Yıllarca basın, şu anda çok az sayıda IPv4 adresinin mevcut olduğu konusunda yazıyor. Ancak diğer taraftan, halka açık IPv4 adreslerini küçük bir miktar para karşılığında veren bir sunucu barındırma şirketi kullanıyorum. Ve özel internet bağlantım halka açık bir IPv4 adresi ile birlikte geliyor.

Bu nasıl mümkün olabilir? Sorun, basının inanmamızı istediği kadar kötü mü?

Bu çok kötü. IPv4 adreslerinin yetersizliği ile mücadele etmek için tüketici ISS'lerinde ilk elden edindiğim deneyimlerin örneklerinin bir listesi:

• IPv4 blokları çevresinde şehirler arasında sürekli olarak dolaşmak, kısa süreli kesintilere neden olmakta ve müşteriler için bağlantı sıfırlamaktadır.
• DHCP kiralama sürelerinin günlerden dakikalara kısaltılması .
• Kullanıcıların Müşteri Yerinde Ekipman (CPE) üzerinde ağ adresi çevirisi (NAT) isteyip istemediklerini seçmelerine izin verin , sonra da herkes için geriye dönük olarak açın.
• NAT'dan çıkma fırsatını zaten kullanan müşteriler için NAT'ı CPE'de etkinleştirme.
• CPE tarafından uygulanan eşzamanlı olarak aktif medya erişim kontrolü (MAC) adreslerinin sayısının azaltılması .
• Servise kaydolduklarında gerçek bir IP adresi olan müşteriler için taşıyıcı sınıfı NAT (CGN) dağıtımı .

Bunların hepsi, ISS'nin müşterilerine sattığı ürünün kalitesini düşürüyor. Bunu müşterileri için neden yaptıklarının tek mantıklı açıklaması IPv4 adreslerinin yetersizliğidir.

IPv4 adreslerinin yetersizliği, çoklu eksiklikleri olan adres alanının parçalanmasına yol açmıştır:

• Yalnızca zaman ve paraya mal olan değil aynı zamanda hataya açık ve kesintilere neden olan idari ek masraflar.
• Birkaç yıl öncesine kadar omurgalı yönlendiricilerde içerik adreslenebilir bellek (CAM) kapasitesinin geniş kullanımı, belirli bir popüler yönlendirici modelinin sınırını geçtiğinde birden fazla ISS'de önemli bir kesintiye neden olur .

NAT olmadan, 3700 milyon yönlendirilebilir IPv4 adresiyle bugüne kadar elde edemeyiz. Ancak NAT, size daha az güvenilir bir bağlantı ve hata ayıklaması zor olan sorunlar sağlayan hassas bir çözümdür. NAT ne kadar fazla katman olursa o kadar kötü olur. Yirmi yıl süren yoğun çalışma, tek bir NAT katmanının çoğunlukla çalışmasını sağladı, ancak IPv4 adreslerinin yetersizliği etrafında çalışmak için tek bir NAT katmanının yeterli olduğu noktasını geçtik.

IPv4 adreslerinin tükenmesine başlamadan önce, NAT'ı yaygın olarak kullanmadık. İnternete bağlı her bilgisayarın kendine özgü küresel bir adresi olacaktı. NAT ilk tanıtıldığında, ISS müşterilerine müşteriye 1 müşteriye 1 gerçek adres vermesi için kullandığı / sahibi olduğu cihaz başına 1 gerçek adres vermekten geçmek olmuştur. Bu, IPv6'ya geçmemiz gereken bir süre (yıl) boyunca sorunu çözdü. IPv6'ya geçmek yerine (çoğunlukla) herkes herkesin değişmesini bekledi ve böylece (çoğunlukla) hiç kimse IPv6'yı kullanamadı. Şimdi yine aynı problemi yaşıyoruz, ancak bu sefer, ikinci bir NAT katmanı (CGN) kuruluyor, böylece ISS'ler birden fazla müşteri arasında 1 gerçek adres paylaşabiliyor.

IP adresinin tükenmesi, eğer son kullanıcının üzerinde kontrol sahibi olmadığı durumlar da dahil olmak üzere, NAT korkunç değilse, önemli bir şey değildir (Taşıyıcı Sınıf NAT veya CGN).

Ancak NAT'ın özellikle son kullanıcının üzerinde kontrol sahibi olmadığı durumlarda korkunç olduğunu savunuyorum . Ve (işi ağ mühendisliği / yönetimi olan ancak yazılım mühendisliği derecesine sahip bir kişi olarak) IPv6 yerine NAT'ı dağıtarak, ağ yöneticilerinin adres tükenmesini çözmenin ağırlığını alanlarından ve son kullanıcılara kaydırdıklarını iddia ediyorum. ve uygulama geliştiricileri.

Öyleyse (bana göre) NAT neden kaçınılması gereken korkunç, kötü bir şey?

Bakalım neyin kırıldığını açıklamakta adalet yapıp yapamayacağımı bakalım (ve daha iyi hale gelmemize neden olan hangi sorunları daha iyi olabileceğini bile bilmiyoruz):

• Ağ katmanı bağımsızlığı
• Eşler arası bağlantılar
• Tutarlı adlandırma ve kaynakların konumu
• En iyi trafik yönlendirmesi, gerçek adreslerini bilen ana bilgisayarlar
• Kötü niyetli trafik kaynağını takip etmek
• Verileri ayıran ve ayrı bağlantılar halinde kontrol eden ağ protokolleri

Bakalım bu öğelerin her birini açıklayabilir miyim?

Ağ katmanı bağımsızlığı

ISS'lerin sadece katman 3 paketlerinin etrafından geçmesi ve bunun üzerindeki katmanlarda ne olduğu umrunda olmaması gerekiyor. İster TCP, UDP, ister daha iyi / daha egzotik bir şey geçiriyor olsanız da (SCTP belki? Veya TCP / UDP'den daha iyi olan, ancak NAT desteği olmadığı için belirsiz olan başka bir protokol) bakım; hepsi sadece onlara veri gibi görünmesi gerekiyordu.

Fakat öyle değil - NAT'ın "ikinci dalgasını", "Taşıyıcı Sınıf" NAT'ı uygularken değil. O zaman mutlaka kullanmak istediğiniz katman 4 protokollerine bakmak ve bunları desteklemek zorundalar. Şu anda, bu pratik olarak yalnızca TCP ve UDP kullanabileceğiniz anlamına gelir. Diğer protokoller ya sadece engellenecek / düşecekti (deneyimlerime göre vakaların büyük çoğunluğu) ya da sadece bu protokolü kullanan NAT ("bunu yapan bir uygulama gördüm") son ana bilgisayarına "iletilecek". Bu protokolü kullanan son ana bilgisayara iletmek bile gerçek bir düzeltme değildir - iki ana bilgisayar kullandığı anda kopar.

TCP ve UDP için şu anda henüz denenmemiş ve kullanılmayan bazı değiştirme protokolleri olduğunu düşünüyorum. Beni yanlış anlama, TCP ve UDP etkileyici bir şekilde iyi tasarlandı ve bugün ikisinin de interneti kullanma şeklimize nasıl ölçeklenebilecekleri şaşırtıcı. Ama neyi kaçırdığımızı kim bilebilir? SCTP hakkında okudum ve kulağa hoş geliyor, ancak NAT nedeniyle pratik olmadığı için hiç kullanmadı.

Eşler Arası bağlantılar

Bu büyük bir tane. Aslında bence en büyüğü. İki uç kullanıcınız varsa, ikisi de kendi NAT'larının ardında, hangisinin önce bağlanmaya çalışıldığına bakılmaksızın, diğer kullanıcının NAT'ları paketlerini bırakacak ve bağlantı başarılı olmayacaktır.

Bu, oyunları, sesli / görüntülü sohbeti (Skype gibi), kendi sunucularınızı barındırmayı vb. Etkiler.

Geçici çözümler var. Sorun, bu geçici çözümlerin geliştirici zamanına, son kullanıcı zamanına ve uygunsuzluğuna ya da hizmet altyapısı maliyetlerine mal olması. Ve kusursuz değiller ve bazen de kırılmazlar. (Diğer kullanıcıların, Skype'ın uğradığı kesintiler hakkındaki yorumlarını görün.)

Geçici bir çözüm, NAT aygıtını belirli bir gelen bağlantı noktasını NAT aygıtının arkasındaki belirli bir bilgisayara iletecek şekilde programladığınız bağlantı noktası iletmedir. Orada bulunan tüm farklı NAT aygıtları için bunun nasıl yapılacağına adanmış bütün web siteleri var. Bkz https://portforward.com/ . Bu genellikle son kullanıcı zamanı ve hayal kırıklığı maliyeti.

Diğer bir geçici çözüm, uygulamalara delik açma gibi şeyler için destek eklemek ve iki NATed istemcisi tanıtmak için NAT'un arkasında olmayan sunucu altyapısını sağlamaktır. Bu genellikle geliştirme zamanına mal olur ve geliştiricileri daha önce gerekmeyecek şekilde sunucu altyapısını potansiyel olarak koruyacak bir konuma koyar.

(Sorunun ağırlığını ağ yöneticilerinden son kullanıcılara ve uygulama geliştiricilere kaydırmak yerine IPv6 yerine NAT dağıtımı hakkında ne dediğimi hatırlıyor musunuz?)

Ağ kaynaklarının tutarlı adlandırma / konumu

Bir NAT'ın içinde ve sonra dışarıda farklı bir adres alanı kullanıldığından, bir NAT içindeki bir cihazın sunduğu herhangi bir hizmetin kendisine ulaşmak için birden fazla adresi vardır ve kullanılacak doğru müşteri istemcisinin nereden eriştiğine bağlıdır. . (Bu, bağlantı noktası iletme çalışmasını aldıktan sonra bile hala bir problemdir.)

Bir NAT içinde bir web sunucunuz varsa, 192.168.0.23 bağlantı noktası 80 numaralı bağlantı noktasında ve NAT aygıtınızın (yönlendirici / ağ geçidi) 35.72.216.228 numaralı dış adrese sahip olduğunu ve TCP bağlantı noktası 80 için bağlantı noktası iletme ayarını kurduğunuzu, şimdi web sunucusuna 192.168.0.23 portu 80 VEYA 35.72.216.228 port 80'i kullanarak erişilebilir. Kullanmanız gereken, NAT'ın içinde veya dışında olmanıza bağlıdır. NAT dışındaysanız ve 192.168.0.23 adresini kullanırsanız, beklediğiniz yere varamazsınız. Eğer NAT içerde ve dış adresini 35.72.216.228 kullanırsanız, belki istediğiniz noktaya gelmek için, NAT uygulama firkete destekleyen gelişmiş bir biriyse, ancak daha sonra isteğinizi sunan web sunucusu isteği NAT cihazınızdan geldiğini görecektir. Bu, NAT'ın arkasındaki ağda daha kısa bir yol olsa bile, tüm trafiğin NAT aygıtından geçmesi gerektiği ve web sunucusundaki günlüklerin NAT aygıtının kaynağı olarak listelendiği için çok daha az kullanışlı olacağı anlamına gelir. bağlantı. NAT uygulamanız saç tokasını desteklemiyorsa, gitmeyi beklediğiniz yere gidemezsiniz.

Ve DNS kullandığınız anda bu sorun daha da kötüleşiyor. Birdenbire, NAT'ın arkasında barındırılan bir şey için her şeyin düzgün çalışmasını istiyorsanız, bir NAT'ın içinde barındırılan hizmetin adresi konusunda, kimin sorduğuna bağlı olarak farklı cevaplar vermek isteyeceksiniz (AKA split horizon DNS, IIRC). Yuck.

Ve hepsi liman yönlendirme ve NAT ile saç tokası DNS'i ayırma konusunda bilgili birisine sahip olduğunuz varsayılıyor. Peki ya son kullanıcılar? Bir tüketici yönlendirici ve bir IP güvenlik kamerası satın aldıklarında ve "sadece çalışmasını" istediklerinde, tüm bunları kurma şansları nedir?

Ve bu beni yönlendirir:

En iyi trafik yönlendirmesi, gerçek adreslerini bilen ana bilgisayarlar

Görüldüğü gibi, gelişmiş firkete bile NAT trafiği her zaman en uygun yoldan akmaz. Bilgili bir yöneticinin bir sunucu kurduğu ve NAT'ı firkete olduğu durumda bile. (Verilen, bölünmüş ufuk DNS'si, bir ağ yöneticisinin elinde dahili trafiğin en uygun şekilde yönlendirilmesine yol açabilir.)

Bir uygulama geliştiricisi Dropbox gibi bir program oluşturup ağ ekipmanını yapılandırma konusunda uzman olmayan son kullanıcılara dağıtırsa ne olur? Özellikle, paylaşım dosyama 4GB'lık bir dosya koyduğumda ve bir sonraki bilgisayara erişmeyi denediğimde ne olur? Makineler arasında doğrudan aktarılıyor mu, yoksa yavaş bir WAN bağlantısı üzerinden bir bulut sunucusuna yüklenmesini beklemeli miyim ve sonra aynı yavaş WAN bağlantısı üzerinden indirmesi için ikinci kez beklemeli miyim?

Saf bir uygulama için, arabulucu olarak NAT'ın arkasında olmayan Dropbox'ın sunucu altyapısı kullanılarak yüklenecek ve daha sonra indirilecektir. Ancak iki makine yalnızca aynı ağda olduklarının farkına varırsa, dosyayı doğrudan çok daha hızlı bir şekilde aktarabilirlerdi. Dolayısıyla, daha az saf olmayan ilk uygulama denememiz için, işletim sistemine makinenin sahip olduğu IP (v4) adresinin ne olduğunu sorabilir ve ardından aynı Dropbox hesabında kayıtlı diğer makinelere karşı bunu kontrol edebiliriz. Bizimle aynı aralıktaysa, dosyayı doğrudan aktarın. Bu birçok durumda işe yarayabilir. Ancak o zaman bile bir sorun var: NAT yalnızca çalışıyor çünkü adresleri yeniden kullanabiliriz. Peki ya 192.168.0.23 adresi ve 192.168.0. Aynı Dropbox hesabına kayıtlı 42 adres aslında farklı ağlarda (ev ağınız ve iş ağınız gibi)? Şimdi arabuluculuk yapmak için Dropbox sunucu altyapısını kullanmakta başarısız olmalısınız. (Sonunda, Dropbox her Dropbox istemcisinin yerel ağda diğer müşterileri bulma umuduyla yayınlamasını sağlayarak sorunu çözmeye çalıştı. Ancak bu yayınlar NAT'ın arkasında olabilecek yönlendiricileri geçmiyor, bu tam bir çözüm olmadığı anlamına geliyor. ,özellikle CGN durumunda .)

Statik IP'ler

Ek olarak, birçok tüketici bağlantısının her zaman bağlantılarda olmadığı durumlarda (çevirmeli bağlantı gibi) ilk sıkıntı (ve NAT dalgası) gerçekleştiğinden, ISS'ler adreslerini yalnızca gerçekten bağlı olduğunuzda genel / harici IP adresleri tahsis ederek daha iyi kullanabilirler. Bu, bağlantı kurduğunuzda, her zaman aynı adresi almak yerine kullanılabilecek adresleri aldığınız anlamına geliyordu. Bu, kendi sunucunuzu çalıştırmayı daha da zorlaştırır ve sabit adreslerde olmak yerine, etrafta dolaşan eşlerle başa çıkmaları gerektiğinden, eşler arası uygulamaları daha da zorlaştırır.

Kötü niyetli trafik kaynağının şaşırtılması

NAT, giden bağlantıları NAT aygıtından geliyormuş gibi yeniden yazdığından, tüm davranışlar iyi ya da kötü, harici bir IP adresine alınır. Her giden bağlantıyı varsayılan olarak kaydeden hiçbir NAT aygıtı görmedim. Bu, varsayılan olarak, geçmiş kötü amaçlı trafiğin kaynağının yalnızca geçtiği NAT cihazına izlenebileceği anlamına gelir. Daha fazla işletme veya taşıyıcı sınıfı ekipman her giden bağlantıyı günlüğe kaydedecek şekilde yapılandırılabilirken, bunu yapan herhangi bir tüketici yönlendiricisi görmedim. ISS'lerin CGN'ler aracılığıyla yapılan tüm TCP ve UDP bağlantılarının bir kaydını tutup sürdürmeyeceklerini (ve ne kadar süreyle) görmenin ilginç olacağını düşünüyorum. Kötüye kullanım şikayetleriyle ve DMCA şikayetleriyle ilgilenmek için bu tür kayıtlara ihtiyaç duyulacaktır.

Bazı insanlar NAT'ın güvenliği arttırdığını düşünüyor. Eğer öyleyse, bunu gizlilik yoluyla yapar. NAT'ın zorunlu kıldığı varsayılan gelen trafik düşüşü, durum bilgisi olan bir güvenlik duvarına sahip olmakla aynıdır. Anladığım kadarıyla NAT için gereken bağlantı izlemeyi yapabilen herhangi bir donanımın durum bilgisi olan bir güvenlik duvarı çalıştırabilmesi gerekir, bu yüzden NAT gerçekten hiçbir noktayı hak etmiyor.

İkinci bir bağlantı kullanan protokoller

FTP ve SIP (VoIP) gibi protokoller kontrol ve gerçek veri içeriği için ayrı bağlantılar kullanma eğilimindedir. Bunu yapan her protokol, içinden geçtiği her NAT cihazında bir ALG (uygulama katmanı ağ geçidi) adı verilen yardımcı bir yazılıma sahip olmalı ya da bir tür aracı ya da delik açma ile bu konuda çalışmalıdır. Tecrübelerime göre, ALG'ler nadiren güncellenir ve SIP ile ilgili olarak ele aldığım en azından birkaç sorunun nedeni olmuştur. Birisinin VoIP'nin kendileri için işe yaramadığını bildiğini duyduğumda, ses yalnızca bir şekilde çalıştığı için, anında bir yerde, ne yapılacağını çözemediği UDP paketlerini bırakan bir NAT ağ geçidi olduğundan şüpheleniyorum.

Özet olarak, NAT kırılma eğilimindedir:

• TCP veya UDP'ye alternatif protokoller
• eşler arası sistemler
• NAT'ın arkasında barındırılan bir şeye erişme
• SIP ve FTP gibi şeyler. Bu konuda çalışmak için ALG'ler bugün, özellikle de SIP'de rastgele ve garip sorunlara neden oluyor.

Çekirdek, ağ yığınının aldığı katmanlı yaklaşım göreceli olarak basit ve zariftir. Bunu ağ oluşturma konusunda yeni birine açıklamaya çalışın ve kaçınılmaz olarak ev ağlarının muhtemelen anlamaya çalışmak için iyi ve basit bir ağ olduğunu varsayalım. Bu ipucunu birkaç durumda, dış ve iç adresler arasındaki karışıklıktan dolayı rotalamanın nasıl çalıştığı hakkında oldukça ilginç (aşırı derecede karmaşık) fikirlerin olduğunu gördüm.

NAT olmadan, VoIP'nin her yerde ve PSTN ile entegre olacağından ve bir cep telefonundan veya bilgisayardan arama yapmanın ücretsiz olacağından (zaten ödediğiniz internet hariç) olduğunu düşünüyorum. Sonuçta, neden siz ve ben sadece 64K VoIP akışını açıp PSTN kadar iyi çalıştığı zaman telefon için ödeme yapalım? Görünüşe göre bugün VoIP dağıtımıyla ilgili 1 numaralı konu NAT aygıtlarından geçiyor.

NAT'ın bağladığı bağlantıyı sona erdirecek olursak, genellikle pek çok şeyin ne kadar basit olabileceğini anlamadığımızdan şüpheleniyorum. İnsanlar hala e-posta (veya Dropbox) dosyalarına e-posta gönderiyorlar, çünkü iki istemci NAT'ın arkasında olduğunda bir arabulucuya ihtiyaç duymanın temel sorunu.

IPv4 tüketilmesinin büyük bir belirtisi, diğer cevaplarda bahsetmediğim bazı mobil servis sağlayıcıların sadece birkaç yıl önce IPv6'ya gitmeye başlamasıdır. IPv6'yı yıllardır kullanıyor olmanız ve bunu bilmeme ihtimaliniz var. Mobil sağlayıcılar, İnternet oyununda daha yenidir ve mutlaka alınabilecek büyük IPv4 tahsisleri olması gerekmez. Ayrıca, kablo / DSL / fiber'den daha fazla adres gerektirir, çünkü telefonunuz genel bir IP adresini evinizin diğer üyeleriyle paylaşamaz.

Tahminim IaaS ve PaaS sağlayıcıları, müşterilerin fiziksel adreslerine bağlı olmayan büyümeleri nedeniyle gelecek. Yakında bir indirim ile sadece IPv6-sunan IaaS sağlayıcıları görmek şaşırmam.

Büyük RIR'ler, bir süre önce normal tahsisat için yeterli yer bıraktı. Bu nedenle çoğu sağlayıcı için IPv4 adreslerinin tek kaynakları kendi stokları ve pazarlarıdır.

Özel bir kamu IPv4 IP'sine sahip olmanın tercih edilebileceği senaryolar vardır, ancak bu kesinlikle şart değildir. Ayrıca tahsis edilmiş ancak şu anda halka açık internet üzerinde kullanılmayan bir grup IPv4 adresi de vardır (özel ağlarda kullanılıyorlar veya hiç kullanılmıyor olabilirler). Son olarak, adresleri olması gerekenden çok daha gevşek bir şekilde tahsis edilmiş eski ağlar var.

En büyük üç RIR artık adreslerin hem üyeleri arasında hem de diğer üyelere satılmasını sağlıyor. Bu yüzden, kullanmadıkları adresleri olan veya bir tarafında bir ücret karşılığında serbest bırakılabilecek adresleri olan ve diğer tarafında gerçekten daha fazla IP adresine ihtiyaç duyan kuruluşlar arasında bir pazar var.

Tahmin edilmesi zor olan şey, her bir fiyat noktasında ne kadar arz ve talebin olacağı ve dolayısıyla piyasa fiyatının gelecekte ne yapacağıdır. Şimdiye kadar IP başına fiyat şaşırtıcı derecede düşük kalmıştır.

İdeal olarak, internetteki her ev sahibinin global bir IP adresi alabilmesi gerekir, ancak IPv4 adres tükenmesi gerçektir, ARIN zaten ücretsiz havuzlarında adres bitti .

Herkesin internet servislerine hala gayet iyi erişebilmesinin nedeni, birden fazla ana bilgisayarın ortak IP adreslerini paylaşmasına izin veren Ağ Adres Çevirisi (NAT) teknikleridir. Ancak, bu sorunsuz gelmiyor.

ISS'ler, şirketlere 256 IP adresi bloğu vermek için kullanılır. Şimdi, ISS'ler cimri ve size 5 gibi (bir şirket) veriyorlar. Geri döndüğünüzde (2003), evinizdeki her PC ve bağlı cihazın kendi internet IP adresine sahipti. Şimdi, kablo / DSN / Fios yönlendiricisinin bir IP adresi vardır ve evinizdeki tüm bilgisayarlara 10.0.0.x ip adresi verir. Özet: ISS'ler IP adreslerini boşa harcamak için kullanılıyor ve şimdi artık onları israf etmiyorlar.

Zaten birçok mükemmel cevabınız var, ancak henüz belirtilmeyen bir şey eklemek istiyorum.

Evet, IPv4 adres tükenmesi, nasıl ölçtüğünüze bağlı olarak kötüdür. Bazı şirketler hala çok büyük bir IPv4 adresi kaynağına sahipler, ancak taşıyıcı sınıfı NAT gibi geçici çözümler görmeye başlıyoruz.

Ancak IPv6'ya cevap verdiklerinde cevapların çoğu yanlıştır.

IPv4 adres sıkıntısı ile başa çıkmanıza yardımcı olabilecek teknolojilerin bir listesi. Her birinin kendine göre avantajları ve sakıncaları vardır.

• IPv6

  • Avantaj: çoğu işletim sisteminde standartlaştırılmış ve bulunur.
  • Dezavantajı: Aksine sık sık yapılan açıklamalara rağmen, ciddi güvenlik sorunları. 2005 yılına kadar, ABD CERT , IPv6'nın küresel adreslemesinin yol açtığı güvenlik sorunları konusunda uyardı. IPv6 uygun şekilde güvence altına alınabilir , ancak tüketici yönlendiricilerinin durumu göz önüne alındığında, bu gerçekleşmeyebilir.
  • Dezavantajı: göç zaman, para ve uzmanlık gerektirir.
  • Dezavantajı: Tüketici sınıfı birçok cihaz ciddi şekilde kusurludur. Örneğin, bir dizi D-Link yönlendiricisi , herhangi bir güvenlik duvarı sunmadan tüm trafiği ileterek IPv6'yı destekler .

Diğer bir husus: IPv6 bugün tamamen yakalansa bile, insanların çok uzun süre kullanacakları eski donanımlar nedeniyle IPv4'ü iptal etmek 20 yıl kadar daha uzun sürer (hala Windows 2003 sunucuları ve Windows XP iş istasyonlarını görüyorum) (IPv6'yı desteklemeyen tüm yazıcı ve kameralardan ve IoT cihazlarından bahsetmeyin).

• CGNat:
  • Avantaj: Müşteri tesislerinde değişiklik yapılmadan çalışır.
  • Dezavantaj: sadece giden bağlantıları destekler.
  • Dezavantaj: Birkaç protokolü desteklemeyebilir.

Sonunda, CGNat yeterli olmayacak. Belki IPv6 yakalayabiliyor, ancak ülke düzeyinde NAT veya bu satırlar boyunca bir şey görmemiz de mümkün.

Şu anda bir danışman olarak müşterilerime IPv6 (genellikle Teredo sayesinde) maruz kaldıklarını belirtmek zorunda kalıyorum. Bir sonraki soru her zaman olacaktır: "Bunu düzeltmenin maliyeti nedir?" ve sonra "Bunu engellemenin maliyeti nedir? Kapatırsak ne kaybederiz?" Her seferinde kararın ne olacağını tahmin et.

Alt satır: sorunuzu cevaplamak için, evet, IPv4 tükenmesi gerçektir. Ve bununla baş etmek için epeyce mekanizmalar göreceğiz. IPv6, denklem halinde olabilir veya olmayabilir.

Açık olmak gerekirse: Ben demiyorum gibi bu durumu. IPv6'nın başarılı olmasını istiyorum (ve IPv6'da bazı iyileştirmeler görmek istiyorum). Sadece şu anda yerde olduğu gibi duruma bakıyorum.

NAT, IPv6 bir fikir olduğunda, gerçek olmadan önce ve IP adresi tahsisi gerçek bir sorun haline geldi (herkes sormak için C Sınıfını temelde ne zaman verdiğini hatırlıyor mu?) Ve bu arada gerçek dünyanın bir çözüme ihtiyacı vardı. .

NAT IoT için yeterli değil. IoT gerçekleşecekse, IPv6 ile gerçekleşecek. IoT'in doğası, çevirmeli dünyanın nasıl çalıştığı ile daha yakından bağlantılıdır, ancak aynı anda daha fazla cihazın bağlı olduğu birkaç büyüklük sırası olacaktır.

Tüm IPv4 adres sorunu oldukça karmaşık. Bazı makalelerin tükendiğini bildiren bazı makaleleri bulabilirsiniz, ancak çok sayıda fazlalık (hiç kullanılmamış) hakkında bir partiden diğerine satılmakta olan bir başka konuşmadan bahsediyorsunuz. Sorun, neden bunlara (gelişmekte olan bölgeler ve gelişmiş ülkelerin kırsal bölgeleri) bunlardan daha az faydalanamayacaklarıdır?

Kazara içine girdiğimiz bir çalışmanın sonucu aşağıdadır. IPv4 havuzunu 256M kat genişletmek için orijinal IPv4 protokolü RFC791 ve uzun süre önce kullanılan, ancak az kullanılan 240/4 adres bloğundan başka bir şey kullanmaz. IETF'e EzIP (Kolay IPv4 için fonetik) adlı bir taslak teklif sunduk:

https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03

Temel olarak, EzIP yaklaşımı sadece IPv4 adresindeki kıtlık sorunlarını çözmekle kalmayacak, aynı zamanda siber güvenlik açıklarına neden olan kök nedenini büyük ölçüde hafifletecek, ayrıca IPv4 etki alanının tümünde İnternet için yeni olanaklar açacaktır. Aslında, bu plan ihtiyaç duyulan izole bölgeler için "gizli" olarak dağıtılabilir. Bunlar, IPv6'yı kayda değer bir süre için konuşlandırma aciliyetini hafifletmeli ve IPv4 adreslerinin alım satım pazarını geçersiz kılmalıdır.

Herhangi bir düşünce veya yorum çok takdir edilecektir.

Abe (2018-07-15 17:29)

Açıkçası, insanların düşündüğü kadar kötü olmadığını düşünüyorum. Evet, belki bazı yerlerde, ama o kadar değil çünkü yeterli adres yok. Çünkü hepsi sahip. Belki de benim konumum ya da bir şey, ama BT'yi son yedi yılda küçük ve orta ölçekli işletmeler için çalıştım ve bahsettiğiniz her şey genellikle standart bir kurulum. Crappy bir cihaza sahip olmadığınız sürece oldukça kolay, ya da ilk sırada ağa göre yapılması gereken boktan bir kurulum var.

Şahsen ben NAT konusunda iyiyim. Genel anlamda konuşma, eklenen bir koruma katmanıdır. En azından ya ekstra bir cihazdan geçmek zorundalar ya da dolaylı olarak bağlantımı koparacak bir yol bulmalılar. Çalışan sunucular için, bunun için ödeme yapmadığınız sürece, genel olarak ISS'niz ile yapılan sözleşmenin ihlali dışında kalan ve / veya ihlal ettiği düşünülür. Tabii ki yapabilirsin ve muhtemelen seni bu konuda rahatsız etmeyeceklerdir, ama yapabilirler.

Port-forwarding ve tüm bunlar tamamen karmaşık değildir. Şimdi, belki bazı cihazların yapılandırılması kolay değildir, ancak IPv4 nedeniyle değildir. Her yerde olduğu için hala en fazla uyumluluğu sunuyor.

Aslında hiç kimse kendilerine e-posta atıp, Drop-box veya Google Drive'a bir şey göndermek zorunda kalmıyor ya da benzer milyonlarca başka bir hizmet bu günlerde tam olarak roket bilimi ya da yavaş değil. Yani her şey senkronize edilir. Bir klasöre bıraktın. Benim gibi inek olmadığın sürece, ve ssh / sftp ile her şeyi yaparsın (tamam her şey değil ). Ve eğer gerçekten kendi sunucunuzu çalıştırmak istemeniz için bir nedeniniz varsa, bulut barındırma ucuzdur - Linux üzerinde Linux çalıştıran özel bir sanal sunucum var. Bant genişliği çok hızlı. Yukarı ok yazabildiğimden daha hızlı açılıyor ve Enter tuşuna basıyorum. Ve ölçeklenebilirdir Tüm kurulum, ücretsiz yedekleme ve elektrik faturası olmadan ayda 5 ila 10 dolar arasındadır.

Gerçekten bir eş ağ çözümüne gerek yok. Bugünlerde çoğu çok kullanıcılı oyunların tümü, araya giren bir sunucu aracılığıyla etkileşime girecek şekilde ayarlanmış, tüm ayarlar ve önceden yapılandırılmışlardır. Öte yandan, bu yazıdaki okuduğumun hepsi doğruysa, IPv6 giderse BT kalabalık ve ucuz olacaktır. Cep telefonları bile elyaf hızlarına yaklaşıyor. Veya en azından kablo.

Bir şirket içi sunucu çalıştırıyorsanız ve onu ağınızın içinde veya dışında aynı etki alanı adıyla vurmanız gerekiyorsa, bir linux tabanlı yönlendirici ve dnsmasq veya ana bilgisayarlardaki herhangi bir ve özel girişleri kullanarak bu adresi her zaman taklit edebilirsiniz. Eğer içerideyseniz, sizi yerel adrese yönlendirmek için

Gerçekten, her cihazın kendine ait açık bir adrese sahip olmasının, ağ üzerinde açık kalmasının gerçekten arzu edildiğini sanmıyorum. Biri size saldırırken kendilerini gizlemek isterse, ne olursa olsun olacak. Ama sen orada oturan bir ördeksin, sadece açık havada esinlenerek orada oturuyorsun. Hayır, her gün IPv4'ümü ve NAT'ımı alacağım. Ama orada olması güzel.

Her neyse, şimdi uykuya dalmak ... muhtemelen söyleyecek daha fazla şey var, ama bir şeyi kaçırmışsam yarın kontrol edeceğim. Eminim dahası vardır.