Dipnot: IP ağlarında hizmet kalitesi ile ilgili bir konu tartışılmaktadır. Tanımlar belirtilmiş, IP ağlarında kaliteyi belirleme yöntemleri anlatılmıştır. Kaliteli hizmet seviyesinin gerçekleştirildiği protokoller tartışılır. IP hizmetlerinin kalitesini sağlamak için çeşitli teknolojilerin bir karşılaştırması verilmektedir. Kuyruk kavramı ve "onlarla başa çıkmak için algoritmalar" tanıtılır.

7.1. QoS Kavramı

Paket ağları IP tabanlı protokoller, teslimatı garanti etmedikleri için garantili çıktı sağlamaz.

Paketlerin geliş sırasının ve aralığının önemli olmadığı uygulamalar için, bireysel paketler arasındaki gecikme süresi kritik değildir. IP telefonu, paketlerin varış sırasının önemli olduğu ve modern bilgi kodlama ve iletme yöntemleriyle sağlanan sinyal iletim dinamiklerinin önemli olduğu veri iletim alanlarından biridir. IP protokolünün üstünde çalışan TCP/IP yığınının taşıma protokolleri, gecikmeye duyarlı trafik için yüksek kaliteli hizmet sağlamaz. TCP protokolü, bilgilerin güvenilir bir şekilde teslim edilmesini garanti etmesine rağmen, öngörülemeyen gecikmelerle aktarır. Genellikle gerçek zamanlı bilgi taşımak için kullanılan UDP protokolü, TCP protokolüne göre daha az gecikme sağlar, ancak IP protokolü gibi hizmet kalitesini sağlamaya yönelik herhangi bir mekanizma içermez.

Aynı zamanda, tıkanıklık dönemlerinde gecikmeye duyarlı bilgi içeren paketlerin (örneğin konuşma) kuyruklarda boşta kalmamasını veya gecikmeye duyarlı olmayan bilgi içeren paketlerden daha yüksek bir öncelik almamasını sağlayan mekanizmalar sağlamak gerekir. Bu amaçla, gerekli olanın sağlanması için ağda mekanizmalar uygulanmalıdır. hizmet kalitesi(Hizmet Kalitesi - QoS).

Objektif, ölçülebilir veya değerlendirilebilir kalite göstergelerişunlardır:

• ağ gecikmesi değişikliği;
• Şebeke bant genişliği.

Tepki süresi şu şekilde tahmin edilir:

• paketin iletildiği andan onayın alındığı ana kadar geçen zaman aralığı;
• Gecikme olarak da adlandırılan tek yönlü uçtan uca gecikme ( gecikme);
• Bant genişliği.

Hazırlık ve güvenilirlik şu şekilde değerlendirilir:

• ağ kaynaklarına veya kullanım oranlarına erişme yeteneği;
• 7/24 hizmet seviyesinin izlenmesinin sonuçları (haftanın 7 günü, günde 24 saat çalışırken).

IP ağlarında uygulanan QoS önlemleri:

1. Kaynak rezervasyonu (bağlantı süresi boyunca uygulamanın yürütülmesi için gerekli kaynaklar talep edilir ve rezerve edilir).
2. Trafik önceliklendirmesi (ağdaki trafiğin bazıları için öncelikli hizmet sırasına sahip sınıflara ayrılması).
3. Yeniden yönlendirme (ağ tıkanıklığı sırasında trafiği bir yedek rotaya aktarmanıza izin verir; QoS, SBC denetleyicilerinin büyük çoğunluğunda bu şekilde sağlanır).

Modern IP ağlarında, yukarıdaki önlemler RSVP protokolü kullanılarak IntServ, DiffServ ve MPLS teknolojileri kullanılarak uygulanmaktadır.

7.2. IP ağlarında gerçek zamanlı trafik

Kural olarak, VoIP trafiğinin çoğu gecikmeye duyarlı bilgi akışlarından oluşur. Maksimum gecikme 250 ms'yi geçmemelidir ve buna, uç istasyondaki bilgilerin işlem süresi de dahildir. Gecikme değişimi (titreşim) de minimumda tutulmalıdır. Ayrıca sıkıştırma sırasında bilgilerin iletim sırasında oluşan hatalara karşı daha hassas hale geldiği ve gerçek zamanlı iletim ihtiyacı nedeniyle tam olarak yeniden sorgulama ile düzeltilemeyeceği de dikkate alınmalıdır.

Konuşma bilgisinin toplam gecikmesi iki ana bölüme ayrılır - ağ geçitlerinde konuşmanın kodlanması ve kodunun çözülmesindeki gecikme veya terminal ekipmanı kullanıcılar ve ağın kendisinin getirdiği gecikme. Genel gecikmeyi azaltmanın iki yolu vardır: ilk olarak, ağ altyapısını, gecikme minimum olacak şekilde tasarlayın ve ikinci olarak, ağ geçidi tarafından ses bilgilerinin işlem süresini azaltın.

Ağ gecikmesini azaltmak için, geçiş yönlendiricilerinin sayısını azaltmanız ve bunları yüksek hızlı kanallarla bağlamanız gerekir. Ve gecikme değişimini yumuşatmak için, örneğin ağ kaynaklarını ayırma mekanizmaları gibi etkili yöntemleri kullanabilirsiniz.

Gerçek zamanlı aktarım gerektiren konuşma ve diğer bilgilerin statik bilgilerle (normal, sesli olmayan veriler) birlikte sıraya girmesini önlemenin bir yolu, ses bilgilerini içeren paketleri ayıklamak ve sıralamaktır.

7.3. Farklı trafik türleri için farklılaştırılmış hizmet - Diff-Serv

Seçenek DiffServ paketleri yerel ağa giden trafikten sınıflandırmanıza olanak tanır. İş DiffServ alanın ilk 6 biti olan DSCP tanımlayıcısına göre Hizmet Şartları. DSCP, paketlerin bir DiffServ ağında nasıl iletileceğini belirler (PHB, Atlama Başına Davranış). Bu tanımlayıcının değeri değiştirilerek, kuyrukta farklı trafik türleri önceliklendirilebilir.

Diff-Serv modeli, ağ mimarisini bir dizi sınır bölümü ve bir çekirdek olarak tanımlar. Diff-Serv modeline göre bir ağ örneği Şekil 7.1'de gösterilmiştir.

Ağa giren trafik, sınır yönlendiricileri tarafından sınıflandırılır ve normalleştirilir. Trafik normalleştirme, parametrelerinin ölçülmesini, hizmetlerin sağlanması için belirtilen kurallara uygunluğun kontrol edilmesini, profil oluşturmayı (bu durumda, belirlenen kurallara uymayan paketler filtrelenebilir) ve diğer işlemleri içerir. Ağın çekirdeğinde, omurga yönlendiricileri trafiği, kodu DS alanında belirtilen PHB sınıfına göre işler.

Diff-Serv modelinin avantajları:

• belirli bir sınıfın trafiğinin nasıl işlenmesi gerektiğine dair ortak bir anlayış sağlar;
• tüm trafiği nispeten az sayıda sınıfa bölmenize ve her bilgi akışını ayrı ayrı analiz etmemenize olanak tanır;
• ön bağlantıya gerek yok ve kaynak rezervasyonu;
• yüksek performanslı ağ ekipmanı gerekli değildir.

Şimdiye kadar Diff-Serv için iki trafik sınıfı tanımlanmıştır:

• acil paket yönlendirme sınıfı (Hızlandırılmış Yönlendirme PHB Grubu);
• Assured Forwarding PHB Group sınıfı.

Diff-Serv'de kullanılan ağ cihazı seviyesindeki QoS mekanizması aşağıdaki işlemleri içerir. İlk olarak, paketler başlıklarına göre sınıflandırılır. Ardından, yapılan sınıflandırmaya göre işaretlenirler (diff-Serv öncelik alanında, işaretlemeye bağlı olarak, gerekirse iletim algoritması seçilir - paketlerin seçici olarak kaldırılmasıyla), bu da ağdaki tıkanıklığı önlemeye yardımcı olur. Son işlem çoğunlukla öncelik sırasına göre sıralanır.

7.4. Entegre Servis IntServ

IntServ (Entegre Hizmetler), trafiği IP uç ağında yoğunlaştırmak için daha uygundur ve IP geçiş ağlarında kullanılması önerilmez (ölçeklenebilirlik sorunları nedeniyle).

Hizmet entegrasyon modeli 1990'ların başında önerildi ve iki tür hizmetle sağlanan tekli akışlara hizmet etmek için geliştirildi: garantili ve yük yönetimli. Garantili hizmetler, belirli bir trafik miktarı için ölçülebilir maksimum uçtan uca gecikme sağlar. Yükle yönetilen hizmetler, güçlü garantiler olmadan sanal düşük ağ yükü altında en iyi çaba hizmetiyle belirli bir miktarda trafik sağlar.

IntServ'in blok şemasını düşünün (Şekil 7.2).

Pirinç. 7.2.

IntServ'i destekleyen her düğümün birkaç gerekli öğeye sahip olması gerekir:

• sınıflandırıcı- gelen paketi, paketin başlıklarından (ağ ve taşıma katmanları) elde ettiği bilgilere göre hizmet sınıflarından birine yönlendirir. Hizmet sınıfı ayrı bir kuyruk olarak uygulanır. Aynı hizmet sınıfındaki tüm paketler aynı QoS'yi almalıdır;
• Paketleme yöneticisi- her kuyruktan paketleri alır ve onları yönlendirir bağlantı katmanı. IntServ için iki aşamalı bir paket yöneticisi önerilmiştir. Tüm gelen paketler, garantili hizmetleri alan akışları diğerlerinden izole etmek için WFQ hizmet disiplinine göre işlenir. Yük yönetimli ve en iyi çaba gerektiren akışlar önceliklere göre ayrılır;
• erişim kontrol ünitesi(kabul kontrolü) - önceden sağlanan garantileri etkilemeden gerekli miktarda kaynağı trafik yoluyla alma olasılığı hakkında kararlar alır. Tüm akış yolu boyunca kaynak tahsisi talebini kabul etmek veya reddetmek için her düğümde erişim kontrolü gerçekleştirilir;
• kaynak rezervasyon protokolü- bağlantı katılımcılarını (gönderen, alıcı, ara yönlendiriciler) gerekli hizmet parametreleri hakkında bilgilendirir. IntServ modeli için RSVP önerilir.

RSVP (aşağıya bakınız) ile birlikte IntServ hizmet modeli, her uygulamanın ihtiyaçlarını mümkün olduğunca dikkate alarak heterojen trafiğin esnek hizmetini düzenlemenize olanak tanır ve paket hizmeti için WFQ kullanmak, izin verilen maksimum gecikme değerini garanti eder. Bu özellik, IntServ'i hizmet için ideal kılar multimedya trafiği.

Ancak, yüksek esneklik ve tek iş parçacıklarının ihtiyaçlarını karşılama "istekliliği" IntServ'deki bir zayıflık kaynağıdır. Modelin ana dezavantajı düşük ölçeklenebilirlik. Verim IntServ, işlenmekte olan iş parçacıklarının sayısına bağlıdır, bu nedenle bu hizmet modelinin milyonlarca kullanıcısı olan bir ağda uygulanması neredeyse imkansızdır! Bu nedenle, büyük ağlar için daha basit ve daha ölçeklenebilir bir teknolojiye ihtiyaç vardır ve IntServ'in kapsamı dahili ve uç ağlarla sınırlandırılmıştır.

Ancak IntServ'in en büyük dezavantajı, özellikle yüksek hızlı omurga ağlarında RSVP'nin ölçeklenebilirliğinden gelir. Aslında, bir yönlendiricinin RSVP bilgilerini işlemesi ve depolaması için ihtiyaç duyduğu kaynak miktarı, QoS akışlarının sayısıyla orantılı olarak artar. Trafik ölçümleri, IP uçtan uca bağlantıların çoğunun, herhangi bir zamanda bir omurga yönlendiricisi tarafından sürdürülen birkaç bin aktif bağlantıyla çok kısa ömürlü olduğunu göstermektedir. Sonuç olarak, yüksek bant genişliği bağlantısındaki birden çok IntServ akışı, yönlendiriciler üzerindeki yükü büyük ölçüde artırır. Ayrıca, topoloji her değiştiğinde, ayrılmış tüm yollar yeniden yönlendirilmelidir.

7.5. Entegre farklılaştırılmış trafik hizmeti

2000 yılında yayınlanan RFC2998, IntServ / RSVP ve DiffServ'in uçtan uca QoS sağlamak için nasıl etkileşime girdiğini açıklar. Bir modelin zayıflıkları, diğerinin karşılık gelen çözümleri ile telafi edilir. Bir yandan, ağın omurga bölümlerinde zayıf ölçeklenebilir IntServ, daha basit bir DiffServ ile değiştirilebilir, diğer yandan RSVP, alınan belirsizliğin belirsizliği ile sorunu (tamamen değilse, daha büyük ölçüde) çözebilir. "saf" bir DiffServ ağında hizmet.

Pirinç. 7.3.

Ana birlikte çalışabilirlik sorunu, RSVP ile talep edilen ve bir DiffServ bölgesinde sağlanan kaynakların eşleştirilmesidir (bu, farklı hizmetlerin sağlanabileceği DiffServ etki alanlarının bitişik dizisine verilen addır). Kaynak eşlemeyi uygulamak için bir dizi çözüm önerilmiştir.

Hizmet kalitesi protokollerinin etkileşimi için iki seçenek düzenlemek mümkündür:

• DiffServ bölgesi RSVP sinyalleşmesini desteklemez ve kaynaklar statik olarak tahsis edilir;
• RSVP mesajları DiffServ bölgesinde işlenir.

İlk durumda takım çalışması müşteri ve SLS operatörü arasındaki statik bir anlaşmaya dayalıdır (hizmet seviyesi belirtimi). En basit durumda, bir DiffServ ağındaki kullanıcı trafiği tarafından alınan bant genişliği miktarını tanımlar. Bu durumda (Şekil 7.3), Tx (gönderen), DiffServ bölgesi aracılığıyla Rx'e (alıcı) yönlendirilen Yol mesajları üretir.

DiffServ bölgesinden geçerken, RSVP mesajlarının içeriği yok sayılır ve normal bir veri paketi olarak gönderilir. Rx düğümü Yol mesajını aldığında, daha sonra Tx düğümüne geri yönlendirilen bir RESV rezervasyon talebi oluşturulur. İstek her RSVP uyumlu yönlendirici tarafından başarıyla işlenir ve DiffServ bölgesinden geçerse, RESV mesajı yönlendirici Er1'e ulaşır. Er1, SLS'ye dayalı olarak, RESV mesajında ​​talep edilen kaynakları ve DiffServ bölgesinde bulunan kaynakları karşılaştırır. Er1 talebi onaylarsa, RESV mesajı Tx düğümüne doğru gönderilir. Aksi takdirde mesaj reddedilir ve Rx düğümü gönderilir. hata mesajı. Tx düğümü tarafından alınan mesaj, Rx düğümüne gönderilen paketleri uygun kodla işaretleme hakkında bilgi içerebilir. Kod değeri varsayılan olarak veya RESV mesajından belirlenir.

İkinci seçenek, DiffServ bölgesindeki (örneğin, Br1) sınır yönlendiricilerinin RSVP protokolünü desteklediğini varsayar. RSVP sinyali desteğine rağmen, yalnızca toplu akışlar IntServ/RSVP ağında olduğu gibi tekli olanlar yerine . RSVP mesaj alışverişinin sırası, önceki durumdakiyle aynıdır. Ancak destek sayesinde

Mayıs
2017

Yayınlar

ViPNet teknolojisi kullanılarak oluşturulan bir VPN ağında IP trafiğinin yönlendirme ve dönüşüm ilkeleri

Yayın, ViPNet düğümlerinin onları telekomünikasyon ağlarına bağlamanın farklı yolları ile etkileşimini sağlayan ViPNet sanal ağındaki yönlendirme ve trafik dönüşümünün temel ilkelerini tartışıyor.

Yayın, ViPNet ağının özelliklerini anlaması gereken teknik uzmanlara yöneliktir. Örneğin, uygulama olasılığını değerlendirmeniz veya dağıtımını planlamanız gereken durumlarda.

Bu makaleyi okumak için IP ağları ve güvenlik duvarları hakkında temel bilgilere sahip olmanız gerekir.

giriiş

Birçok VPN sistemi, öncelikle yerel ağları İnternet üzerinden güvenli bir şekilde bağlamak ve kaynaklara güvenli uzaktan erişim sağlamak için tasarlanmıştır. Bu görevlerle birlikte, yerel ağ içinde de dahil olmak üzere konumlarından bağımsız olarak, Eşler Arası şemaya göre doğrudan düğümler arasında trafik koruması düzenleme görevi varsa, bu tür sistemlerin kullanımı çok zordur. ViPNet teknolojisi, herhangi bir topolojideki düğümlerin VPN bağlantısı sorunlarını çözmeyi kolaylaştırır.

ViPNet teknolojisi ile klasik VPN sistemleri arasındaki avantajlı farklardan biri, ViPNet düğümleri arasında güvenli bilgi alışverişi oturumları sırasında herhangi bir senkronizasyon prosedürü ve anahtar oluşturma olmamasıdır. Bu özellik, sistemin kararlılığını büyük ölçüde artırır ve çeşitli ağ hizmetlerinin yüksek güvenilirliğini sağlar.

1.1 ViPNet sanal ağ bileşenleri

Çeşitli işletim sistemleri için ViPNet bileşenleri, ViPNet yazılım ve donanım sistemleri ve çeşitli sanal ortamlar için hazır sanal makineler kullanılarak bir sanal ağ oluşturulur. Sanal ağ ayrıca iOS, Android ve bu platformlar için geliştirilmiş yüklü ViPNet İstemci uygulamalarına sahip diğer işletim sistemi platformlarındaki mobil cihazları da içerebilir.

ViPNet İstemci yazılımına sahip bilgisayarlar ve mobil cihazlar bundan böyle İstemciler olarak anılacaktır. İstemciler, ağ koruması ve bireysel bilgisayarların ve cihazların VPN ağına dahil edilmesini sağlar.

Windows ve Linux için ViPNet Coordinator yazılımına sahip bilgisayarlar, büyük ve küçük ağlar için ViPNet yazılım ve donanım sistemleri, çeşitli kapasitelerde endüstriyel güvenlik ağ geçitleri, sanal makinelerdeki ViPNet koordinatörleri bundan sonra Koordinatör olarak anılacaktır. Çeşitli güvenlik sınıflarının koordinatörleri, tünelledikleri ağ kaynaklarının trafik şifrelemesini (VPN ağ geçitleri gibi), diğer VPN düğümleri arasında VPN trafiğini aktarır, güvenli ağ bağlantısını sürdürmek için hizmet işlevlerini gerçekleştirir ve düğümler arasındaki VPN trafik yollarını optimize eder.

İstemciler ve Koordinatörler, ViPNet sanal ağ düğümleri veya basitçe ViPNet düğümleri olarak adlandırılır. ViPNet düğümleri (düğümler arasındaki bağlantılar) arasında güvenli kanallar aracılığıyla trafik alışverişi yapma yeteneği, yönetici tarafından merkezi olarak ayarlanır.

1.2 Koordinatörün işlevleri

Koordinatörler genellikle ağların ucuna kurulur ve aşağıdaki işlevleri yerine getirir:

VPN ağ geçidi, yerel ve uzak düğümler arasında güvenli siteden siteye ve istemciden siteye kanalların (tünellerin) oluşturulmasını uygulayan klasik VPN'ler için standart bir özelliktir. Koordinatör, VPN paketlerini yönlendirme işlevini yerine getiren bir dizi diğer koordinatör aracılığıyla böyle bir kanal oluşturabilir.

Güvenlik duvarı, açık, güvenli ve tünelli geçiş ve yerel ağ bağlantıları için bir filtreleme işlevi ve açık ve tünelli bağlantılar için bir adres çevirme işlevidir.

IP adres sunucusu - hem bu sanal ağ içindeki hem de diğer ViPNet sanal ağlarının düğümleriyle etkileşime girerken ViPNet düğümleri arasında ağ topolojisi hakkında güncel bilgilerin otomatik alışverişi işlevi. Bilgi alışverişi, özel bir güvenli VPN trafiği dinamik yönlendirme protokolü kullanılarak yapılır (bkz. "Dinamik Yönlendirme Protokolü"). Bu protokolün sonucu, VPN trafiğini, kullanılan yöntem ve düğümün ağa bağlı olduğu yer için en uygun rota boyunca ViPNet ağ düğümleri arasında yönlendirme yeteneğidir.

VPN paket yönlendiricisi - koordinatörden geçen transit VPN trafiğinin diğer ViPNet düğümlerine yönlendirilmesini sağlayan bir işlev. Yönlendirme, VPN paketlerinin açık kısmında iletilen ve taklit ekleme ile sahteciliğe karşı korunan güvenli düğümlerin tanımlayıcılarına ve VPN trafiği dinamik yönlendirme protokolünün çalışması sonucunda elde edilen verilere dayanarak gerçekleştirilir. Koordinatör üzerinde yönlendirilen herhangi bir VPN trafiği, bir sonraki veya son ViPNet düğümüne, bu düğümün erişilebilir olduğu IP adresine ve bağlantı noktasına gönderilir. Paketin kaynak IP adresi, paketin kaynaklandığı koordinatörün arayüz adresi ile değiştirilir. Bir VPN paket yönlendiricisi olarak hareket ederken, koordinatörün diğer düğümlerin şifrelenmiş verilerine erişimi yoktur, yalnızca onları iletir.

Bir istemci veya koordinatör, dinamik NAT ile bir cihaz aracılığıyla İnternet'e bağlanırsa, diğer ana bilgisayarlardan gelen başlatma bağlantılarına doğrudan erişilemez. Bu durumda, bu koordinatörün arkasındaki kurumsal ağ kaynaklarına erişimi düzenlemek veya uzak düğümlerden böyle bir istemciyle bağlantı kurmak için, dış ağdaki koordinatörlerden biri, sürekli iletişim kurdukları bir bağlantı sunucusu olarak tanımlanır. VPN paket yönlendiricisinin işlevselliği nedeniyle, bağlantı sunucusu, harici ağdan böyle bir düğümle iletişim kurmak için bir ara bağlantı görevi görür (daha sonra doğrudan iletişime geçiş olasılığı ile, daha fazla ayrıntı için bkz. dinamik NAT'lı cihazlar aracılığıyla İnternet'e ").

Bağlantı Sunucusu, dağıtıldıklarında istemci ayarlarında otomatik olarak ayarlanır ve daha sonra değiştirilebilir. Koordinatör için gerekirse bağlantı sunucusu ayarlarında belirtilebilir.

Aktarım sunucusu - önemli güncellemelerin, referans bilgilerinin, ilkelerin, ViPNet ağ yönetim programlarından korunan düğümlere ViPNet yazılım güncellemelerinin teslimini ve ayrıca ViPNet uygulama yazılımı posta zarflarının (örneğin, ViPNet Business Mail, File Exchange programları) yönlendirilmesini sağlayan bir işlev ).

Varsayılan olarak, IP adresi sunucusu, istemcinin bağlantı sunucusudur. Gerekirse Bağlantı Sunucusu olarak başka bir koordinatör atanabilir.

2. Bir sanal ağdaki ViPNet düğümleri arasındaki etkileşimin genel ilkeleri

ViPNet ağ düğümleri, IP protokolünü destekleyen her tür ağda bulunabilir. Ana bilgisayarın ağa bağlanma şekli herhangi biri olabilir: Ethernet ağı, XDSL bağlantısı üzerinden PPPoE, Çevirmeli veya ISDN bağlantısı üzerinden PPP, herhangi bir hücresel ağ, Wi-Fi cihazları, MPLS ağları veya VLAN'lar ve diğerleri.

2.1 Dinamik Yönlendirme Protokolü

Yönetici, kontrol uygulamasında (ViPNet Yöneticisi) aralarında bağlantılar ayarladıysa, ViPNet ağındaki iki düğüm birbiriyle iletişim kurabilir. Uzak tünelli düğümlere erişmek için tünel oluşturma koordinatörü ile bir bağlantı kurmanız gerekir. İki düğüm arasında bir bağlantı kurmak, iki düğümün, aralarında güvenli bir VPN bağlantısı düzenlemek için gerekli anahtar bilgilere sahip olduğu anlamına gelir.

Her istemcinin kendi koordinatörü vardır - IP adres sunucusu, bağlantı sunucusu ve taşıma sunucusu (bkz. "Koordinatör işlevleri". Gerekirse, bu işlevleri farklı koordinatörler tarafından gerçekleştirilecek şekilde yapılandırabilirsiniz).

ViPNet düğümlerinin birbirine sürekli erişim olanağı, işletim sistemi uygulama düzeyinde çalışan VPN trafiği dinamik yönlendirme protokolü tarafından sağlanır. Bu protokol içindeki hizmet verilerinin değişimi, aynı VPN bağlantıları üzerinden gerçekleşir ve bu nedenle korunur.

Dinamik yönlendirme protokolünün çalışması, ViPNet ağ düğümleri arasında, birbirlerine erişmenin olası yolları hakkında güncel bilgileri ve ayrıca gerçek IP adreslerinin listelerini otomatik olarak aktarmaktır. Protokol, bu bilgiyi yalnızca kendi ViPNet ağı içinde değil, aynı zamanda farklı ViPNet ağlarının düğümleri arasında da dağıtır (eğer iki ağın yöneticileri, aşağıdakilere uygun olarak güvenli etkileşim için iki ağın düğümleri arasındaki bağlantılar hakkında ilgili bilgileri kabul etmiş ve değiş tokuş etmişse). görevleri).

Protokolün işleyişinde önemli bir rol, tüm ağ düğümlerine iletişimi organize etmek için gerekli bilgileri sağlayan koordinatörler tarafından oynanır. Bir IP adresi sunucusu olarak görev yapan koordinatörler, "kendi" istemcilerine mevcut erişim yöntemleri hakkında bilgi toplar. Daha sonra, IP adresi sunucuları bu bilgiyi istemcileriyle ilişkili düğümlere doğrudan veya başka bir koordinatör zinciri aracılığıyla iletir.

Bilgi alışverişi görevlerine (bundan sonra hedeflenen trafik olarak anılacaktır) uygun olarak trafiğin güvenli iletimini sağlamak için, bu trafiğin korunmasını sağlayan düğümler (istemciler ve tünel koordinatörleri) arasında bağlantılar kurmanız gerekir. çoğu durumda otomatik olarak oluşturulan "kendi" koordinatörleri ile müşterilerin bağlantıları.

Dinamik yönlendirme protokolü trafiğinin (bundan sonra hizmet trafiği olarak anılacaktır) güvenli iletimini sağlamak için, düğümlere erişim hakkında bilgilerin iletilmesi gereken zincir boyunca koordinatörler arasında bağlantılar kurmak da gereklidir. Küçük ağlarda, basitlik için koordinatörleri "hepsinden herkese" temelinde bağlayabilirsiniz. Ancak, büyük ağlarda, hizmet trafiğini azaltmak için koordinatörler arasındaki bağlantı sayısı en aza indirilmeli ve bağlantılar, hizmet trafiğini yönlendirmek için aşağıdaki olasılıklara göre ayarlanmalıdır:

Bir ViPNet ağı içinde bilgi, ikiden fazla koordinatörün bulunmadığı bir zincir boyunca iletilir. Yani, istemciler birbirine bağlıysa, bu istemciler için bir IP adresi sunucusunun işlevlerini yerine getiren koordinatörlerin de birbirine bağlı olması gerekir.

• İki farklı ViPNet ağı etkileşime girdiğinde, hizmet trafiği her ağda en fazla iki koordinatörden oluşan bir zincir aracılığıyla değiş tokuş edilebilir. Bu sayede, her ağda, üzerinden başka bir ağ ile alışverişin gerçekleşeceği bir koordinatör (ağ geçidi) seçmek ve onu başka bir ağdaki aynı koordinatöre bağlamak yeterlidir. Ve zaten bu koordinatörlerle, hizmet bilgilerini başka bir ağa aktarması gereken ağların her birinin koordinatörleriyle iletişim kurulur. Bu topoloji ile, ağ geçidi koordinatörleri, birlikte çalışmanın hem yönetimini hem de kontrolünü basitleştiren başka bir ağa "tek giriş noktası" haline gelir. Doğal olarak, iki ağın koordinatörleri, atanmış ağ geçidi koordinatörleri aracılığıyla değil de doğrudan bağlanırsa, bilgi daha kısa sürede iletilecektir.

Dinamik yönlendirme protokolünün bir sonucu olarak, tüm ViPNet düğümleri, bağlı oldukları diğer düğümlere erişim parametreleri hakkında bilgiye sahiptir. Aynı zamanda, her durumda, hizmet trafiği rotasından bağımsız olarak düğümler arasındaki hedeflenen trafik, mevcut ağ altyapısı izin veriyorsa koordinatörleri atlayarak en kısa yoldan gidecektir (bkz. dinamik NAT'lı cihazlar aracılığıyla İnternet").

2.2 Kapsülleme

ViPNet yazılımı, istemcinin veya koordinatörün tüm ağ trafiğini yakalar. Güvenli bir kanal üzerinden başka bir ViPNet ana bilgisayarına iletilmesi amaçlanan trafik, güvenli ViPNet IP paketlerinde kapsüllenir. Herhangi bir protokolün orijinal IP paketleri kapsüllenir (ağ katmanında tünelleme).

Bağlantının olduğu diğer ViPNet düğümlerine herhangi bir IP paketi göründüğünde, alıcı düğümle herhangi bir ön bağlantı protokolü olmayan paket şifrelenir, bir ViPNet paketinde kapsüllenir ve VPN ağı aracılığıyla alıcı düğüme iletilir.

Koordinatörlerin belirli modifikasyonları, uzak ağ segmentlerini tek bir yerel ağda birleştirmenize izin veren bağlantı düzeyinde (L2 OSI) tünellerin inşasını da destekler. Bu durumda, sadece IP değil, herhangi bir ağ protokolünün Ethernet çerçeveleri, ViPNet korumalı IP paketlerinde (UDP protokolü) kapsüllenir.

ViPNet paketlerinde kapsülleme için iki tip IP protokolü kullanılır:

Varsayılan kaynak bağlantı noktası 55777 veya diğer ana bilgisayarlarda otomatik olarak kaydedilen başka bir bağlantı noktası ile IP/UDP.

IP/241 - düğümler aynı yerel ağda etkileşim kurduğunda kullanılır.

Aynı yayın alanındaki düğümler arasındaki iletişim için, ek UDP başlıklarının olmaması nedeniyle daha az ek yükü olan IP/241 protokolü otomatik olarak kullanılır.

IP/241, aynı yayın etki alanındaki ana bilgisayarlar arasındaki trafiği kapsüllemek için kullanılır.

Diğer durumlarda, UDP protokolü otomatik olarak kullanılır, bunun için IP paketlerinin her tür güvenlik duvarı ve NAT'lı cihaz üzerinden geçişini organize etmek kolaydır. Güvenli UDP paketleri oluştururken, düğümler varsayılan olarak kaynak bağlantı noktası 55777'yi (kapsülleme bağlantı noktası) ayarlar, ancak ayarlarında, dinamik yönlendirme protokolü sayesinde diğer düğümler tarafından bu aracılığıyla erişimi organize etmek için bilinecek olan isteğe bağlı bir bağlantı noktası ayarlayabilirsiniz. Liman. Bir ağdaki NAT aygıtları arasında geçiş yaparken, paketlerdeki kaynak bağlantı noktası değişebilir. Bununla ilgili bilgiler, yaklaşmakta olan trafiğin geçişini organize etmek için diğer düğümler tarafından da bilinecektir.

UDP protokolü, bir NAT cihazı tarafından ayrılmış düğümler arasındaki trafiği kapsüllemek için kullanılır.

UDP paketlerinin iletiminin ISP tarafından yasaklandığı ve güvenli düğümlerin UDP protokolü aracılığıyla etkileşiminin imkansız olduğu durumlar vardır. Örneğin, otellerde ve diğer halka açık yerlerde erişim noktaları kullanılırken UDP trafiği engellenebilir.

Ana bilgisayar böyle bir yasağı otomatik olarak algılar ve oluşturulan UDP paketlerini ilettiği bağlantı sunucusuyla (varsayılan olarak 80 numaralı bağlantı noktasında) bir TCP bağlantısı kurar. Diğer ana bilgisayarlar için ViPNet trafiği, bu bağlantı aracılığıyla, bağlantı sunucusuna iletilir ve oradan normal şekilde iletilir. Bağlantı Sunucusunda bir TCP tüneli kurarken, sunucunun TCP paketlerini kabul edeceği herhangi bir bağlantı noktası belirtilebilir.

UDP trafiğinin kullanılması mümkün değilse, düğüm, bağlantı sunucusuyla bir TCP bağlantısı kurar ve bunun üzerinden ViPNet ağının diğer düğümleriyle UDP trafiğini değiştirir.

2.3 İlk güvenli ağ ayarları

Düğümler, VPN trafiğinin dinamik olarak yönlendirilmesine yönelik protokolün çalışması nedeniyle uygulamaların etkileşimi için gerekli tüm bilgileri otomatik olarak alır. Bir ağ kurarken yapılması gereken ilk ayarlar minimum düzeydedir:

Ağ Kontrol Merkezi'nde bir ağ yapısı oluşturun - istemciler, koordinatörler ve bağlantıları.

Ağ koordinatörlerine erişmek için IP adreslerini veya DNS adlarını ayarlayın.

ViPNet istemcileri genellikle yazılım kurulumundan sonra herhangi bir ayar gerektirmez.

Gerekirse, her koordinatör için harici bir ağa bağlanmak için birkaç moddan birini ayarlayın. Varsayılan mod ("Statik adres çevirisi ile") çoğu durumda ek ayarlar olmadan çalışmasını sağlar. Koordinatörde bağlantı modlarını ayarlama hakkında daha fazla bilgi için “Koordinatörleri harici bir ağa bağlama seçenekleri” bölümüne bakın.

Kuruluşun harici güvenlik duvarında, gerekirse, ilgili ViPNet protokolünün (UDP ve/veya TCP protokolünün bağlantı noktaları ve adresleri) atlanmasını yapılandırın.

Diğer ViPNet ağlarının gerekli düğümleri ile etkileşim kurmak için, başka bir ViPNet ağının yöneticisi ile bazı birincil hizmet bilgilerini değiş tokuş edin. Gelecekte, böyle bir değişim otomatik olarak gerçekleşecektir.

3. ViPNet ağındaki bağlantı mekanizmaları

3.1 Düğümlerin göreli konumunu belirleme

Düğümler, birbirleriyle ilişkili olarak nasıl konumlandıklarına bağlı olarak farklı bağlantılar kurar:

Aynı yayın etki alanındalar.

Aynı yönlendirilmiş ağda bulunurlar, ancak farklı yayın etki alanlarında bulunurlar, yani yönlendirme cihazlarıyla ayrılırlar (statik adres çevirisi olanlar dahil) ve yayın yoluyla birbirlerine erişilemezler.

Dinamik adres çevirisine sahip NAT cihazlarıyla ayrılmıştır.

Ağa bağlanırken veya kendi IP adresini değiştirirken, ana bilgisayar özel bir yayın gerçekleştirir ve diğer ViPNet ana bilgisayarlarının kendisiyle aynı yayın etki alanında olduğunu yanıtlardan belirler. Bu tür düğümler birbirlerinin IP adreslerini kaydeder. Bu adreslere gönderilen paketler şifrelenir ve IP/241 protokolünde kapsüllenir.

İstemciler, yayın etki alanlarında erişilemeyen ana bilgisayarlar hakkında bilgi almak için bir IP adres sunucusu kullanır ve diğer ana bilgisayarlara tam erişim bilgilerine sahip olan, ilk olarak onlara güvenilir bir şekilde bağlanmak için bir bağlantı sunucusu kullanılır.

3.2. Dinamik NAT ile cihazlar üzerinden internete bağlanan iki ana bilgisayarın bağlantısı

Dinamik NAT modunda İnternet erişimi sağlayan bir sağlayıcı aracılığıyla İnternete bağlanan iki düğüm arasındaki bağlantıların organizasyonunu düşünün. Örneğin, Müşteri 1 Londra'da bir otelde ve Müşteri 2 St. Petersburg'da bir otelde:

1. Bilgisayar açıldığında, her İstemcinin ViPNet yazılımı, UDP protokolü aracılığıyla bağlantı sunucusuna erişim kanalını belirler (bağlantı sunucusu paylaşılabilir).

İstemci 1, bağlantı sunucusuna UDP aracılığıyla bağlanamazsa, Müşteri TCP aracılığıyla bir bağlantı kurar (varsayılan olarak bağlantı noktası 80, ancak başka herhangi bir bağlantı noktası ayarlanabilir).

2. İstemci, Bağlantı Sunucusuna bağlandıktan sonra, sunucuya periyodik olarak test IP paketleri göndererek bağlantıyı sürdürür. Bu nedenle İstemci 1, İstemci 2 dahil olmak üzere diğer düğümlerin bağlantı sunucusu aracılığıyla kendisiyle bir girişim bağlantısı kurmasına izin verir. IP paketlerini Connection Server'a göndermek için varsayılan aralık 25 saniyedir. Bu, çoğu NAT aygıtında çalışmak için genellikle yeterlidir. Gerekirse, aralık (zaman aşımı) değiştirilebilir.

3. İstemci 1'deki bazı uygulamalardan İstemci 2 yönünde hedeflenen trafik varsa (örneğin, VoIP), İstemci 1 kendi bağlantı sunucusu aracılığıyla paketleri iletmeye başlar. Bağlantı Sunucusu, sırayla, bu paketleri İstemci 2'nin Bağlantı Sunucusuna iletir, o da daha sonra bunu İstemci 2'ye gönderir.Dönüş trafiği benzer bir rota izler.

İstemci 1, Bağlantı Sunucusuna bir TCP bağlantısı üzerinden bağlanırsa, Bağlantı Sunucusu TCP bağlantısından UDP trafiğini alır (hâlâ şifrelenir ve Bağlantı Sunucusu tarafından şifresi çözülemez). Sunucu, Bağlantı Sunucusu aracılığıyla İstemci 2'ye UDP trafiği gönderir. İstemci 2, bağlantı sunucusuyla TCP üzerinden iletişim kurarsa, İstemci 2'nin bağlantı sunucusuna ulaşan trafik, bu TCP bağlantısı üzerinden İstemci 2'ye gider.

Böylece iki istemci, iki bağlantı sunucusu aracılığıyla birbirleriyle iletişim kurar. İstemci bağlantı sunucusuna UDP aracılığıyla bağlanırsa, uygun bir ağ ortamı yapılandırmasıyla bağlantı sunucuları etkileşimden çıkarılabilir, yani istemciler doğrudan mesaja gider. Bu mekanizmayı düşünün:

1. UDP protokolü aracılığıyla hedeflenen trafiğin iletilmesine ve alınmasına paralel olarak, bağlantı sunucuları aracılığıyla aşağıdakiler gerçekleşir:

Her iki istemci, bağlantı sunucularından alınan harici ağdan (adres ve bağlantı noktası) kendilerine doğrudan erişim parametreleri hakkında bilgi içeren bağlantı sunucuları aracılığıyla birbirlerine bir test paketi gönderir.

• Her iki istemci de bu paketleri birbirinden alır ve birbirlerine olası doğrudan erişimin parametrelerini öğrenir. Ayrıca, her istemci diğer istemcinin bağlantı sunucusuna erişim bilgilerine de sahiptir (bu bilgiyi önceden kendi IP adres sunucularından alırlar). Bu verileri kullanarak, her iki istemci de test IP paketlerini doğrudan adreslere ve erişim bağlantı noktalarına birbirlerine ve diğer taraftaki bağlantı sunucularına gönderir.

1. Taraflardan en az birinin test IP paketi, diğer tarafın NAT cihazından doğrudan geçmeyi başardıysa, düğümler arasında doğrudan bir bağlantı kurulur. Bu doğrudan bağlantının her iki taraf için kullanılabilirliği, hedeflenen trafiğin iletiminin sona ermesinden sonra 75 saniye boyunca korunur. Bundan sonra, rotalar bırakılır ve bir bağlantı kurulması gerekiyorsa, düğümler yeniden bağlantı sunucuları üzerinden trafik iletmeye başlar.

Tüm NAT türleri doğrudan bağlantı kurmanıza izin vermez (aşağıya bakın). Taraflardan en az biri buna izin veren bir NAT cihazı kullanıyorsa doğrudan bağlantı mümkündür.

2. Test doğrudan IP paketleri her iki tarafa da ulaşmadıysa, ancak diğer taraftaki bağlantı sunucusuna ulaştıysa, iki istemci arasındaki hedeflenen trafik bağlantı sunucularından birinden geçecektir. Bu bağlantının kullanılabilirliği, hedeflenen trafiğin aktarımının sona ermesinden sonra 75 saniye boyunca bağlanan düğümler için de korunur. Benzer bir durum, istemcilerden biri bağlantı sunucusuna TCP üzerinden bağlanırsa ortaya çıkar. Bu Bağlantı Sunucusu trafikten hariç tutulamaz, ancak düğümünün UDP aracılığıyla bağlı olduğu başka bir Bağlantı Sunucusu hariç tutulabilir.

3. Test paketleri herhangi bir yere ulaşmadıysa, iki düğüm arasındaki trafik, iki bağlantı sunucusu üzerinden uzun bir yol boyunca ilerlemeye devam edecektir.

Bağlantı sunucuları aracılığıyla NAT cihazlarının arkasındaki istemcilerin etkileşiminin başlaması ve doğrudan etkileşime geçiş

Dört tür dinamik NAT vardır: Koni NAT, Adres Kısıtlı koni NAT (veya Kısıtlı koni NAT), Port Kısıtlı koni NAT, Simetrik NAT. Doğrudan bağlantı kurulması, yalnızca her iki NAT cihazı da Simetrik NAT gerçekleştirecek şekilde yapılandırılmışsa desteklenmez. Bu durumda, trafik bağlantı sunucularından birinden geçecektir. En az bir taraf başka bir NAT türü çalıştırıyorsa, doğrudan bağlantı kurulur.

Böylece ya uzak ana bilgisayarla doğrudan bağlantı kurulur ya da Bağlantı Sunucularından biri aracılığıyla bağlantı kurulur. Mümkünse düğümler, bağlantı sunucularının katılımı olmadan en kısa yollar üzerinden birbirleriyle iletişim kurar, böylece şifreli IP trafiğinin hızını arttırır ve koordinatörlerin üzerindeki yükü azaltır. İstemciler daha kısa bir bağlantı kuramazlarsa, istemciler bağlantı sunucuları aracılığıyla birbirleriyle iletişim kurmaya devam eder.

3.3 Aynı yönlendirilmiş ağdaki düğümleri bağlama

İki istemci aynı yönlendirilmiş ağdaysa veya statik NAT cihazlarıyla ayrılmışsa ancak yayın yoluyla erişilemiyorsa, ilk paketleri Bağlantı Sunucusu aracılığıyla da gönderirler. Bundan sonra, yukarıda açıklanan mekanizmaya göre (bkz. “İnternete bağlanan iki düğümün dinamik NAT ile cihazlar aracılığıyla bağlanması”), bu tür düğümlerin bağlantı sunucusunun katılımı olmadan doğrudan iletişim kurmaya başlamaları garanti edilir. Sonraki bağlantılar, bağlantı sunucusu doğrudan dahil olmadan saklanan yönlendirme bilgilerine göre iki düğüm tarafından kurulur.

Düğümler, hedeflenen trafik olmasa bile sıfırlanmayacak olan paket yönlendirme bilgilerini birbirleri için depolar. Bilgiler, yalnızca düğümün bağlantısı kesilirse ve ardından ağa yeniden bağlanırsa sıfırlanır.

3.4 Başka bir ViPNet ağına taşınan bir istemci için bir bağlantı sunucusu seçme

Bir istemci kullanıcısı veya bir ağ yöneticisi, ara bağlantının kurulduğu başka bir ViPNet ağındaki bir koordinatör de dahil olmak üzere, istemci için bağlantı sunucusu olarak herhangi bir koordinatörü seçebilir. Bu, örneğin istemci, İnternet erişiminin yalnızca bu yerel ağda bulunan bir "yabancı" koordinatör (başka bir ViPNet ağının koordinatörü) aracılığıyla mümkün olduğu bir yerel ağa geçtiğinde gerekli olabilir. Başka bir ağdaki Bağlantı Sunucusu aracılığıyla bağlanabilmenin koşulu:

istemci ağı ve bağlantı sunucusu ağı arasında birlikte çalışmanın varlığı;

"yabancı" bir bağlantı sunucusunun, istemci için bir IP adres sunucusu görevi gören "kendi" ağındaki bir koordinatörle bağlantısı.

Bağlantı sunucusunun görevi, istemciden istemcinin bağlı olduğu ana bilgisayarlara bağlantılar sağlamaktır. Bunu yapmak için, istemcinin hedeflenen trafiğinin yönlendirilmesini sağlamak için bağlantı sunucusunun bu düğümlere olası erişim yolları hakkında bilgiye sahip olması gerekir. Ancak, diğer ağların düğümlerine erişim parametreleriyle ilgili bilgiler, yalnızca bu düğümler bu yabancı ağın herhangi bir düğümüne bağlıysa yabancı bir ağa (bağlantı sunucusunun ağı) girebilir. Çoğu zaman durum böyle değildir ve istemcinin bağlı olduğu ve istemcinin erişmesi gerekebilecek düğümlerin en azından bazılarının (ve muhtemelen tümünün) bu ağla bağlantısı yoktur. Ancak bu düğümlere erişimle ilgili bilgiler, istemcinin ağındaki IP adres sunucusuna aittir. IP adresi sunucusu bunu istemciye gönderir. İstemci bu bilgiyi aldığında, yabancı ağdaki bir bağlantı sunucusuna iletir. Sonuç olarak, yabancı bir ağdaki bir bağlantı sunucusu, hedeflenen istemci trafiğini bağlı olduğu tüm ana bilgisayarlara yönlendirebilir. İstemci, kendi ve bağlı olduğu diğer güvenli ağların tüm kaynaklarına erişim sağlar.

İstemcinin orijinal Bağlantı Sunucusuna, istemcinin taşındığı yerel ağdan erişilebiliyorsa, Bağlantı Sunucusunu değiştirmeye gerek yoktur.

4. Koordinatörleri harici bir ağa bağlama seçenekleri

Koordinatör için harici ağdaki çeşitli bağlantı modlarından birini ayarlayabilirsiniz. Mod seçimi, koordinatörün harici ağdan koordinatöre harici bir güvenlik duvarı tarafından ayrılıp ayrılmadığına bağlıdır. Aşağıdaki modları ayarlayabilirsiniz:

"Güvenlik duvarı kullanmadan" bağlantı modu.

Başka bir koordinatörün harici güvenlik duvarı olduğu koordinatör bağlantı modunun arkasında.

Güvenlik duvarı bağlantı modu "Statik adres çevirisi ile".

Güvenlik duvarı bağlantı modu "Dinamik adres çevirisi ile".

Varsayılan olarak, koordinatörler "Statik adres çevirisi ile" güvenlik duvarı üzerinden çalışacak şekilde ayarlanmıştır. Mod, ViPNet Yönetici kontrol uygulamasında veya doğrudan koordinatörde değiştirilebilir. Bu mod oldukça çok yönlüdür ve çoğu durumda kullanılabilir.

4.1 "Güvenlik duvarı kullanmadan" modunda bir koordinatör bağlama

Koordinatörün İnternette kalıcı bir IP adresi varsa, İnternet erişimi olan herhangi bir ağdan ona bir rota oluşturabilirsiniz. Böyle bir koordinatörde, “Güvenlik duvarı kullanmadan” modunu ayarlayabilirsiniz.

Bu durumda, "Statik adres çevirisi ile" varsayılan modu da kullanılabilir. ViPNet'in gelecek sürümlerinde, "Güvenlik duvarı olmadan" modunun kullanımdan kaldırılması gerekiyor.

4.2 Bir koordinatörü başka bir koordinatör aracılığıyla bağlama: Koordinatör modunun arkasında

Koordinatör A, yerel ağın iç ve dış bölümleri arasındaki sınırda bulunuyorsa ve dış ağ, koordinatör B tarafından korunuyorsa, koordinatör A genellikle "Koordinatörün Arkasında" moduna ayarlanır ve koordinatör B'yi harici olarak seçer. Bu durumda koordinatör B, koordinatör A bağlantı sunucusu rolünü yerine getirir.

Koordinatörlerin birbiri ardına bu şekilde kurulması (basamaklı), yerel ağın iç bölümlerinin trafiğini hem yerel ağın dış konturunda hem de trafik bunun ötesine geçtiğinde korumanıza olanak tanır. Zincirdeki koordinatör sayısı sınırlı değildir. Bir koordinatör için birkaç koordinatör kurabilir ve böylece birbirinden ve birkaç bölümünün ortak yerel ağından güvenilir izolasyon sağlayabilirsiniz. İstemciler, belirli iş istasyonlarını korumak için bu yerel ağda herhangi bir yere yerleştirilebilir.

Basamaklı koordinatörler

Koordinatörleri yerel ağ içinde, sınırında duran koordinatörün (basamaklı koordinatörler) arkasına kurarken, yerel ağın dahili bölümünden uzak ViPNet düğümlerine trafik aşağıdaki gibi iletilir:

Yerel ağın iç kesimlerini koruyan ViPNet koordinatörleri, kendileri tarafından şifrelenmiş, uzaktan korunan kaynaklara yönelik trafiği otomatik olarak harici ağ kesiminin kenarındaki bir koordinatöre gönderir. Bu koordinatör, uzaktaki ana bilgisayarlar hakkında sahip olduğu bilgilere göre güvenli trafiği iletir.

• Uzak ViPNet düğümleri, yerel ağ içindeki koordinatörlere daha fazla ileten harici bir koordinatör aracılığıyla yerel ağın dahili kesimine yönelik trafiği gönderir.

Basamaklı koordinatörler, hem yerel ağın dış kesiminde hem de dış genel ağda geçtiğinde yerel ağın iç kesiminin trafiğini korumanıza izin verir. Basamaklama ayrıca VPN trafiğinin, çeşitli yönetim şemalarında genellikle onu kontrol etmek için kullanılan WAN'da istenen yoldan geçmesine izin verir.

Basamaklı koordinatörlerle bir şema oluşturmak, “Koordinatörün Arkasında” modunda koordinatörler kurmakla sınırlı değildir. Aynı şema, "Bağlantı Sunucusu üzerinden tüm trafik" ayarıyla dinamik NAT koordinatörü modu kullanılarak oluşturulabilir. Gelecek sürümlerde, kademeli devreler oluşturmak için yalnızca bu koordinatör modunun kullanılması planlanmaktadır.

4.3 Koordinatörün güvenlik duvarı üzerinden bağlanması "Statik adres çevirisi ile"

Yerel ağın kenarında statik adres çeviri kurallarını yapılandırma yeteneğine sahip bir üçüncü taraf güvenlik duvarı zaten kuruluysa, arkasına ağ arabirimlerinin özel adreslerine sahip bir koordinatör yerleştirebilir ve güvenlik duvarı modunu “Statik adres çevirisi ile” ayarlayabilirsiniz. " üstünde. Koordinatörün ağ arayüzlerinin her biri, statik çeviri kuralları ile ayrı bir güvenlik duvarı aracılığıyla belirli bir ağa bağlanabilir. Bu koordinatör aracılığıyla yerel ağdaki diğer ViPNet düğümleri ve açık düğümlerin, dışındaki düğümlerle etkileşimi sağlanacaktır. Statik adres çeviri kuralları güvenlik duvarında yapılandırılmalıdır:

Koordinatör üzerinde belirtilen trafik kapsülleme portuna uygun olarak paketleri dış ağdan koordinatörün adresine iletmek.

• Koordinatörün kaynak adresi ve kapsülleme bağlantı noktasının belirtildiği dış ağa UDP paketlerinin iletilmesi.

Koordinatörün "Statik adres çevirisi ile" modunda çalışması

Bu moddaki koordinatör, gerçek bir harici güvenlik duvarı olmadığında bile başarıyla çalışır. Bu nedenle, bu mod varsayılan olarak koordinatörlerde ayarlanmıştır.

4.1 Güvenlik duvarı modu "Dinamik adres çevirisi ile"

Koordinatör, dinamik adres çevirisi ile güvenlik duvarları aracılığıyla harici ağlara bağlanan bir yerel ağın ucuna kurulursa, güvenlik duvarının arkasındaki çalışma modunu "Dinamik adres çevirisi ile" olarak ayarlamanız gerekir.

Bağlantıları başlatmak için koordinatör harici ağdan mevcut olmadığından, harici ağdan erişilebilen koordinatörlerden biri (“Statik adres çevirisi ile” veya “Güvenlik duvarı kullanmadan” modunda çalışır) bağlantı sunucusu olarak atanmalıdır. BT. Bağlantı sunucusu, başka herhangi bir düğümden (güvenli bir ağdaki bağlantıları dikkate alarak) böyle bir koordinatörün arkasındaki yerel ağ kaynaklarına inisiyatif bağlantı imkanı sağlayacaktır.

Bu moddaki koordinatörün bağlantı sunucusu aracılığıyla harici ağdan erişilebilir olması nedeniyle, arkasındaki yerel ağdaki istemciler ve tünelli kaynaklar, diğer herhangi bir modda koordinatörün arkasında olduğu gibi, diğer düğümler tarafından tam olarak kullanılabilir durumdadır. Koordinatörün bu modda bağlantı sunucusu aracılığıyla çalışması, yukarıda açıklanan NAT cihazının arkasındaki istemcinin çalışmasına benzer ve bağlantı sunucusunun katılımı olmadan "doğrudan" mesaja gitmenizi sağlar (ayrıntılar için). İstemcilerin bağlantı sunucusu aracılığıyla çalıştırılması için bkz. "Dinamik NAT ile cihazlar aracılığıyla İnternet'e bağlanan iki düğümün bağlanması").

"Dinamik adres çevirisi ile" modunda koordinatörün çalışması, bir NAT cihazının arkasındaki bir istemcinin çalışmasına benzer: koordinatörün, bağlantı sunucusu aracılığıyla harici ağdan erişilebilir olması garanti edilir. Kolaylık olması açısından, şekil, aynı zamanda ilk bağlantı kurulumunda yer alan uzak istemcinin bağlantı sunucusunu göstermemektedir.

Koordinatörün ayarlarında "Tüm trafik üzerinden bağlantı sunucusu" seçeneğini etkinleştirirseniz, "Koordinatörün arkasında" moduna benzer kademeli şemalar oluşturabilirsiniz.

5. Açık kaynakların IP trafiğinin tünellenmesi

Yerel ağda trafiğinin korunması gerekmeyen yerel ağ ana bilgisayarlarını sanal bir ağa dahil etmek için, koordinatör bir tünel sunucusu (VPN ağ geçidi) görevi görür:

IP trafiğini ViPNet ağına aktarmak, açık tünelli düğümlerin trafiğini kapsüllemek ve şifrelemek için bir ağ geçidi görevi görür.

Herhangi bir IP protokolü için tünelli düğümlerin uzak düğümlerle etkileşimini sağlar. Etkileşen düğümlerin yerel adreslerinin tutarlı olup olmadığı önemli değildir. ViPNet ağındaki sanal adreslerin teknolojisi sayesinde, aynı IP adreslerine sahip düğümler etkileşime girebilir (bkz. "ViPNet ağındaki sanal adresler"), bu nedenle adresleme anlaşması gerekli değildir.

Kapsüllenmiş trafiği IP adresi adına alıp ileterek korunan yerel ağın adres yapısını gizler.

Açık tünelli kaynakları herhangi bir uzak istemci, koordinatör veya uzak bir yerel ağın tünelli düğümleri ile bağlamak için, koordinatörleri ağa bağlamak için yukarıda açıklanan tüm şemalar mevcuttur. Bu, karmaşık bir topolojiye sahip dağıtılmış bilgi ağlarında ViPNet sanal ağının tüm avantajlarını kullanmanızı sağlar.

Bu koordinatörün tünel açacağı açık düğümler, koordinatörün ayarlarında veya ViPNet Yönetici kontrol uygulamasında ayrı adresler veya aralıklar olarak belirtilebilir.

6. ViPNet ağındaki sanal adresler

6.1 Sanal adresler nasıl çalışır?

ViPNet teknolojisi, alt ağların IP adreslerini müzakere etmeden özel IP adreslerine sahip korumalı kaynaklar arasında etkileşim sağlar. Uzak taraflar, korunan kaynakların aynı özel IP adreslerini ve alt ağlarını kullanabilir.

Bu olasılığı sağlamak için, her bir ViPNet düğümünde, bağlantılı olduğu diğer tüm ViPNet düğümleri için çakışmayan sanal adresler otomatik olarak oluşturulur:

İstemciler ve koordinatörler için, gerçek adresleri olduğu kadar çok sanal adres oluşturulur.

Uzak koordinatörler tarafından tünellenen düğümlerin bireysel adresleri veya adres aralıkları için örtüşmeyen sanal adresler ve aralıklar oluşturulur.

Her düğüm, diğer düğümler ve tünelledikleri cihazlar için kendi benzersiz sanal adres kümesini oluşturur.

Düğümlerin sanal adresleri, gerçek adreslerine bağlı değildir ve ViPNet Yönetici kontrol uygulamasında kendilerine atanan benzersiz ViPNet düğüm tanımlayıcılarına bağlıdır. Uzak bir ViPNet düğümünün IP adresini değiştirirseniz (bu, mobil bilgisayarlar, cihazlar ve yapılandırılmış DHCP-istemci hizmetine sahip bilgisayarlar için tipiktir), bu düğümde oluşturulan sanal adresi değişmez. Bu özellik, bir ana bilgisayarın sanal adresiyle güçlü bir şekilde kimliğini doğrulamak için uygulamalarda kullanılabilir.

6.2 Görünürlük adresleri

Her ViPNet düğümü, bu düğümün bağlı olduğu tüm ViPNet düğümlerinin gerçek IP adreslerinin listelerini ve ayrıca koordinatörler tarafından tünellenen düğümlerin IP adreslerinin listelerini bilir. Düğüm bu adresleri farklı şekillerde alır:

1. Diğer istemcilerin ve koordinatörlerin gerçek adreslerinin listeleri, ViPNet Yönetici kontrol uygulamasından ve ViPNet trafik dinamik yönlendirme protokolünün çalışması yoluyla hizmet mesajlarındaki düğüme gönderilir (bkz. "Dinamik Yönlendirme Protokolü").

2. Uzak koordinatörler tarafından tünellenen düğümlerin gerçek adreslerinin listeleri, ViPNet Yönetici kontrol uygulamasından hizmet mesajlarındaki düğüme gönderilir.

3. Şifreli trafik, gerçek adresi daha önce ViPNet Yöneticisinden veya dinamik yönlendirme protokolü (madde 1 ve 2) aracılığıyla alınmamış bir düğümden geliyorsa, düğüm, şifresi çözülen paketin kaynak IP adresini bu paketin gerçek adresi olarak kaydeder. düğüm.

Yukarıda belirtildiği gibi, gerçek adresler benzersiz sanal adreslerle eşleştirilir. Bazı uzak düğümlerdeki bir kaynakla etkileşim kurmak için istemciler, koordinatörler ve tünelli düğümler üzerindeki uygulamalar, görünürlük adresini (uzak düğümün gerçek veya karşılık gelen sanal adresi) kullanmalıdır. Belirli bir düğümdeki bir düğümün görünürlük adresi olarak hangi adresin (gerçek veya sanal) kullanılması gerektiği, o düğümdeki ayarlar tarafından belirlenir.

Kullanıcıların ve yöneticilerin, görünürlük adresi olarak hangi adresin kullanıldığını önemsemelerine ve uygulamalarda ayarlamalarına gerek yoktur. Standart ad hizmetlerini (DNS hizmetleri) veya SCCP, SIP, H.323 ve diğer hizmet protokollerini (IP telefonu gibi) kullanan multimedya uygulamalarını kullanan uygulamalar, karşı taraftan doğru IP adresini otomatik olarak alacaktır. Bu protokollerin paket gövdelerinde uygulamalara ihtiyaç duydukları kaynakların IP adresleri verilir. İstemciler ve koordinatörler üzerindeki ViPNet yazılımı, bu protokollerin paketlerini işler: gönderildiklerinde, verilen IP adresine sahip olan ViPNet düğümünü tanımlayan kapsüllenmiş paketlere ek bilgiler ekler. Örneğin, bir DNS sorgusuna yanıt gönderirken, adı istenen korunan kaynağın IP adresini tanımlayan bilgiler eklenir. Bir paket alındığında, bu bilgi, ayıklanan paketin gövdesindeki IP adresini gerekli kaynağın gerçek görünürlük adresiyle (bu düğümdeki görünürlük adresi) değiştirmenize olanak tanır. Uygulamanın alınan adresi, uzak bir kullanıcıyla bir görüşme düzenlemek, Exchange postası ile çalışmak, web portallarına ve diğer kaynaklara güvenli modda adla erişim sağlamak için kullanılır.

Diğer düğümlerden gelen şifresi çözülmüş paketleri işlerken, kaynak adresini bu düğümdeki bu düğümlerin görünürlük adresiyle değiştirirler. Sonuç olarak, düğümün kendisindeki veya tünelli düğümlerindeki uygulamalar, dönüş trafiğini doğru görünürlük adresine gönderir. Bu tür trafik şifrelenecek ve hedef ana bilgisayara iletilecektir.

7. Birden çok ağ arabirimine sahip koordinatörlerin trafik yönlendirmesi

ViPNet koordinatörü, farklı alt ağlara bağlı isteğe bağlı sayıda fiziksel veya sanal arabirime sahip olabilir. Her alt ağın yanında açık tünelli kaynaklar olabilir.

Uzak koordinatörlerin arkasında bulunan kaynaklara bağlanmak için farklı alt ağlar aracılığıyla birkaç alternatif iletişim kanalının kullanımını yapılandırabilirsiniz. Bunu yapmak için, bu alt ağlardaki uzak koordinatörlere uygun erişim adreslerini ayarlamanız ve gerekirse bunların kullanım önceliğini belirleyen metrikler ayarlamanız gerekir.

Koordinatör veya onun tarafından tünellenen kaynaklar üzerinde çalışan uygulamalar, paketlerini görünürlük adresleriyle uzak korunan kaynakların adresine gönderir: uzak düğümlerin gerçek adresleri (kural olarak, bunlar bulundukları yerel ağlarda verilen özel IP adresleridir) veya karşılık gelen otomatik olarak atanan sanal adreslere. Koordinatörün işletim sistemi, trafiği bu adresler için mevcut rotalara göre yönlendirir.

Ancak, özel adreslere veya bunlara karşılık gelen sanal adreslere sahip çoklu uzak alt ağların tümü için yolları yapılandırmaya gerek yoktur; bu, sanal adreslerin tek bir alt ağdan tahsis edilmesi durumunda özellikle zor olacaktır. ViPNet yazılım sürücüsü, harici erişim adresleri için belirtilen rotaya uygun olarak trafiğin gerekli arabirime yönlendirilmesini bağımsız olarak sağlar.

Yani, koordinatörde, harici yönlendirilebilir ağlara bir varsayılan rota ve diğer gerekli rotaları yapılandırmak yeterlidir. Bu, standart yönlendiriciler için tipik bir ayar kümesidir.

8.Veri bağlantı katmanında açık kaynakların trafiğinin tünellenmesi (koordinatörler L2 kodlayıcı L2 kodlayıcı modunda çalışır)

HW tipi koordinatörler L2 kodlayıcı moduna ayarlanabilir (L2OverIP bağlantı katmanında tünelleme teknolojisi). Bu moddaki koordinatörler, birkaç (32'ye kadar) uzak yerel ağın sınırlarına kurulur ve bunları tek bir yerel ağda birleştirir. Bu LAN'lardaki düğümler, aynı yayın etki alanındalarmış gibi iletişim kurar (doğrudan MAC adresi görünürlüğü ile yönlendirme yok).

L2 kodlayıcı modundaki koordinatör, L2 adaptöründe alınan Ethernet çerçevelerini sınırlarındaki benzer L2 kodlayıcılar aracılığıyla uzak ağlara ileten sanal bir anahtar olarak çalışır:

yayın (özellikle ARP istekleri) ve çok noktaya yayın çerçeveleri - birleştirilen tüm ağlara;

tek noktaya yayın çerçeveleri - sanal anahtarın MAC adreslerinin birikmiş tablosuna göre belirli bir ağa.

L2 bağdaştırıcısı tarafından alınan trafiğin daha yüksek düzeyinin (IP veya diğer) protokolü önemli değildir.

Koordinatör Ethernet çerçevelerini işler ve IP paketleri arasında ayrım yapmaz. Bu nedenle, açık kaynak IP trafiğini tünellemek için kullanılamaz (bkz. "Açık Kaynak IP Trafiğini Tünel Açma").

Bir L2 bağdaştırıcısında yakalanan bir Ethernet çerçevesi, önce istenen koordinatörün hedef adresiyle basit bir IP paketine paketlenir. Yayın Ethernet çerçevesi, diğer yerel ağların koordinatörlerinin hedef adresleri ile birkaç IP paketinde çoğaltılır. Bu tür her bir IP paketi, ilgili koordinatör ile iletişim anahtarı kullanılarak şifrelenir, standart bir ViPNet paketinde kapsüllenir ve harici bir arayüz aracılığıyla gerekli koordinatöre gönderilir. Alım sırasında orijinal Ethernet çerçevesi alınır ve yerel ağa gönderilir.

Koordinatörler VLAN teknolojisini destekler (802.1Q):

L2 kodlayıcı modundaki koordinatör, etiketlemeyi sürdürürken etiketli çerçeveleri diğer segmentlere iletebilir.

Koordinatörün L2 bağdaştırıcısı üzerinde, VLAN'daki konumlarını dikkate alarak, uzak segmentlerdeki düğümlerle L2 tüneli üzerinden çalışacak sanal VLAN arayüzleri oluşturabilirsiniz.

EtherChannel teknolojisini kullanarak birkaç koordinatörü farklı portlar üzerinden harici bir anahtara bağlayarak yerel ağlar arasındaki L2 kanalının performansını artırabilirsiniz. Üç HW2000 koordinatöründen oluşan böyle bir kümenin testleri, 10 Gb / s'lik bir performans gösterdi (koordinatörlerin sayısıyla doğru orantılı olan performans artışı). Daha fazla ayrıntı için "ViPNet Coordinator HW Cluster ile Veri Merkezi Koruması" başlıklı makaleye bakın https://www.anti-malware.ru/analytics/Technology_Analysis/ViPNet_Coordinator_HW .

Çözüm

Şeffaf olmayan adresleme ile IP ağlarında bilgisayarların güvenli bir şekilde bağlanmasını organize etmek için ViPNet teknolojik çözümlerini kullanmanın dikkate alınan yöntemleri, bugün bu alanda ortaya çıkan tüm pratik ihtiyaçları karşılamaktadır.

VPN trafiğinin dinamik olarak yönlendirilmesine yönelik protokolün çalışması nedeniyle, en karmaşık ağ yapılandırmalarında bile ViPNet düğümlerinin kullanıcılar ve yöneticiler tarafından yapılandırılması en aza indirilir veya hiç gerekli değildir.

Vladimir Ignatov

Küresel İnternet trafiği 2018 yılına kadar 1,6 zettabayta ulaşacak. Akıllı arabalar da dahil olmak üzere Ultra-HD/4K video ve makineden makineye iletişim teknolojilerinin yaygınlaşması büyümenin ana itici güçleri olacaktır.

Cisco'nun Görsel Ağ Gelişimi Endeksi: Küresel Tahmin ve Hizmet Dağıtımı 2013-2018'e dayanmaktadır. (Cisco VNI), 4 yıl içinde küresel IP trafiği neredeyse üç katına çıkacak. Bu, İnternet kullanıcılarının ve çeşitli cihazların sayısındaki artış, geniş bant hızlarındaki artış ve video görüntüleme sayısı nedeniyle olacaktır. 2018 yılına kadar sabit ve mobil bağlantılardan geçen yıllık küresel IP trafiği hacminin 1,6 zettabayta* ulaşması bekleniyor, yani. bir buçuk trilyon gigabayttan fazla. Bu, 1984 ile 2013 yılları arasında dünya çapında üretilen 1,3 zettabaytlık IP trafiğinden daha fazladır.

Yeni başlayan Dünya Kupası maçlarının yayınını on milyonlarca taraftar internet üzerinden izleyecek. Video akışı ve IP oyunları, Brezilya'daki aylık trafiğin üç katı olan 4,3 eksabayt İnternet trafiği oluşturabilir. Ayrıca, her stadyumda ve maça giden seyirciler tarafından oluşturulan internet trafiğinin de şu anda Brezilyalıların sahip olduğu tüm akıllı telefonların yoğun saatlerde** oluşturduğu ortalama trafik miktarını aşacağı tahmin ediliyor.

Küresel IP trafiğinin 2018 yılına kadar ayda 132 eksabayta ulaşması bekleniyor. Aynı miktarda trafik üretebilir:

• Dünya Kupası final maçı sırasında aynı anda 8,8 milyar ekrana iletilirse, ultra yüksek tanımlı (Ultra-HD/4K) video akışı;
• Game of Thrones 4. Sezonu yüksek tanımlı (HD) veya isteğe bağlı video kullanarak kesintisiz olarak 1,5 milyar ultra yüksek tanımlı izleyen 5,5 milyar izleyici;
• 24 milyar ekranda aynı anda ultra yüksek çözünürlükte yayınlanan House of Cards'ın 3. Sezonu;
• 940 katrilyon metin mesajı;
• 4.5 trilyon YouTube klibi.

Önümüzdeki yıllarda, IP trafiğinin bileşimi önemli ölçüde değişecek. 2018 yılına kadar, çoğu ilk kez kişisel bilgisayarlarla değil, diğer cihazlarla ilişkilendirilecek. Ayrıca, ilk kez Wi-Fi trafiği kablolu trafiği geçecek ve yüksek tanımlı video trafiği geleneksel video trafiğini aşacak.

Her Şeyin İnterneti de ivme kazanıyor ve 2018 yılına kadar makineden makineye iletişim modüllerinin sayısı insan sayısına eşit olacak. Yani, her "akıllı" araba için neredeyse 4 bağlantı olacak.

Cisco'da ürün ve çözüm pazarlamadan sorumlu başkan yardımcısı Doug Webster, "9 yıl önce yayınlanan türünün ilk raporunda, zettabyte'ı küresel IP trafiği büyümesi için bir ölçüt olarak belirledik" dedi. - Bugün zaten zettabayt çağında yaşıyoruz ve inanılmaz endüstri değişikliklerine tanık oluyoruz. Hem bugün hem de yakın gelecekte hizmet sağlayıcılar için önemli fırsatlar sunan bu tahminde vurgulanan temel eğilimler arasında Her Şeyin İnterneti'nin uygulanması, ağ mobilitesine yönelik talepteki artış ve ultra yüksek çözünürlüklü videonun ortaya çıkışı yer alıyor. ”

Küresel Trafik Büyüme Tahminleri ve Temel Hizmet Dağıtımı Sürücüleri

IP trafiği

2018 yılına kadar, kişisel bilgisayarlar olmadan trafiğin çoğundan mobil ve giyilebilir cihazlar sorumlu olacak. PC olmayan cihazlar 2013 yılında IP trafiğinin %33'ünü oluştururken, 2018'de bu payları %57'ye yükselecek. PC trafiğinde yıllık artış %10 olurken, diğer cihazlar ve bağlantılar daha yüksek bir oranda büyüyecek: TV için %18, tabletler için %74, akıllı telefonlar için %64 ve makineden makineye (M2M) modüller için %84 .

Yoğun saatlerde trafik, normal İnternet trafiğinden daha hızlı büyür. 2013 yılında, yoğun saatlerde İnternet trafiği %32, günün diğer saatlerinde trafik ise %25 arttı.

2013 yılında, kentsel ağlar üzerinden, omurga bağlantılarından daha fazla trafik iletildi. 2013-2018 döneminde. kentsel ağlardaki trafik, omurga bağlantılarındakinden neredeyse iki kat daha hızlı büyüyecek. Bu kısmen, 2018 yılına kadar içerik dağıtım ağlarındaki İnternet trafiğinin beklenen iki katına çıkmasından kaynaklanmaktadır.

IP videosu

2018 itibariyle, IP videonun toplam IP trafiğindeki payı %79'a yükselecek (2013'te %66 idi).

2018 yılına kadar ultra yüksek çözünürlüklü videonun toplam IP trafiğindeki payı 2013 yılına göre %0,1 artarak %11'e ulaşacak. Yüksek tanımlı videonun payı 2013'te %36'dan 2018'de %52'ye yükselirken, standart tanımlı video toplam IP trafiğinin %64'ünden %37'sine düşecek.

Erişim türlerine göre IP trafiği

2018 itibariyle, Wi-Fi ve mobil cihazlar IP trafiğinin %61'ini oluşturacak. Wi-Fi %49, hücresel ağlar - %12 olacak. 2018 itibariyle, sabit trafik, toplam IP trafiğinin yalnızca %39'unu oluşturacaktır. Karşılaştırma için: 2013'te Wi-Fi'nin payı %41, hücresel trafik - %3, sabit trafik - %56 idi.

2018 yılına kadar Wi-Fi ve mobil cihazlar İnternet trafiğinin %76'sını oluşturacak. Wi-Fi% 61, hücresel ağlar -% 15 olacak. 2018 yılına kadar sabit trafik, toplam İnternet trafiğinin yalnızca %24'ünü oluşturacaktır. Karşılaştırma için: 2013'te Wi-Fi'nin payı %55, hücresel trafik - %4, sabit trafik - %41 idi.

Cihazlar ve bağlantılar

2018 itibariyle, gezegendeki her insan için ortalama 2,7 ağa bağlı cihaz veya bağlantı olacak. 2013 yılında bu rakam kişi başına 1,7 idi.

Küresel makineler arası bağlantı sayısı 7,3 ​​milyar veya kişi başına neredeyse bir bağlantı olacaktır (2018 yılına kadar dünya nüfusunun 7,6 milyar olacağı varsayılırsa).

IPv6 özellikli sabit ve mobil cihazların sayısı 2013'te 2 milyardan 2018'de 10 milyara yükselecek.

Geniş bant hızlarının büyümesi

Küresel geniş bant hızı 2013 sonunda 16 Mbps'den 2018'de 42 Mbps'ye yükselecek.

Geniş bant bağlantılarının çoğunluğu (yaklaşık %55) 2018 yılına kadar 10 Mbps'yi aşacaktır. Japonya ve Güney Kore'de ortalama geniş bant hızı 2018'e kadar 100 Mbps'ye yaklaşacak.

Gelişmiş hizmetlerin dağıtımı

Konut sektöründe en hızlı büyüyen hizmet, 2013-2018 döneminde %10'luk ortalama yıllık büyüme ile çevrimiçi video olacaktır. kullanıcı sayısı 1,2'den 1,9 milyar kişiye yükselecek.

Tüketici segmenti, 2013-2018 döneminde %36'lık bir CAGR ile lokasyon bazlı mobil hizmetlerde en hızlı büyümeyi yaşayacak. bu tür hizmetlerin kullanıcılarının sayısı 236 milyondan bir milyardan fazla kişiye yükselecek.

İş segmentinde en hızlı büyüyen İnternet hizmeti, 2013-2018 döneminde yıllık ortalama yüzde 45 artışla kişisel cihazlar ve masaüstü bilgisayarlar kullanılarak yapılan video konferans olacaktır. kullanıcı sayısı 37 milyondan 238 milyona çıkacak.

Ülke ve bölgeye göre tahminler

2018 yılına kadar, en büyük IP trafiği hacmi - ayda 47,7 eksabayt - Asya-Pasifik bölgesinde oluşturulacak. Cihazların ve bağlantıların çoğunluğunu oluşturan dünyanın en kalabalık bölgesi, 2018 boyunca trafik açısından en üst sıradaki yerini koruyacak.

2013-2018 döneminde Orta Doğu ve Afrika'da. IP trafiğinin en yüksek büyüme oranları korunacaktır (yıllık ortalama %38 artışla beş kat artış).

2018 itibariyle, en büyük trafik hacmine sahip ülkeler Amerika Birleşik Devletleri ve Çin olacak (sırasıyla ayda 37 ve 18 eksabayt).

2013-2018 döneminde IP trafiğinde en hızlı büyüme. Hindistan ve Endonezya'da (sırasıyla yüzde 39 ve yüzde 37 ortalama yıllık büyüme) görülecektir.

Tüm bunlardan servis sağlayıcılar için ne çıkar?

Servis sağlayıcı ağlarının gelişmiş güvenlik ve zekaya ihtiyacı olacaktır. Sabit ve mobil ağlara erişmek için kimlik doğrulaması gerektiren artan sayıda tablet, akıllı telefon ve makineden makineye cihaza uyum sağlamak zorunda kalacaklar.

Yüksek tanımlı ve ultra yüksek tanımlı video gibi video hizmetlerinin evrimi, hizmet sağlayıcıların bant genişliğini ve ölçeklenebilirliği artırmasını gerektirebilir. Konut, mobil ve iş sektörleri, her türden ağ ve cihaz aracılığıyla gelişmiş video hizmetlerine erişim için güçlü bir talep görmeye devam edecek. Burada anahtar başarı faktörleri hizmet kalitesi, kullanım kolaylığı ve fiyat olacaktır.

Yüksek tanımlı video konferansı ve web video konferansı gibi iş segmentinde ve talep üzerine iş videosu gibi hizmetlerin sürekli çoğalması, ağ sanallaştırmasında ve video iletimi için İnternet'in kullanımında artan bir büyümeyi tetikleyebilir. hem hizmet sağlayıcılar hem de bağımsız hizmet sağlayıcılar (over-the-top sağlayıcılar, OTT) için belirli sorunlar.

4G ağlarının büyümesi ve ilgili hizmetlerin yayılması, mobil kullanıcılar sabit ve mobil ağlarında benzer hizmetler ve hizmet kalitesi talep etmeye devam ettikçe hızlanabilir.

IP ağları, sürekli gelişen yeni ve gelişen sabit ve mobil ağ uygulamalarını destekleyecek zekaya ve esnekliğe sahip olmalıdır. Hizmetlerini farklılaştırmak için birçok hizmet sağlayıcı, uygulama geliştiricilerle aktif olarak işbirliği yapıyor.

Herhangi bir yönetici er ya da geç yönetimden bir talimat alır: "ağa kimin gittiğini ve ne kadar indirdiğini hesaplayın." Sağlayıcılar için, "herkesin içeri girmesine izin verme, ödeme alma, erişimi kısıtlama" görevleriyle desteklenir. Ne sayılacak? Nasıl? Neresi? Çok fazla parçalı bilgi var, yapılandırılmamışlar. Acemi yöneticiyi, ona genel bilgiler ve malzemeye faydalı bağlantılar sağlayarak sıkıcı aramalardan kurtaralım.
Bu yazıda ağdaki trafiğin toplanması, muhasebeleştirilmesi ve kontrolünün organize edilmesinin ilkelerini açıklamaya çalışacağım. Sorunun sorunlarını ele alacağız ve ağ cihazlarından bilgi almanın olası yollarını listeleyeceğiz.

Bu, trafik ve BT kaynaklarının toplanması, muhasebeleştirilmesi, yönetimi ve faturalandırılmasına ayrılmış bir dizi makaledeki ilk teorik makaledir.

İnternet erişim yapısı

Genel olarak, ağ erişim yapısı şöyle görünür:

• Dış kaynaklar - kontrol ettiğiniz bir ağa ait olmayan tüm siteler, sunucular, adresler ve diğer şeylerle birlikte İnternet.
• Erişim cihazı bir yönlendirici (donanım veya PC tabanlı), anahtar, VPN sunucusu veya hub'dır.
• Dahili kaynaklar - ağdaki çalışmaları dikkate alınması veya kontrol edilmesi gereken bir dizi bilgisayar, alt ağ, abone.
• Yönetim veya muhasebe sunucusu - özel yazılım çalıştıran bir cihaz. Bir yazılım yönlendiricisi ile işlevsel olarak birleştirilebilir.

Bu yapıda ağ trafiği, erişim aygıtı aracılığıyla dış kaynaklardan iç kaynaklara ve bunun tersi de geçerlidir. Trafik bilgilerini yönetim sunucusuna gönderir. Kontrol sunucusu bu bilgileri işler, veritabanında saklar, görüntüler, kilit komutları verir. Ancak, erişim cihazlarının (yöntemleri) ve toplama ve yönetim yöntemlerinin tüm kombinasyonları uyumlu değildir. Çeşitli seçenekler aşağıda tartışılacaktır.

Ağ trafiği

Başlangıç ​​olarak, "ağ trafiği" ile ne kastedildiğini ve kullanıcı veri akışından hangi yararlı istatistiksel bilgilerin çıkarılabileceğini tanımlamak gerekir.
IP sürüm 4, şu ana kadar baskın ağlar arası iletişim protokolü olmaya devam ediyor. IP protokolü, OSI modelinin (L3) 3. katmanına karşılık gelir. Gönderici ve alıcı arasındaki bilgiler (veriler), bir başlık ve bir "yük" içeren paketler halinde paketlenir. Başlık, paketin nereden geldiğini ve nereden (gönderen ve hedef IP adresleri), paket boyutunu, yük tipini tanımlar. Ağ trafiğinin büyük kısmı UDP ve TCP veri yüklerine sahip paketlerden oluşur - bunlar Katman 4 (L4) protokolleridir. Adreslere ek olarak, bu iki protokolün başlığı, veri ileten hizmetin (uygulamanın) türünü belirleyen bağlantı noktası numaralarını içerir.

Bir IP paketini kablolar (veya radyo) üzerinden iletmek için ağ cihazları, onu bir Katman 2 (L2) protokol paketine "sarmaya" (kapsüllemeye) zorlanır. Bu türün en yaygın protokolü Ethernet'tir. "Tele" fiili aktarım 1. seviyededir. Genellikle, erişim cihazı (yönlendirici) paket başlıklarını 4.'den daha yüksek bir seviyede analiz etmez (akıllı güvenlik duvarları bir istisnadır).
Veri paketlerinin L3 ve L4 başlıklarından adresler, bağlantı noktaları, protokoller ve uzunluk sayaçları alanlarından gelen bilgiler, trafik muhasebesi ve yönetiminde kullanılan "kaynak malzemeyi" oluşturur. Aktarılacak gerçek bilgi miktarı, IP başlığının Uzunluk alanındadır (başlığın uzunluğu dahil). Bu arada, MTU mekanizması nedeniyle paket parçalanması nedeniyle, iletilen toplam veri miktarı her zaman yük boyutundan daha büyüktür.

Bu bağlamda bizi ilgilendiren paketin IP ve TCP/UDP alanlarının toplam uzunluğu toplam paket uzunluğunun %2...10'u kadardır. Tüm bu bilgileri toplu olarak işler ve saklarsanız, yeterli kaynak olmayacaktır. Neyse ki, trafiğin büyük çoğunluğu, harici ve dahili ağ cihazları arasında "akışlar" olarak adlandırılan bir dizi "diyalogdan" oluşacak şekilde yapılandırılmıştır. Örneğin, tek bir e-posta iletme işlemi (SMTP protokolü) dahilinde, istemci ile sunucu arasında bir TCP oturumu açılır. Sabit bir parametre seti ile karakterize edilir. (Kaynak IP adresi, Kaynak TCP bağlantı noktası, Hedef IP adresi Hedef TCP bağlantı noktası). Bilgi paketlerini paket bazında işlemek ve depolamak yerine, akış parametrelerinin (adresler ve bağlantı noktaları) ve ayrıca ek bilgilerin - her yönde iletilen paketlerin sayısı ve toplam uzunluklarının, isteğe bağlı olarak oturum süresi, yönlendirici arayüzünün saklanması çok daha uygundur. endeksler, ToS alan değeri vb. Bu yaklaşım, oturumun sona erdiği anı açıkça engellemenin mümkün olduğu bağlantı yönelimli protokoller (TCP) için faydalıdır. Ancak, oturuma yönelik olmayan protokoller için bile, örneğin bir zaman aşımı yoluyla bir akış kaydını toplamak ve mantıksal olarak tamamlamak mümkündür. Aşağıda, trafik akışlarıyla ilgili bilgileri günlüğe kaydeden kendi faturalandırma sistemimizin SQL veritabanından bir alıntı bulunmaktadır:

Erişim cihazının yerel ağdaki bilgisayarlar için tek bir harici, genel IP adresi kullanarak İnternet erişimini organize etmek için adres çevirisi (NAT, maskeleme) gerçekleştirdiği duruma dikkat edilmelidir. Bu durumda, özel bir mekanizma, dinamik çeviri tablosuna göre dahili (İnternette yönlendirilemez) adresleri değiştirerek, trafik paketlerinin IP adreslerinin ve TCP / UDP bağlantı noktalarının değiştirilmesini gerçekleştirir. Bu konfigürasyonda, dahili ağ ana bilgisayarlarındaki verileri doğru bir şekilde kaydetmek için, istatistiklerin, çeviri sonucunun dahili adresleri henüz “anonimleştirmediği” bir şekilde ve yerde toplanması gerektiği unutulmamalıdır.

Trafik / istatistik hakkında bilgi toplama yöntemleri

Trafiğin doğrudan erişim cihazının kendisinde (PC yönlendirici, VPN sunucusu), bu cihazdan ayrı bir sunucuya (NetFlow, SNMP) veya "kablodan" (dokunma, SPAN) aktarılmasıyla ilgili bilgileri yakalayabilir ve işleyebilirsiniz. Tüm seçenekleri sırayla analiz edelim.

bilgisayar yönlendiricisi

En basit durumu düşünün - Linux işletim sistemine sahip bir PC'ye dayalı bir erişim cihazı (yönlendirici).

Böyle bir sunucu nasıl kurulur, adres çevirisi ve yönlendirme, çok şey yazıldı. Bir sonraki mantıksal adımla ilgileniyoruz - böyle bir sunucudan geçen trafik hakkında nasıl bilgi edinileceği hakkında bilgi. Üç yaygın yol vardır:

• libpcap kitaplığı kullanılarak sunucu ağ kartından geçen paketlerin durdurulması (kopyalanması)
• yerleşik güvenlik duvarından geçen paketlerin ele geçirilmesi
• paket başına istatistikleri (önceki iki yöntemden biri tarafından elde edilen) toplu bilgi ağı akışına dönüştürmek için üçüncü taraf araçlarının kullanımı

libpcap

İlk durumda, arayüzden geçen paketin filtreden (man pcap-filter) geçtikten sonra bir kopyası, bu kütüphane kullanılarak yazılan sunucudaki bir istemci program tarafından istenebilir. Paket, bir Katman 2 (Ethernet) başlığıyla gelir. Yakalanan bilgilerin uzunluğunu sınırlamak mümkündür (yalnızca başlığındaki bilgilerle ilgileniyorsak). Bu tür programlara örnek olarak tcpdump ve Wireshark verilebilir. libpcap'ın bir Windows uygulaması var. Bir PC yönlendiricisinde adres çevirisi kullanılması durumunda, bu tür bir müdahale yalnızca yerel kullanıcılara bağlı dahili arabiriminde gerçekleştirilebilir. Dış arabirimde, çeviriden sonra IP paketleri, ağın dahili ana bilgisayarları hakkında bilgi içermez. Ancak bu yöntemle, sunucunun kendisinin İnternet'te oluşturduğu trafiği hesaba katmak mümkün değildir (bu, üzerinde bir web veya posta hizmeti çalışıyorsa önemlidir).

libpcap'in çalışması, şu anda tek bir kitaplık kurmaktan ibaret olan işletim sisteminden destek gerektirir. Bu durumda paketleri toplayan uygulama (kullanıcı) programı şunları yapmalıdır:

• gerekli arayüzü aç
• alınan paketlerin içinden geçirileceği filtreyi, yakalanan parçanın boyutunu (snaplen), arabelleğin boyutunu,
• ağ arayüzünü, sadece bu arayüzün MAC adresine gönderilenler için değil, genel olarak geçen tüm paketler için yakalama moduna sokan promisc parametresini ayarlayın.
• alınan her pakette çağrılacak bir işlev (geri arama) ayarlayın.

Seçilen arabirim üzerinden bir paket iletirken, filtreyi geçtikten sonra bu işlev Ethernet, (VLAN), IP vb. içeren bir arabellek alır. başlıklar, toplam boyut snaplen'e kadar. libcap kütüphanesi paketleri kopyaladığı için, onunla geçişlerini engellemek mümkün değildir. Bu durumda, trafik toplama ve işleme programı, örneğin belirtilen IP adresini trafik engelleme kuralına yerleştirmek için bir komut dosyası çağırmak gibi alternatif yöntemler kullanmak zorunda kalacaktır.

güvenlik duvarı

Güvenlik duvarından geçen verileri yakalamak, adres çevirisi çalışırken bile hem sunucunun kendi trafiğini hem de ağ kullanıcılarının trafiğini hesaba katmanıza olanak tanır. Bu durumda ana şey, yakalama kuralını doğru bir şekilde formüle etmek ve doğru yere koymaktır. Bu kural, paketin trafik hesaplama ve kontrol uygulamasının onu alabileceği sistem kitaplığına doğru iletimini etkinleştirir. Linux işletim sistemi için iptables güvenlik duvarı olarak kullanılır ve engelleme araçları ipq, netfliter_queue veya ulog'dur. OC FreeBSD-ipfw için tee veya yönlendirme gibi kurallarla. Her durumda, güvenlik duvarı mekanizması, kullanıcı programıyla aşağıdaki şekilde çalışma yeteneği ile desteklenir:

• Bir kullanıcı programı - bir trafik işleyicisi, bir sistem çağrısı veya bir kitaplık kullanarak kendisini sisteme kaydeder.
• Kullanıcı programı veya harici bir komut dosyası, güvenlik duvarında bir kural belirler ve seçilen trafiği (kurallara göre) işleyicinin içine "sarar".
• Her geçen paket için, işleyici içeriğini bir bellek arabelleği (IP başlıkları vb. ile) şeklinde alır. İşlemden (hesaplama) sonra, program ayrıca işletim sistemi çekirdeğine böyle bir paketle daha sonra ne yapacağını söylemelidir - atın veya Alternatif olarak, değiştirilen paketi çekirdeğe geçirmek de mümkündür.

IP paketi kopyalanmadığından, ancak analiz yazılımına gönderildiğinden, onu "çıkarmak" ve bu nedenle belirli bir türdeki trafiği (örneğin, seçilen yerel ağ abonesine) tamamen veya kısmen kısıtlamak mümkün hale gelir. Ancak, uygulama çekirdeğe kararıyla ilgili yanıt vermeyi durdurursa (örneğin, askıda kalırsa), sunucu üzerinden trafik basitçe engellenir.
Önemli miktarda iletilen trafiğe sahip açıklanan mekanizmaların, sunucu üzerinde, verilerin çekirdekten kullanıcı programına sürekli kopyalanmasıyla ilişkili aşırı bir yük oluşturduğuna dikkat edilmelidir. İşletim sistemi çekirdeği düzeyinde istatistik toplama yöntemi, NetFlow protokolünü kullanarak uygulama programına toplu istatistiklerin verilmesiyle bu dezavantaja sahip değildir.

Net akış

Bu protokol, Cisco Systems tarafından, trafik muhasebesi ve analizi amacıyla yönlendiricilerden trafik bilgilerini dışa aktarmak için geliştirilmiştir. Şu anda en popüler sürüm 5, alıcıya, geçmiş trafik hakkında akış kayıtları adı verilen bilgiler içeren UDP paketleri biçiminde yapılandırılmış bir veri akışı sağlar:

Trafikle ilgili bilgi hacmi, özellikle büyük ve dağıtılmış ağlarda önemli olan trafiğin kendisinden birkaç kat daha küçüktür. Netflow üzerinde istatistik toplarken (ek mekanizmalar kullanmazsanız) bilgi aktarımını engellemek elbette mümkün değildir.
Şu anda, bu protokolün daha da geliştirilmesi popüler hale geliyor - akış kaydı şablonu yapısına dayanan sürüm 9, diğer üreticilerin cihazları için bir uygulama (sFlow). Son zamanlarda, istatistiklerin daha derin seviyelerdeki protokoller üzerinden (örneğin, uygulama türüne göre) iletilmesine izin veren IPFIX standardı kabul edilmiştir.
Netflow kaynaklarının (aracılar, problar) uygulanması, PC yönlendiricileri için hem yukarıda açıklanan mekanizmalara göre çalışan yardımcı programlar (flowprobe, softflowd) biçiminde hem de doğrudan işletim sistemi çekirdeğinde yerleşik olarak (FreeBSD: , Linux: ) mevcuttur. Yazılım yönlendiricileri için netflow istatistik akışı, yönlendiricinin kendisinde yerel olarak alınabilir ve işlenebilir veya ağ üzerinden (iletim protokolü - UDP üzerinden) alıcı cihaza (toplayıcı) gönderilebilir.


Toplayıcı program aynı anda birçok kaynaktan bilgi toplayabilir, çakışan adres boşluklarıyla bile trafiklerini ayırt edebilir. nprobe gibi ek araçların yardımıyla, düzinelerce yönlendirici ile büyük ve dağıtılmış bir ağı yönetirken önemli olan ek veri toplama, akış çatallama veya protokol dönüştürme yapmak da mümkündür.

Netflow dışa aktarma işlevleri, Cisco Systems, Mikrotik ve diğerlerinden yönlendiricileri destekler. Benzer işlevsellik (diğer dışa aktarma protokolleriyle birlikte), tüm büyük ağ ekipmanı üreticileri tarafından desteklenir.

libpcap "dışarıda"

Görevi biraz karmaşıklaştıralım. Erişim cihazınız bir üçüncü taraf donanım yönlendiricisiyse ne olur? Örneğin, D-Link, ASUS, Trendnet vb. Üzerinde, büyük olasılıkla, verileri almak için ek bir yazılım aracı koymak mümkün değildir. Alternatif olarak, bir akıllı erişim cihazınız var, ancak onu yapılandırmak mümkün değil (hak yok veya sağlayıcınız tarafından kontrol ediliyor). Bu durumda, paketleri kopyalamanın "donanım" araçlarını kullanarak, erişim cihazının dahili ağ ile bağlantı noktasında doğrudan trafik hakkında bilgi toplamak mümkündür. Bu durumda, Ethernet paketlerinin kopyalarını almak için kesinlikle özel bir ağ kartına sahip ayrı bir sunucuya ihtiyacınız olacaktır.
Sunucu, yukarıda açıklanan libpcap yöntemine göre paket toplama mekanizmasını kullanmalıdır ve görevimiz, erişim sunucusundan gelen çıktıya benzer bir veri akışını bunun için tahsis edilen ağ kartının girişine göndermektir. Bunun için şunları kullanabilirsiniz:

• Ethernet hub: Paketleri tüm bağlantı noktaları arasında ayrım gözetmeksizin ileten bir aygıt. Modern gerçekliklerde, tozlu bir depoda bir yerde bulunabilir ve bu yöntem önerilmez: güvenilmez, düşük hız (1 Gbps hızında hub yoktur)
• Ethernet - yansıtma özelliğine sahip bir anahtar (yansıtma, SPAN bağlantı noktaları. Modern akıllı (ve pahalı) anahtarlar, tüm trafiği (gelen, giden, her ikisi) uzak (RSPAN) dahil olmak üzere başka bir fiziksel arabirimin, VLAN'ın belirtilen bağlantı noktasına kopyalamanıza olanak tanır )
• Bir yerine iki ağ kartı toplamak için kurulum gerektirebilecek donanım ayırıcı - ve bu, ana sistem kartına ektir.

Doğal olarak, izin veriyorsa, erişim cihazının kendisinde (yönlendirici) SPAN bağlantı noktasını yapılandırabilirsiniz - Cisco Catalyst 6500, Cisco ASA. İşte bir Cisco anahtarı için böyle bir yapılandırma örneği:
oturum 1 kaynak vlan 100'ü izleyin! paketleri nereden alıyoruz
oturum 1 hedef arayüzü Gi6/3'ü izleyin! paketleri nereye gönderiyoruz?

SNMP

Ya bizim kontrolümüzde bir router yoksa, netflow ile iletişime geçme isteği yok, kullanıcılarımızın trafiğinin detayları ile ilgilenmiyoruz. Yönetilen bir anahtar aracılığıyla ağa basitçe bağlanırlar ve her bir bağlantı noktasına düşen trafik miktarını kabaca tahmin etmemiz yeterlidir. Bildiğiniz gibi, uzaktan yönetilen ağ cihazları, ağ arayüzlerinden geçen paket (bayt) sayaçlarını destekler ve görüntüleyebilir. Bunları yoklamak için standartlaştırılmış SNMP uzaktan yönetim protokolünü kullanmak doğru olacaktır. Bunu kullanarak, yalnızca belirtilen sayaçların değerlerini değil, aynı zamanda arayüzün adı ve açıklaması, üzerinden görünen MAC adresleri ve diğer faydalı bilgiler gibi diğer parametreleri de oldukça basit bir şekilde alabilirsiniz. Bu, hem komut satırı yardımcı programları (snmpwalk), grafiksel SNMP tarayıcıları hem de daha karmaşık ağ izleme programları (rrdtools, cacti, zabbix, whats up gold, vb.) tarafından yapılır. Ancak, bu yöntemin iki önemli dezavantajı vardır:

• trafik engelleme yalnızca aynı SNMP kullanılarak arabirim tamamen devre dışı bırakılarak yapılabilir
• SNMP üzerinden alınan trafik sayaçları, Ethernet paketlerinin uzunluklarının toplamını ifade eder (tek noktaya yayın, yayın ve çok noktaya yayın ayrı olarak), daha önce açıklanan araçların geri kalanı ise IP paketlerine göre değerler verir. Bu, Ethernet başlığının uzunluğundan kaynaklanan ek yük nedeniyle (özellikle kısa paketlerde) fark edilir bir tutarsızlık yaratır (ancak bu yaklaşık olarak şu şekilde ele alınabilir: L3_bytes = L2_bytes - L2_packets*38).

VPN

Ayrı olarak, erişim sunucusuna açıkça bir bağlantı kurarak ağa kullanıcı erişimi durumunu dikkate almaya değer. Klasik bir örnek, modern dünyada analogu uzaktan erişim VPN hizmetleri (PPTP, PPPoE, L2TP, OpenVPN, IPSEC) olan eski güzel çevirmeli ağdır.


Erişim cihazı yalnızca kullanıcı IP trafiğini yönlendirmekle kalmaz, aynı zamanda özel bir VPN sunucusu olarak da hareket eder ve içinde kullanıcı trafiğinin iletildiği mantıksal tünelleri (genellikle şifreli) sonlandırır.
Bu trafiği hesaba katmak için, hem yukarıda açıklanan tüm araçları (ve bağlantı noktaları / protokoller tarafından derinlemesine analiz için çok uygundurlar) hem de VPN erişim kontrol araçları sağlayan ek mekanizmaları kullanabilirsiniz. Öncelikle RADIUS protokolünden bahsedeceğiz. Çalışmaları oldukça karmaşık bir konudur. VPN sunucusuna (RADIUS istemcisi) erişim denetiminin (yetkilendirmesinin), nitelikleriyle birlikte geçerli kullanıcıların bir veritabanına (metin dosyası, SQL, Active Directory) sahip özel bir uygulama (RADIUS sunucusu) tarafından kontrol edildiğinden kısaca bahsedeceğiz ( bağlantı hızı kısıtlamaları, atanan IP adresleri). Yetkilendirme işlemine ek olarak, istemci periyodik olarak sunucuya muhasebe mesajları, iletilen bayt ve paketlerin sayaçları dahil olmak üzere şu anda çalışan her VPN oturumunun durumu hakkında bilgi gönderir.

Çözüm

Yukarıda açıklanan trafik bilgilerini toplamanın tüm yöntemlerini birlikte özetleyelim:

Biraz özetleyelim. Uygulamada, yönettiğiniz ağı (istemciler veya ofis aboneleriyle birlikte) bir dizi erişim aracını (yazılım ve donanım yönlendiricileri, anahtarlar, VPN sunucuları) kullanarak harici bir ağ altyapısına bağlamak için çok sayıda yöntem vardır. Bununla birlikte, hemen hemen her durumda, ağ üzerinden iletilen trafik hakkındaki bilgilerin analizi ve kontrolü için bir yazılım veya donanım aracına yönlendirilebileceği bir şema oluşturabilirsiniz. Bu aracın, bireysel istemciler, protokoller ve daha fazlası için akıllı erişim kısıtlama algoritmaları uygulayarak erişim cihazına geri bildirim sağlaması da mümkündür.
Bu, malzeme analizini tamamlar. Çözülmemiş konulardan geriye kalanlar:

• toplanan trafik verilerinin nasıl ve nereye gittiği
• trafik muhasebesi yazılımı
• faturalandırma ile basit bir "sayaç" arasındaki fark nedir
• trafik nasıl sınırlandırılır
• ziyaret edilen web sitelerini kaydetme ve sınırlama

IP trafiğini SDH ağları üzerinden aktarma veya ATM'nin bir alternatifi var mı?

Oleg ALLENOV
AMT Grubu

İnternet gibi yüksek hızlı multimedya ağlarında hangi ulaşım teknolojilerinin ön plana çıkacağı konusunda çok fazla tartışma var. Ve muhaliflerin çoğunluğu oylarını ATM lehine vermiş olsa da, herkes bu görüşe katılmıyor. Aktarım multimedya ağları oluşturmak için başka bir alternatif seçenek de mümkündür - eş zamanlı dijital hiyerarşi (SDH) ağında doğrudan kapsülleme ile IP protokolünü (İnternet Protokolü) kullanmak.

IP 15 yılı aşkın bir süredir kullanılmaktadır, ATM ise nispeten yeni bir protokoldür. Birbirinden farklı üniversite kampüslerinden oluşan birleşik bir bilimsel ağdan gelen IP İnternet'in varlığı sırasında, tüm gezegeni kapsayan devasa bir bilgisayar ağı haline geldi. Sürekli artan İnternet kullanıcılarının sayısı (şimdi milyonlarca) ve artan bant genişliği talepleri Web'i sürdürülemez hale getirmekle tehdit ediyor. Yeni multimedya uygulamaları, genellikle gerçek zamanlı olarak, mevcut bant genişliğine çok daha fazla talepte bulunuyor. Bu, bizi İnternet altyapısını oluşturmaya yönelik mevcut yaklaşımları yeniden gözden geçirmeye zorlar.

İnternetin bant genişliğini artırmak için her şeyden önce yüksek hızlı "taşıma" gereklidir. Bir seçenek, popüler ATM teknolojisini kullanmaktır. Bir taşıma protokolü olarak ATM'nin hem ekipman üreticilerinden hem de son kullanıcılardan giderek daha fazla eleştiri aldığına dikkat edilmelidir. ATM'nin dezavantajlarını daha ayrıntılı olarak analiz etmeye çalışacağız ve İnternet trafiğini taşımanın başka bir yolu lehine argümanları - SONET / SDH protokollerinde TCP / IP protokollerinin doğrudan kapsüllenmesi - ele alacağız.

ATM Teknolojisi

Asenkron Aktarım Modu, ATM, ağ satıcılarına ve hizmet sağlayıcılara, İnternet'in hakim olduğu çok çeşitli multimedya uygulamalarına isteğe bağlı bant genişliği ve garantili hizmet kalitesi sağlayan bir teknoloji olarak sunuldu. Bu nedenle, ATM bileşenlerinin en yeni parçası değil, özellikle İnternet trafiğini taşımak için hedeflenmiş ve geliştirilmemiştir. Yakın gelecekte, Ağın büyük ölçüde ATM kullanıcıları ve LANE (LAN Öykünmesi) istemcilerinden oluşması bekleniyordu, bu da İnternet uygulamalarının sınırsız olasılıklar vaat eden yeni bir taşıma protokolüne kolay ve doğal bir şekilde taşınmasına izin verecekti.

Ancak (belki de yeni çözümlerin yüksek maliyeti veya inorganik yapıları nedeniyle), bazı nedenlerden dolayı bu olmadı. Ayrıca, taşıma protokolleri olarak TCP/IP protokollerinin etkisini artırma eğilimi giderek daha belirgin hale gelmiştir.

Gerçekten de, TCP / IP protokol yığını uzun süredir çalışılmış ve test edilmiştir, oluşturulması ve hata ayıklaması için çok para ve çaba harcanmıştır. IPv4'ün bazı dezavantajları varsa, IPv6'nın gelecek sürümü bunların çoğunu ortadan kaldıracaktır. Bununla birlikte, IPv4'ün mevcut sürümü de birçok kişiye uygundur ve uzmanlara göre birkaç yıl daha dayanabilir. Çok sayıda üretici, IP'yi modern telekomünikasyon altyapısı için umut verici bir taşıma protokolü olarak görüyor. Peki ATM'nin bununla ne ilgisi var?

ATM, ITU-T tarafından geniş bant ISDN (veya B-ISDN) için temel teknoloji olarak önerilmiştir. B-ISDN, esas olarak multimedya trafiğini taşımak için tasarlandığından, ATM, gerçek ağlarda bu tür trafiği desteklemek için iyi bir şekilde konumlandırılmıştır.

Aradan biraz zaman geçti ve telekomünikasyon ekipmanı üreticileri dikkatlerini ATM'ye çevirdi. ATM Forumu, yeni teknolojiyi hayata geçirmek için oluşturuldu. Aynı zamanda, ATM Forum'a verilen görevler, taban tabana zıt özelliklere sahip (multimedya) trafiği destekleyen, belirli bir hizmet kalitesini (QoS) garanti eden ve çok noktaya yayın yayınını destekleyen etkin bir genişletilebilir protokolü standartlaştırmak ve geliştirmekti. Ayrıca bu protokolün mevcut LAN ve WAN teknolojileriyle uyumlu olması gerekir.

ATM teknolojisinin tam da o dönemde var olan teknolojilerin yukarıdaki gereksinimleri karşılayamadığına dair genel inanç nedeniyle bu kadar geniş bir popülerlik kazandığı anlaşılmalıdır.

IP teknolojisi

Öte yandan IP, unutulacak, kullanımdan kaldırılmış bir protokol gibi görünmüyor. Dünya çapında kurulu çok sayıda "Ethernet Üzerinden IP" çözümü vardır ve temelde yeni özellikler veya en azından daha yüksek hızlar vaat etmeden müşterileri ucuz Ethernet "kartlarını" atmaya ve ATM adaptörlerini kurmaya ikna etmek kolay değildir (artış hızda hiçbir şekilde açık değildir).

Kişisel bilgisayarlar için ATM adaptörlerini kullanma deneyimi olan birçok müşterinin 100 Mbps Hızlı Ethernet ağ kartının (Tam Çift Yönlü) en az 155 Mbps ATM adaptörü kadar yavaş olduğu konusunda benimle hemfikir olacağını düşünüyorum. Bunun nedeni, ATM protokolünün daha fazla fazlalığı ve hücrelerin montajı/sökülmesindeki gecikmelerdir. Garantili ATM hizmet kalitesine gelince, pratik olarak LANE'de uygulanmamaktadır ve artık IP trafiğini ATM üzerinden iletmek için AAL5 UBR (maksimum UBR + veya ABR) kullanılmaktadır. Yani QoS hakkında konuşmaya gerek yok.

Kuşkusuz, yeni teknoloji çok çeşitli hizmet düzeylerini desteklemelidir. Bununla birlikte, IP, evrensel ağlar arası iletişim için protokol olarak seçilmiştir ve 1980'lerin ortalarında o zamanki 20.000 bilgisayarlı İnternet'te iyi çalıştı ve bugün birkaç milyon ana bilgisayarı başarıyla bağlamaya devam ediyor. IP Gerçekten Eski mi? ATM taraftarları muhtemelen evet cevabını verecektir.

İnternet protokolleri ailesinin geliştirilmesine ve mevcut duruma getirilmesine büyük fonlar yatırıldı. Yalnızca ATM Forumu değil, aynı zamanda IETF (İnternet Mühendisliği Görev Gücü) de aktiftir - gelişmekte olan yüksek hızlı multimedya ağlarında IP'yi uygulamanın yollarını aramaya devam etmektedir. Çok noktaya yayın yayınını (IGMP, DVMRP, PIM) ve trafik iletimi için kaynak rezervasyonu (RSVP) sağlayan protokolleri desteklemek için protokoller oluşturulmuştur. Gerekli hizmet kalitesine (Etiket Anahtarlama) göre yönlendirme (henüz PNNI kullanımı kadar esnek olmasa da) uygulamak mümkündür ve IETF'de yayınlanmak üzere hazırlanmakta olan MPLS (Çok Protokollü Etiket Anahtarlama) standardı bunu sağlayacaktır. etiket değiştirmeyi destekleyen tüm cihazların birlikte çalışabilirliği ve muhtemelen MPOA'nın (ATM Üzerinden Çok Protokollü) konumunu önemli ölçüde zorlayacaktır.

Peki, yerleşik IP teknolojisini yeni ortaya çıkan ATM ile değiştirmek mantıklı mı?

ATM üzerinden IP

Başlangıçta, IP'yi ATM üzerinden taşıma fikri, ATM'yi mevcut İnternet mimarisine sokmanın olası bir yolu olarak kabul edildi ve ardından IP'nin tamamen yer değiştirmesi yapıldı. Artık ATM'nin IP'nin yerini tamamen alamayacağını anlayarak şu soruyu sorabiliriz: IP trafiğini ATM üzerinden iletmek için neden hala verimli yöntemler geliştirilmedi? Görünüşe göre, ATM'nin İnternet'teki mevcut bant genişliği sorunlarını çözebilecek benzersiz bir hızlı anahtarlama teknolojisi sunduğu düşünülüyor. Ancak gerçekte bazı sorunlar var.

Öncelikle ATM anahtarlarının hemen hemen tüm fiziksel arayüzlerinin (ATM25, TAXI vb. gibi nadir istisnalar dışında) SDH/SONET/PDH çerçeve formatında çalıştığına dikkat edelim. Bu, yaygın olarak kullanılan SDH taşıma ağlarıyla entegrasyonu kolaylaştırmak için yapılır. Ancak, SDH tamamen yokken ve proje tarafından sağlanmadığında bile, kullanıcı trafiğinin iletimine SDH ek yükü eklenir ve bu, en hafif şekilde söylemek gerekirse, ağın hızını ve performansını artırmaz.

ATM'nin asenkron olduğu halde, SDH'nin senkron bir iletim yöntemi olduğuna dikkat etmek de önemlidir. ATM trafiğini SDH taşıma ağları üzerinden iletirken, bir dizi işlevin (örneğin, OA&M) çoğaltılmasından bahsetmeden, eşzamansız hücre aktarım yönteminin tüm avantajlarını kaybederiz.

IP'nin, sırayla SDH aracılığıyla çalışan ATM'de kapsüllenmesi, durumun iyileştirilmesine katkıda bulunmaz. IP değilken ATM protokolü bağlantı yönelimlidir. Bu tutarsızlık ayrıca ek karmaşıklığa ve bir dizi işlevin tekrarına yol açar.

Bu nedenle, protokollerin her biri, IP ve ATM, kendi yönlendirme protokolünü gerektirir. IP ve ATM'nin ortak çalışmasını kontrol etmek için ek kontrol fonksiyonlarına ihtiyaç vardır. Alt katmanlardaki kesin ağ topolojisi bilgisi olmadan, çok noktaya yayın paketlerinin iletimi, sınır yönlendiricilerinde basit kopyalamaya dönüştüğü için, çok noktaya yayın trafik iletiminin verimliliği düşer. Bu tür paketlerin dağıtımı, gerçek bir ağ için optimal olmaktan uzak rotalar boyunca gerçekleştirilir.

Herhangi bir kalifiye ağ uzmanı, LANE teknolojisinin hiçbir şekilde organik ve umut verici olmadığı konusunda hemfikir olacağından, LAN öykünme yöntemlerinin eksiklikleri üzerinde durmaya gerek yoktur. Birçok açıdan, bu teknoloji, yayın ortamları için tasarlanmış protokolleri, böyle bir veri aktarım modunun imkansız olduğu bir ortamda (NBMA, Yayınsız Çoklu Erişim) çalışması için "çekmek" için başarısız bir girişimdir.

Dolayısıyla, İnternet hala kendisiyse ve IP'ye dayalı olmaya devam ediyorsa, IP ile eşit derecede iyi olan gerçekten verimli, gerçekten yüksek hızlı taşıma protokolü SDH arasında ATM şeklinde ek bir "katmana" ihtiyaç var mı? hemen hemen her türlü trafik taşıyan?

SDH üzerinden IP

SDH teknolojisi, güvenilir taşımayı organize etmek için yaygın olarak kullanılmaktadır. SDH, sağlayıcılar arasında iletişim için standart bir protokol sağlamak üzere tasarlanmıştır; Amerikan, Avrupa ve Japon dijital sistemlerini birleştirmek; gigabit hızlarında dijital sinyallerin çoğullanmasını sağlamak; OA&M (operasyon, yönetim ve bakım) işlevleri için destek sağlar.

SDH çerçevelerle çalışmasına ve kendi kanal yapısına sahip olmasına rağmen, ağ katmanı açısından bakıldığında, SDH yalnızca bir sekizli akışıdır. Bir IP paketini bir SDH konteynerine doğru şekilde yerleştirmek için, paketin (veya paket grubunun) sınırlarının senkron taşıma modülü STM (senkron taşıma modülü) içinde açıkça tanımlanması gerekir. Başka bir deyişle, bağlantı katmanı çerçevelerini oluşturmak için IP ve SDH arasında bazı protokol "katmanları" gereklidir.

SDH noktadan noktaya bağlantılar sağladığından, ara protokol olarak PPP (Noktadan Noktaya Protokol) kullanmak oldukça mantıklı görünüyor. PPP, İnternet'te geniş alan ağları üzerinden bağlantı kurmak için bir bağlantı katmanı protokolü olarak yaygın olarak kullanılmaktadır. Ayrıca PPP, PPP protokolünün ek özelliklerini kullanmanıza izin verir:

• çok protokollü kapsülleme olasılığı;
• hata koruması;
• bağlantı katmanı bağlantılarını kurmak, yapılandırmak ve test etmek için LCP protokolünü kullanmak;
• çeşitli ağ protokollerini desteklemek ve yapılandırmak için NCP protokol ailesini kullanma yeteneği.

Ancak, bir ağ protokolü olarak yalnızca IP'nin bizi ilgilendirdiği ve ayrıca bir dizi NCP protokolü işlevinin (örneğin, IP adreslerinin dinamik atanması) bizim durumumuzda ilgili olmadığı belirtilmelidir. Gerçekten ilgilendiğimiz şey, IP'yi PPP'ye yerleştirmek ve ardından PPP çerçevelerini SDH'ye yerleştirmek.

PPP'de IP kapsülleme, iyi kurulmuş ve yaygın olarak kullanıldığından bir sorun değildir. Şekilde gösterilen SDH'de PPP'yi kapsülleme prosedürü (tanımlanan Yol Sinyal Etiketi = 207hex), SDH yol katmanında özel bir hizmet adaptörü tarafından gerçekleştirilmelidir. Hizmet bağdaştırıcısı, bir PPP çerçeve akışını alan ve bir STM taşıma modülü akışını "yayan" bir "kara kutu" olabilir. Her iki protokol de tek bayt modunda çalışmaya yönelik olduğundan, PPP SDH ile çalışmak için çok uygundur.

Böylece, İnternet trafiğini doğrudan mevcut SDH taşıma hizmetine dahil ederek, karmaşık bir ağ altyapısını önemli ölçüde basitleştiriyor, böylece maliyetini düşürüyor ve etkin çıktıyı artırıyoruz. IP trafiğini gigabit hızlarında (Gigabit Ethernet) iletmek için yeni fırsatların ve IP paketlerinin hızlı geçişi için teknolojilerin (Multiprotocol Label Switching - MPLS) ortaya çıkmasıyla birlikte, IP protokolünü tek bir taşıma hizmetinin temeli olarak kullanmak gerçek hale geliyor. video, telefon ve diğer multimedya uygulamalarının iletilmesi - Neyse ki, World Wide Web'de IP protokolünün uygulanması konusundaki çalışmaların ana kısmı zaten tamamlandı. Bu bağlamda, standartların görünümü (RFC 1619) ve modern İnternet yönlendiricilerinde, özellikle de Cisco Systems'ın GSR 12000'inde "SDH üzerinden PPP" (veya Sonet Üzerinden Paketler - POS) gibi arayüzlerin ilk pratik uygulamaları çok görünüyor. zamanında.

Sonuç olarak, yazarın hiçbir şekilde ATM teknolojisinin önemini küçümsemeyeceğini ve dünya telekomünikasyon hizmetlerinin gelişimi üzerindeki olumlu etkisini inkar etmeyeceğini belirtmek isterim. Eşzamansız hücre transfer modu teknolojisinden farklı, multimedya servisleri geliştirmenin alternatif yollarının olasılığını düşünmek, tartışmalı bir şekilde ona ilginç geldi.

YAZAR HAKKINDA

Oleg Allenov - AMT Group, CCSI/CCIE eğitim merkezinin eğitmeni. Telefonla iletişime geçilebilir. 725 - 7660