Tabii ki, adresleri tükendikten sonra açık İnternet üzerinden IPv6'ya gitme gerekliliğinin farkındayım, ama neden onu dahili bir ağda kullanmaya ihtiyaç duyulduğunu anlamıyorum. IPv6 ile sıfır yaptım, bu yüzden merak ediyorum: Modern güvenlik duvarları dahili IPv4 adresleri ile harici IPv6 adresleri arasında NAT yapmaz mı?
Merak ediyorum, burada çok fazla insanın IPv6 ile mücadele ettiğini ve neden rahatsız olduğunu merak ettiğimi merak ediyordum.
Yanıtlar:
IPv6 için NAT yoktur (zaten NAT düşündüğünüz gibi). NAT, IPv4'ün adresleri tükenmesi için $ EXPLETIVE geçici bir çözümdü (gerçekte var olmayan ve NAT hiç gerekmeden önce çözülmüş, ancak tarih 20/20 idi). Karmaşıklıktan başka bir şey eklemez ve IPv6'da baş ağrısına neden olmak dışında çok az şey yapar (çok fazla IPv6 Adresimiz var, onları boşa harcıyoruz). NAT66 var ve her ana bilgisayar tarafından kullanılan IPv6 adreslerinin sayısını azaltma amaçlı (IPv6 ana bilgisayarlarının birden fazla adrese sahip olması normal, IPv6 IPv4'ten birçok yönden biraz farklı, bu bir tanesidir).
İnternetin uçtan uca yönlendirilebilir olması gerekiyordu, bu IPv4'ün icat edilmesinin nedeninin bir parçası ve neden kabul gördü. Bu, İnternet üzerindeki tüm adreslerin erişilebilir olması gerektiği anlamına gelmez. NAT her ikisini de keser. Güvenlik duvarları, erişilebilirliği kırarak güvenlik katmanları ekler, ancak normalde bu yol gösterme pahasınadır.
IPv6'yı IPv4 adresi ile IPv6 bitiş noktası belirtmenin bir yolu olmadığından ağlarınızda isteyeceksiniz. Diğer yol, IPv4 Internet'e hala erişmek için DNS64 ve NAT64 kullanan yalnızca IPv6 ağlarının etkinleştirilmesini sağlar. Bugün IPv4'ü bir araya getirmek gerçekten mümkün, ancak biraz zor olsa da. IPv4 dahili adreslerinden IPv6 sunucularına proxy kullanmak mümkün olacaktır. Proxy sunucusu ekleme ve yapılandırma, ağa yapılandırma, donanım ve bakım maliyetleri ekler; genellikle IPv6'yı etkinleştirmekten çok daha fazlası.
NAT da kendi sorunlarına neden olur. Yönlendirici, üzerinden geçen her bağlantıyı koordine edebilmeli, uç noktaları, bağlantı noktalarını, zaman aşımlarını ve daha fazlasını izleyebilmelidir. Tüm bu trafik genellikle tek bir noktadan geçiyor. Gereksiz NAT yönlendiricileri oluşturmak mümkün olsa da, teknoloji çok karmaşık ve genellikle pahalıdır. Yedek basit yönlendiriciler kolay ve ucuzdur (nispeten). Ayrıca, yönlendirilebilirliğin bir kısmını yeniden oluşturmak için, NAT sisteminde iletme ve çeviri kuralları oluşturulmalıdır. Bu hala SIP gibi IP adreslerini yerleştiren protokolleri ihlal ediyor. UPNP, STUN ve diğer protokoller de bu soruna yardımcı olmak için icat edildi - daha fazla karmaşıklık, daha fazla bakım, daha fazla yanlışlık olabilir .
Dahili (rfc1918) ipv4 adreslerinin tükenmesi, ipv6'ya gitmek için çok geçerli bir neden olabilir.
Comcast , Nanog37'de yönetim adresleri için neden ipv6'ya gittiklerini açıkladı .
20 Million video customer
x 2.5 STB/customer
x 2 ip addresses/STB
--------------------
= 100 Millions IP addresses
Ve bu sadece video içindir , veri / modemler için değil.
2005 yılında RFC1918 havuzlarını tükettiler. Ardından halka açık adres havuzlarını kullandılar (nat yönetim için bir seçenek değil) ve ihtiyaçlarını çözmek için ipv6'ya gittiler .
Birkaç sebep:
IPv6 yayını desteklemiyor. Çok noktaya yayın ile değiştirilir. Yayın, bir düğümün bir alt ağdaki tüm düğümlere trafik göndermesini sağlar. Yayın alanlarının yönetimi, büyük IPv4 ağlarının hızlı ve sorunsuz çalışmasını sağlamak için büyük bir sorundur. Çok noktaya yayın, "stil" biçimini almak isteyen düğümlerin gerçekte "kaydolmasını" gerektirir; bu nedenle, ağ, tüm ana bilgisayarlara isabet eden trafik sular altında kalmaz.
IPv6, yerel olarak IPsec stili şifrelemeyi destekler.
IPv6 otomatik yapılandırmayı destekler. Bir yönlendiricinin arkasındaki ana makinelerin DHCP'ye ihtiyaç duymadan kendilerini yapılandırması mümkündür, ancak yine de DNS sunucusu, TFTP sunucusu vb. DHCP seçeneklerini yerine getirmek için bir DHCP sunucusuna ihtiyacınız vardır.
Eski işim, büyük bir üniversitede, dahili olarak bir IPv6 tahsisi kullanacaktı. Onlara geri IPv4 / 16 atandı ve bugün bile IPv4 adreslerini hemen hemen tüm iç istemcilere aktarıyor. RFC1918 şebekeleri sadece telekom şebekesi ve bazı özel kullanımlarla sınırlandırılmıştır (PCI standartları Ekim 2010'a kadar RFC1918 kullanımı gerektirmiştir).
Bu nedenle, aktif olarak IPv6'yı dahili olarak da kullanmayı planlıyorlardı. Hala çözülmesi gereken bazı donanım sorunları vardı, kenar anahtarları v6'yı yeterince iyi desteklemiyordu, ancak çekirdek hazırdı. Buradaki fikir, v6'nın halka açık bir şekilde görünmesini sağlamak (tamam, kamuya duyarlı bir sonuç), ağın herkese dağıtmak için yapılan çalışmaların% 70'ini kapsayacağı, bunun da% 30'unu da yapabileceği ve sona erdirileceği düşüncesiydi. onunla bit.
Halka açık bir IP tahsisi ile uzun süre yaşamış olan halkımız, atasözünün çok farkındaydı: "sadece halka olduğu için ulaşılabilir olduğu anlamına gelmez." Chris S’in dediği gibi rutubete ulaşılabilir değildir.
Bu yüzden en az bir organizasyon sınıfı IPv6'yı dahili olarak konuşlandırıyordu: çünkü zaten RFC1918 IPv4'ü dahili olarak kullanıyorlardı.
IPv6, IPv4 üzerinde daha basit bir otomatik yapılandırma ve otomatik keşif mekanizması gibi bazı potansiyel gerçek dünya iyileştirmeleri sunar, ayrıca bir IP aralığını port taraması yaparak kötü amaçlı yazılımların bir ağ üzerinde çoğaltması olanaksız hale geldiğinde de daha güvenlidir - - sadece çok fazla IP var. Ancak bu gelişmeler özellikle çarpıcı değil ve kesinlikle değişim maliyetine değmez.
Ancak bunun bir ya da ya da karar olmadığını, her ikisinin de paralel olarak çalışabileceğini ve yazılım geliştirirseniz, test amacıyla birçok insanın da bahsettiği gibi muhtemelen yapmalısınız. IPv6 uyumlu bir program yapmanın güvenilir bir yolu yoktur. Çoğu modern işletim sistemi aralarında otomatik olarak bir iç IPv6 ağı kurar - bu sadece onu kullanmaktan ibarettir.
10 yıl önce, işveren müşterilerinin program güncellemelerini almak için kullandıkları bir yazılım geliştirdim. Ağ bileşenini oluştururken, IPv6 uyumluluğundaki bina arasında karar vermek zorunda kaldım ya da sadece tüm IP adreslerinin 4 bayt olacağını varsaydım. Yaklaşık 4 saatlik çalışmadan tasarruf ederek basit rotaya geçmeye karar verdim ve sadece IPv4 uygulamasını yaptım. Zaten birkaç yıl içinde değiştirileceğini düşündüm. Bugün hala kullanıyorlar ve bu nedenle bazı küçük pazarlardan kilitlendiler.
Küçük bir şirket için çalışmak IPv6 kullanmamak için nedenler sadece düşünebiliyorum.
Sadece bizim gibi bir şirketin değişimi yapması bir anlam ifade etmiyor, çünkü kesinlikle ondan kazanacak hiçbir şeyle kayda değer bir masraf ve çaba gerektirmeyecek.
Açıkçası, NAT'ı ve yerel adreslerle uğraşmanın sağladığı faydaları seviyorum. Internet'te IPv6 ile etkileşime girmemiz gerekirse (yapılacak bir geek olmak yerine) gerekli olursa, bunu ağ geçidinde yapacağız.
Bu mevcut IPv6 modasının dünyanın en büyük çoğunluğu için, en azından on yıl veya daha fazla bir süre için, dahili olarak bir zorunluluk haline gelmesini beklemiyorum. Emekli olmayı umduğum gibi, benim için zaman ve çaba harcamak için şahsen çok fazla teşvik yok.
Düzenle:
Düşüşler alıyorum ama tek bir mantıklı ve mantıklı karşıt görüş değil. Düşünmeden trende uymak isteyen sadece bir avuç sincap atlama meraklısı olduğunu düşündürüyor. Bir ağda çok ciddi bir değişiklik yapmak için bir NEDEN olmalı ve benim de bir tane yok. Ayrıca, yalnızca çok az sayıda SF kullanıcısının bir tanesine sahip olduğundan şüpheleniyorum.
Burada iki şeyden bahsediyoruz - iç ağı saf IPv6'da çalıştırmak veya IPv4 / IPv6 çift yığınını çalıştırmak. Saf IPv6 çalıştırma hakkında konuşmak için erken olduğunu düşünüyorum - birçok işletim sisteminde IPv6 kullanmadan IPv6 kullanmak bile imkansızdır. Bununla birlikte, ağınızı IPv6'ya kaçınılmaz geçiş için hazırlamak amacıyla yazılım (b) geliştirirseniz, aşağıdaki nedenlerle (a) ikili yığın çalıştırmayı düşünebilirsiniz. Durum A ise, şimdi harekete geçmelisin, B ise o zaman benim tahminime göre düşünmek için yaklaşık 1-2 yıla sahipsin (ama ne kadar erken başlarsan o kadar hazırlıklı olursun).
Durumum A ve şimdi 6 ay boyunca çift yığın kullanıyoruz. Bu süre zarfında kamu / özel DNS, adres tahsisi, DHCP, yönlendirme, güvenlik duvarı ile ilgili bazı sorunları tespit ettik ve çözdük ve bu sorunların çoğunu denemeden bile bekleyemeyiz. Artık tamamen IPv6'ya hazırız ve hatta tünel açma yoluyla IPv6 kamu erişimine sahibiz. Tecrübelerime göre, IPv6'nın yaşlanma IPv4'e kıyasla çok daha basit ve daha zarif bir çözüm olduğunu söyleyebilirim, bu yüzden zaman IPv6'ya geçmeye geldiğinde çok mutlu olacağım, ama bu zaman gelmeden önce - çift yığını gitmek.
Düşük adres alanı, yayın yokluğu, IPSec ve daha basit otomatik konfigürasyonun yanı sıra IPv6'nın "pek bilinmeyen" avantajlarından bazıları:
Daha büyük adres alanı, adresin veri depolama olarak kullanılabilecek daha fazla bit içerdiği anlamına gelir. : Örnek, iki düğüm arasındaki-sayımını hop için sonra kendi IPv6 bir fonksiyonu örneğin adresleri olabilir
IPv6 adresi biçiminde olabilir PREFIX:Country&Region:DC&Line:Rack&Unit:VM&IDböylece daha yakın düğümler aynı fazla Most-Önemli-Bits sahip olacaktır. Bu sadece bir örnek, elbette "yakınlık" metrikleri, DNS TXT|SRVkayıtları gibi bir tür harici veritabanında saklanabilir .
Kriptografik Olarak Oluşturulmuş Adresler ( CGA ) ve SEND (SEcure Neighbor Discovery) gibi şifreleme amaçlı IPv6 adres alanını kullanma konusunda bazı teknikler vardır.
IPv6 etkinleştirildiğinde, ağdaki tüm düğümlerin yerel bağlantı IPv6 adresi vardır (başka şekilde yapılandırılmadıysa). Böylece yanlış yapılandırılmış düğüme bile erişme şansınız var.
Düğümlerin MAC adreslerini doğrudan yerel bağlantı IPv6 adresinden alabilirsiniz ( IPv6 gizlilik uzantıları yapılandırılmamışsa)
IPv4'ü binlerce düğümlü alt ağlarda kullanmanın hiçbir yolu yoktur - ağınız yayın trafiğiyle aşırı yüklenecektir (örneğin ARP).
Düğüm bilgisini kullanarak ek bilgi için düğümü sorgulayabilirsiniz , örneğin BSD'de ICMPv6 Düğüm Bilgi Düğümü Adresleri için ana bilgisayarı sorgulayabilirsiniz:
$ ping6 -a Aacgsl ::1
PING6(72=40+8+24 bytes) ::1 --> ::1
136 bytes from ::1:
fe80::beae:c5ff:fe43:44a(TTL=infty)
fe80::beae:c5ff:fe43:212(TTL=infty)
::1(TTL=infty)
fe80::1(TTL=infty)
2a02::9222(TTL=infty)
IPv6'yı dahili bir ana bilgisayar için kullanmanın iki nedeni olduğunu düşünebilirim.
Gelecekte bu konağın artık en azından belirli limanlarda harici olarak erişilebilir olması gerektiğini bulabilirsiniz.
Bu ana bilgisayarın aynı dahili adresi seçen başka bir ana bilgisayara da bağlanması gerektiğini bulabilirsiniz. Örneğin, Acme şirketindeki 10.0.0.5'e bağlanmanız gerekir ve Emca şirketindeki kendi adresiniz de 10.0.0.5'tir. Bunun önceki bir işte olduğunu hatırlıyorum, ikimiz de aynı dahili adresleri kullandık.
Modern dünyada bilgisayarların çoğunun% 100 dahili olmadığını söyleyebilirim. Çoğu masaüstü dış dünyaya sınırlı bağlantılar yapabilir veya bunun tersi de olabilir.
IPv6'yı dahili olarak kullanmanın tek iyi nedeni, dünya IPv6'ya geçtiğinde hazır olmaktır ve bence bu benimseme oranına bakıldığında oldukça kötü bir sebep. Dahili IP'lerin çoğu dışarıdan erişilemez hale geldiğinden, geri kalanını tercüme etmek büyük bir sorun olmaz.
Şirketim muhtemelen IPv6'ya dahili olarak asla geçmeyecek. Politikada köklü bir değişime ihtiyaç duyacak kadar büyük olması, nasıl gerçekleşebileceğini dürüstçe düşünemem. Bir çok insan öldürülmek zorunda kalacak ve bir sürü açıklanamayan işe alım seçimi yapılması gerekecekti. Aynı şekilde, ayrı ayrı iş birimlerinin LAN'larında IPv6'ya geçme girişimleri, birlikte çalışabilirlik ve sürdürülebilirlik endişelerine dayanan kurumsal ağ oluşturma üst düzey yöneticileri tarafından önyargılı hale getirilecektir (yerel olarak çok fazla boşluğa izin veriyoruz, ancak bu kadar fazla değil ).
Temel olarak, IPv6'ya geçiş ağrısız olsaydı, bunu yıllar önce yapardık.
IPv4, adres alanı doluncaya kadar her aygıtın doğrudan Internet’te olması amaçlanıyordu. Ardından, son 20 yıl boyunca hepsini kilitleyerek geçirdik. Şimdi, IPv6 tasarım gereği, bir kez daha her cihazı doğrudan İnternet'e yerleştirmek istiyor ... sonuç aynı olacak. NAT'ın, aynı derecede etkili veya daha iyi bir ikame olmadan terk edilmeyecek bir güvenlik katmanı olduğuna tamamen katılıyorum.
Ne yazık ki, bu cevapların ve yorumların büyük çoğunluğunda birçok kötü bilgi var. Körün bu kadar kör bir şekilde bu kadar üretken bir şekilde sürdüğünü görmek çok üzücü.
NAT hiçbir yere gitmiyor ve size "Ah, o NAT, ne korkunç bir şey" ... "diyen insanlar Ah, o NAT, etrafta çalışmaktan başka bir şey değildi" ... ad nasueum Dilini kullanmaya başlarlarsa Bu, bir haftasonu ağ koltuk savaşçısı değil, tavsiye için gerçek bir profesyonel ağ mimarına geçin.
İnternetten dahili sunuculara denge trafiği yüklemeniz mi gerekiyor? Tahmin et ne oldu, IPv6 ile bunu yaptığın gibi yapamazsın .... NAT kullanmıyorsan!
Evet bu doğrudur. Bazıları diyecek, oh sadece DSR / Direct server dönüş yükü dengelemesini kullanıyorsunuz. Fakat vazgeçmek zorunda olduğunuzu söylemeyi unuturlar 1) Kurabiye ekleme 2) Uygulama ivmesi 3) Liman adres çevirisi
Yani eğer dahili sunucularınızı 8080 portunda, fakat harici portunuzu 80'de çalıştırmak istiyorsanız ... Oh, çok üzücü, IPv6 ile yapamazsınız .... iyi ole NAT kullanmıyorsanız! DSR ile bile değil.
Öyleyse, "Ah, evet, tüm IPv6 NAT teklifleri başarısız oldu ... şükürler olsun" diyen "övünme" ye (ve imparatorluk alkışın sesiyle ölür) Bunun ne anlama geldiğini biliyor musunuz? NAT, IPv6 ile bile çalışsa bile korkunç olacak, çünkü tüm IPv6 zealotları, NAT / PAT'a olan ihtiyaç ve aslında bunu yapan insanlar bunu gönülsüzce yapıyorlar. Çok üzgün, çok kötü yönetilen
Öyleyse, hakikat sizi özgür kılan ve uyumunuzu zorlamak için korkutucu taktikleri kullanmaya çalışan lemmings'lerin tepelerinin üzerine çıkabildiğiniz için ne yapıyorsunuz?
Ağınızın genel / özel brokeri olarak görev yapan bir Yük Dengeleyici veya Güvenlik Duvarı satın alıyor veya kullanmaya devam ediyorsunuz. Genel taraf arayüzleri, sahip olduğunuz aynı VIP'leri barındırıyor ancak ihtiyaç duyduğunuzda tamamlayıcı bir IPv6 adresiyle ev sahipliği yapıyor. Loadbalancer / Firewall katmanının kuzeyindeki her şey aynı zamanda çift yığın IPv4 / IPv6'dır. Loadbalancer / Firewall'un iç arabirimlerinde hepsi IPv4 ve tüm iç ağınız IPv4 ve istediğiniz kadar kalıyor. Bu sadece senin işin. Loadbalancer, iç ve dış arasında NAT / PAT yapar ... çünkü zaten ve tam özellikli yük dengelemesi için gereklidir ve şimdi harici IPv6 probleminizi de çözmektedir.
Ah ve "NAT'ın tek güvenlik amacı ne işe yarar" diye sormuş alaycı kişiye
Güvenlik, en temel düzeyde Kullanılabilirlik ile ilgilidir. Bunu reddetmeden önce düşünün.
Yük dengeleyiciler, Kullanılabilirlik / Güvenlik özelliğini kullanır ve kullanmakta olduğunuz IP sürümünden bağımsız olarak NAT / PAT özelliğini kullanmak zorunda kalırsınız.
DSR ile ilgili alıntı başarısız: https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return
k thnx
Kabul edilen cevap yanıltıcıdır
Chris'in NAT'taki kavramları yanlış; IPv4 şemasının yapay genişlemesinin yanı sıra NAT'ın en iyi özelliklerinden biri GÜVENLİK. NAT, internete doğrudan bağlanırsa akla gelebilecek tüm saldırıların hedefi olabilecek bir ana bilgisayarın IP'sini gizleyen katmandır. Mutlulukla, ekstra güvenlik önlemlerini teşvik etmeden NAT'tan kurtulmaktan bahsetmek, konuyla ilgili cehalettir.