IPv6 AAAA kayıtlarıyla ilişkili gecikmeler nasıl önlenir?

Windows sunucularımız IPv6 AAAAkayıtlarını Windows DNS sunucularımıza kaydediyor. Ancak, ağımızda IPv6 yönlendirmesi etkin değil, bu nedenle sık sık durma davranışlarına neden oluyor.

Microsoft RDP en kötü suçlu. AAAADNS'de kaydı olan bir sunucuya bağlanırken , uzak masaüstü istemcisi önce IPv6'yı dener ve bağlantı zaman aşımına uğrayana kadar IPv4'e geri dönmez. İleri düzey kullanıcılar, doğrudan IP adresine bağlanarak bu sorunu çözebilir. IPv4 adresini çözmek ping -4 hostname.fooher zaman anında çalışır.

Bu gecikmeyi önlemek için ne yapabilirim?

• İstemcide IPv6 devre dışı bırakılsın mı?
  • Hayır, Microsoft IPv6'nın Windows işletim sisteminin zorunlu bir parçası olduğunu söylüyor .
  • Bunun her yerde tutarlı bir şekilde ayarlandığından emin olmak için çok fazla müşteri var.
  • Sonunda IPv6 uyguladığımızda daha fazla soruna neden olacak.
• Sunucuda IPv6 devre dışı bırakılsın mı?
  • Hayır, Microsoft IPv6'nın Windows işletim sisteminin zorunlu bir parçası olduğunu söylüyor .
  • Tüm IPv6 yığınını devre dışı bırakmak için uygunsuz bir kayıt defteri kesmek gerekir.
  • Bunun tüm sunucularda doğru ayarlandığından emin olunması elverişsizdir.
  • Sonunda IPv6 uyguladığımızda daha fazla soruna neden olacak.
• Kullanıcı facnig DNS imlecindeki IPv6 kayıtlarını maskelemek mi?
  • Hayır, NLNet Unbound kullanıyoruz ve bunu desteklemiyor .
• IPv6 AAAA kayıtlarının Microsoft DNS sunucusuna kaydedilmesini engelliyor musunuz?
  • Bunun mümkün olduğunu bile sanmıyorum.

Bu noktada, DNS bölgelerimizden tüm AAAA kayıtlarını temizleyen bir komut dosyası yazmayı düşünüyorum. Lütfen, daha iyi bir yol bulmama yardım et.

GÜNCELLEME: DNS çözümlemesi sorun değildir . @Joeqwerty'nin cevabında belirttiği gibi, DNS kayıtları anında iade edilir. Hem Ave AAAAkayıtlar derhal mevcuttur. Sorun, bazı istemcilerin ( mstsc.exe) tercihen IPv6 üzerinden bağlantı kurmaya çalışması ve IPv4'e geri dönmesi biraz zaman almasıdır.

Bu bir yönlendirme sorunu gibi görünüyor. pingHedef adres unroutable çünkü komutu bir "Genel hata" hata iletisi üretir.

C:\Windows\system32>ping myhost.mydomain
Pinging myhost.mydomain [2002:1234:1234::1234:1234] with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.
Ping statistics for 2002:1234:1234::1234:1234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Bu davranışın bir paket yakalamasını alamıyorum. Bu (başarısız) ping komutunu çalıştırmak, Microsoft Ağ İzleyicisi'nde paket üretmez. Benzer şekilde, kaydı mstsc.exeolan bir ana bilgisayarla bağlantı kurmaya çalışmak AAAAIPv4'e bir geri dönüş yapana kadar trafik üretmez.

GÜNCELLEME: Ana bilgisayarlarımızın tümü herkese açık olarak yönlendirilebilir IPv4 adresleri kullanıyor. Bu sorunun bozuk bir 6to4 yapılandırmasına gelebileceğini düşünüyorum. 6to4, genel IP adresleri ile RFC1918 adresleri arasındaki ana bilgisayarlarda farklı davranır.

GÜNCELLEME: Ağımda kesinlikle 6to4 ile balık olan bir şey var. Windows istemcisinde 6to4'ü devre dışı bıraktığımda bağlantılar anında çözülüyor.

netsh int ipv6 6to4 set state disabled

Ancak @joeqwerty'nin dediği gibi, bu sadece sorunu maskeliyor. Hala ağımızdaki IPv6 iletişiminin neden tamamen çalışmadığını bulmaya çalışıyorum.

Bu soru oldukça ilginç ve itiraf etmeliyim ki bu davranışı hiç görmedim. Daha iyi denemek ve anlamak için biraz uğraşarken, başka bir W2K8R2 sunucusundan W2K8R2 RDS sunucularımdan biri için nslookup sorgulama pasajı aldım ve aynı test sunucusundan aynı RDS sunucusuna bir RDP oturumunun bir parçacığını yakaladım . Nslookup, IPv6 kaydını döndürmede gecikme göstermedi ve nslookup, IPv6 kaydını sorgulamadan önce test sunucumun IPv4 kaydı için sorguladığını gösterdi. Yakalamadaki zaman deltası her iki sorguda da kayda değer bir gecikme göstermemektedir.

DÜZENLE

Şimdi bir şey üzerinde çalışıyorsunuz.

Microsoft 6To4 bağdaştırıcısı için trafik yakaladığınızdan emin olun, aksi takdirde IPv6'yı görmezsiniz:

İşte RDS sunucumun nslookup sonucu. IPv6 adreslerini not edin:

Şimdi yakaladığım bir pasaj:

Ve son olarak, netstat'tan bağlantıyı gösteren bir pasaj:

Açıkça, onayladığınız gibi, DNS çözümlemesi sorun değil. Sorun, RDP bağlantısının IPv4 yerine IPv6'yı tercih etmesidir (Windows için varsayılan - Windows IPv4 yerine IPv6'yı tercih eder) ve IPv6 düzgün çalışmadığından IPv6'dan geri döndüğünde (belirttiğiniz gibi) gecikmeye neden olur. IPv4. İstemcileri IPv6 yerine IPv4 tercih edecek şekilde yapılandırarak bunu düzeltebilirsiniz, ancak bunun yalnızca sorunu maskeleyeceğini düşünüyorum. Daha iyi çözüm, IPv6'nın neden çalışmadığını bulmak ve bunu düzeltmek olacaktır. IPv6 hakkında yardımcı olmak için yeterli bilmiyorum ama tahminim DNS tarafından döndürülen IPv6 kayıtlarının yalnızca RDS ana bilgisayarlarının bulunduğu alt ağda geçerli olan "yerel" adresler olması ve istemcilerin farklı bir alt ağda olmalarıdır. t Bu IPv6 adreslerine ulaşma.

IPv6 geçiş teknolojisi 6to4 olarak adlandırılan rezil bunun gibi sorunlara neden için. İşte birkaç faktör vardır. Bireysel olarak zararsızdırlar, ancak birleşik etki, son kullanıcıların bağlantı gecikmeleri yaşayabilmesidir.

Azaltıcı etkenlerle ilgili etkinleştirici faktörlerin ve düşüncelerin bir listesi aşağıda sunulmuştur.

Windows varsayılan olarak 6'ya 4'ü etkinleştirir

Ana bilgisayarlarınız Windows'un yeni bir sürümünü (Vista veya üzeri) çalıştırıyorsa, genel olarak yönlendirilebilen bir IPv4 adresi mevcut olduğunda Windows fırsat olarak 6to4 tünellemesini etkinleştirir. Kritik olarak, bu hem sunucular hem de istemciler için geçerlidir.

Bir sistemin 6to4 kullanıp kullanmadığını öğrenmek ipconfigiçin 6to4 önekiyle başlayan bir IPv6 adresi çalıştırın ve arayın 2002:. Böyle bir şey olurdu.

C:\> ipconfig
Tunnel adapter 6TO4 Adapter:
IPv6 Address. . . . . . . . . . . : 2002:1111:2222::1111:2222

• Uç noktalarınız Active Directory'ye bağlıysa, 6to4 ve Teredo gibi geçiş protokollerini devre dışı bırakmak için Grup İlkesi'ni kullanabilirsiniz. Bu, KB929852'de iyi belgelenmiştir . (Müşterileriniz veya sunuculardan bu uygulama yeterli, ancak bu adım atıyoruz eğer muhtemelen müşteriler hem her yerde devre dışı bırakmak için mantıklı olurdu ve sunucuların.)
• Yalnızca birkaç ana bilgisayarı yönetiyorsanız, 6to4'ü duruma göre devre dışı bırakabilirsiniz. Bu, IPv6'yı tamamen devre dışı bırakmaktan çok daha iyidir.netsh int ipv6 6to4 set state disabled
• Farklı bir istemci işletim sistemi kullanın. Örneğin, Mac OS X'te varsayılan olarak 6to4 etkin değildir.

Herkese açık olarak yönlendirilebilir IPv4 adresleri kullanılıyor

6to4 yalnızca genel olarak yönlendirilebilen IPv4 adresleri olan ana bilgisayarlarda çalışır, bu nedenle bu sorun NAT güvenlik duvarının arkasındaki ana bilgisayarları asla etkilemez.

• İstemcileri ve / veya sunucuları bir NAT güvenlik duvarının arkasına taşıyabilir ve RFC1918 adreslemesini kullanmaya başlayabilirsiniz. Ancak bazı durumlarda, genel olarak yönlendirilebilir adresler aslında tercih edilir. Bir ağın tamamının adresinin değiştirilmesi de gerçekçi olmayan bir seçim olabilir.

6to4 ağ üzerinde düzgün çalışmıyor

Herhangi bir yayın modunda 6to4'te sorun gidermek çok zordur. O kadar zahmetlidir ki, IETF'ye resmi bir talep vardı, 6to4'ün tarihi olarak yeniden sınıflandırılması gerekiyor . Bu yazarın görüşüne göre, 6to4 kullanımdan kaldırılmıştır.

Kısacası 6to4, 6in4 adlı bir protokol kullanarak IPv6 paketlerini IPv4 paketlerine kapsülleyerek çalışır (IP protokolü = 41). IPv4 paketleri 192.88.99.1, internetin herhangi bir yerinde çalışan bir 6to4 rölesine ulaşması umuduyla herhangi bir yayın adresine gönderilir . Şanslıysanız, coğrafi olarak yakınlarda bile olabilir.

Uygulamada, bazı 6to4 röleleri yanlış ayarlanmış ve birçok ağ 6in4 trafiğinin güvenlik duvarını geçmesine bile izin vermiyor. Genellikle bu, bir güvenlik duvarı tüm giden trafiğe izin verdiğinde, ancak IP protokolü 41 paketlerinin güvenlik duvarı üzerinden geri dönmesine izin vermediğinde olur. (TODO sorun giderme için ilgili RFC'yi not eder.) Bu hata ("gelen kara delik") ve diğerleri RFC 6343'te açıklanmaktadır .

• Güvenlik duvarınızı, ağınızdaki ana bilgisayarlardan gönderildiğinde IP protokolü 41'i (TCP sıfırlamaları ile) yüksek sesle reddedecek şekilde ayarlayın. Bu, belirleyici olmayan bağlantı gecikmelerinden daha anlamlı bir "hızlı başarısız" davranışı ile sonuçlanmalıdır. Bunun sınırlı test ortamlarında çalıştığı gösterilmiştir .
• ISS'nizden veya ilk sekmeli transit sağlayıcınızdan çalışan bir 6to4 rölesi ayarlamasını isteyin. Bu doğru yapılırsa, son kullanıcılar için en iyi deneyimi sağlayacaktır. Herkese açık olarak yönlendirilebilen bir IPv4 adresine sahip herhangi bir son kullanıcı IPv6 internetine katılabilir.

Dinamik DNS kaydı

Tipik bir Active Directory ortamında, her bilgisayarın kendi adreslerini DNS sunucusuna kaydetmesine izin verilir. Bir ana bilgisayar birden çok ağ bağlantılı olduğunda, 6to4 tünelinden bile tüm adreslerini kaydeder.

Çoğu internet hizmeti dinamik DNS kullanmaz, bu nedenle bu sorun genellikle istemcilerin ve sunucuların aynı ağ için "dahili" olduğu kurumsal sitelerle sınırlıdır.

• Dinamik DNS güncellemelerini devre dışı bırakmayı seçebilirsiniz. Daha sonra bölge dosyasına herhangi bir AAAA kaynak kaydı koymazsanız, bunlar asla sunulmaz. Ancak, dinamik DNS genellikle dahili DNS sunucuları için istenir. (Bunu yaparsanız, zaten mevcut olabilecek AAAA kayıtlarını da sildiğinizden emin olun.)
• DNS sunucusunu AAAA kaynak kayıtları için yanıt vermeyecek şekilde ayarlayın. Ancak bunu yapmayın, çünkü IPv6'yı uygulamaya başlamak istediğinizde size gerçekten sorun verecektir. (Herkes ücretsiz / açık kaynaklı bir DNS güvenlik duvarı biliyor mu?)

İstemci uygulaması zarif bir şekilde başarısız olmaz

Microsoft'un RDP istemcisi, IPv6 yönlendirme sorunlarıyla düzgün bir şekilde ilgilenmeyen bir istemci uygulamasına bir örnektir. Çoğu web tarayıcısı, bunun gibi IPv6 edge durumlarıyla uğraşmada daha iyidir, bu nedenle bu davranışı gösterme eğilimi göstermezler.

• Farklı bir müşteri kullanmayı deneyin. Belki şanslı olacaksın.

Bu durum için çok yararlı olmadığını anlıyorum, ancak benzer bir ikilemle karşı karşıya olan uygulayıcılar için, "Happy Eyeballs" (RFC 6555) olarak bilinen ve aynı anda ipv4 ve ipv6'ya bağlanma ve hangisinin önce bağlandığını seçme yöntemini belirten bir uygulama tekniği var.

İşte benim çözümüm. Varsayılan olarak Windows, IPv6 yollarına IPv4 yollarından daha yüksek bir öncelik verir. IPv6 önek ilkesini düzenlerseniz, IPv6 yerine IPv4 kullanmasını sağlamak için bu davranışı değiştirebilirsiniz.

Ağımdaki tüm sistemlerin aynı şekilde ayarlandığından emin olmak için, bir makine oluşturduktan veya yeniledikten sonra yazılım yüklemesi sırasında çalıştırılan bir .bat komut dosyasına aşağıdaki komutları koydum.

netsh int ipv6 isatap set state disabled
netsh int ipv6 6to4 set state disabled
netsh interface teredo set state disable

netsh interface ipv6 delete prefixpolicy ::1/128
netsh interface ipv6 delete prefixpolicy ::/0
netsh interface ipv6 delete prefixpolicy 2002::/16
netsh interface ipv6 delete prefixpolicy ::/96
netsh interface ipv6 delete prefixpolicy ::ffff:0:0/96
netsh interface ipv6 delete prefixpolicy 2001::/32

netsh interface ipv6 add prefixpolicy ::1/128 50 0
netsh interface ipv6 add prefixpolicy ::ffff:0:0/96 40 1
netsh interface ipv6 add prefixpolicy ::/0 30 2
netsh interface ipv6 add prefixpolicy 2002::/16 20 3
netsh interface ipv6 add prefixpolicy ::/96 10 4
netsh interface ipv6 add prefixpolicy 2001::/32 5 5

Bunun ne yaptığını açıklamak için:

İlk 3 hat, çoğu ağ için yedek oldukları için yerleşik tünel arayüzlerini devre dışı bırakır. Makinelerinize kendi IPv6 adreslerini vermiyorsanız bu 3 satırı kullanmak istemeyebilirsiniz, benim durumumda bir DHCPv6 sunucum ve tünel bağlantılı bağlantı için IPv6 atayan ilgili altyapım var

İkinci komut bloğu, mevcut tüm IPv6 yönlendirme önek ilkelerini siler.

Üçüncü blok daha sonra IPv6 önek ilkelerini yeniden oluşturur, ancak farklı bir öncelik kümesi kullanır. Bu şekilde IPv4'e karşılık gelen önek IPv6'ya göre tercih edilir ve uygulama IPv6 kullanımını belirtmediği sürece makine IPv4'ü kullanmak isteyecektir.

Bu çözüm işlevsel çift yığın yeteneğini korur, ancak IPv4 kullanma tercihi, eksik, güvenilmez veya zayıf performans gösteren IPv6'ya sahip sitelerin, sistemdeki bir program tarafından söylenmedikçe kullanmaktan kaçınacağı anlamına gelir.

Bence işletim sistemlerini IPv4 yerine IPv6 kullanmanın benimsenmesini engelliyor. Geçiş dönemi boyunca, bir ana bilgisayarın IPv6 bağlantısına sahip olduğunu düşündüğü, ancak aslında tamamen işlevsel bir bağlantıya sahip olmadığı, yazılım arızalarına ve büyük gecikmelere neden olduğu zamanlar olacaktır. Tanıdığım birçok kişi, IPv6'yı tamamen bağlantılarını kurmadan önce IPv6'yı kırık bir şekilde dağıtan ISP'ler için bir geçici çözüm olarak IPv6'yı tamamen yönlendiricilerinde devre dışı bıraktı ve bu insanlar yönlendiricilerini yeniden yapılandırıncaya kadar IPv6 olmadan bırakmayı yeniden etkinleştirmeyi unutacaklar.