Çift yığın VPN: adres ailesini siz değil, istemci seçer

Tünel ayakta, IPv4 siteleri yükleniyor ve bir ana makine adı zaman aşımına uğruyor. Hemen varılan sonuç VPN'in bozuk olduğu ya da kimlik bilgilerinin yanlış olduğudur; oysa genellikle ikisi de doğru değildir. Ad hem IPv4 hem IPv6 adresi döndürdü, uygulama birini seçti ve bu adaylardan yalnızca birinin çalışan bir yolu vardı. Seçim kararını istemci verdi; tünel yalnızca seçileni kapsamıyordu.

Seçim bir kapsama vaadi değildir

RFC 6724'te açıklanan varsayılan adres seçimi, birden fazla seçenek olduğunda ana makinenin hangi kaynak-hedef çiftini tercih edeceğine karar verir. Happy Eyeballs bunun üzerine bir bağlantı stratejisi ekler: iki ailede de denemeler başlatır ve ilk yanıt vereni tutar, böylece kullanıcı bozuk bir ailenin zaman aşımını beklemez.

Hiçbir mekanizma yol oluşturmaz. Tüneliniz yalnızca IPv4 taşıyorsa, AAAA adayı yine de istemcinin deneyebileceği meşru bir hedeftir ve hata, tarayıcı geri döndüğü için hata olarak değil yavaş yükleme olarak görünür. Kullanıcı bozuk değil yavaş bir site bildirir ve destek bileti bu belirsizliği devralır. Sabit bir aileyle yeniden üretin, rapor belirginleşir.

Semptomun uygulamalar arasında tutarsız olmasının nedeni bu geri dönüştür. Tarayıcı gecikmeyi gizler; sabit aileli komut satırı istemcisi gerçek hatayı hemen gösterir.

İsteğin gerçekte hangi aileyi kullandığını bulun

Tünelle değil, adla başlayın. Her iki kayıt türünü sorgulayın ve ne döndüğünü not edin:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

v4 isteği başarılı olup v6 isteği başarısız olursa, sorunu hata ayıklanabilir bir biçimde yeniden üretmiş olursunuz. İkisi de kabuktan başarılı olup tarayıcı hâlâ başarısız olursa, tünele dokunmadan önce uygulamanın kendi çözümleyicisine veya önbelleğe alınmış bir yanıta bakın.

Aileyi ve hedefi notlarınızda tutun. Sitenin VPN üzerinden yüklenmediğini söyleyen bileti kimse doğrulayamaz, oysa AAAA'nın başarısız olduğunu ve A'nın çalıştığını söyleyen bilet belirli bir yolu gösterir.

O aile için yolu kontrol edin

Başarısız olan aile için çekirdeğe hangi yolu kullanacağını sorun ve tünelin yapılandırılmış adresleriyle karşılaştırın. Linux'ta ip -6 route get hedef için seçilecek arabirimi ve kaynağı gösterir.

Ardından tünelin kendisini kontrol edin. WireGuard eşleri izin verilen IP listesi taşır ve 0.0.0.0/0 için bir giriş IPv6 hakkında hiçbir şey söylemez. Eşin listesinde IPv6 öneki yoksa, istemcinin AAAA trafiğini tünele göndermek için bir nedeni yoktur ve paket ana makinenin aksi hâlde yapacağı yoldan çıkar.

Güvenlik duvarı kuralları ve NAT ilkesi her aile için aynı denetimi hak eder. IPv4 için yazılmış bir kural hiçbir platformda IPv6'yı kapsamaz ve bir ailenin çalışıp diğerinin çalışmamasının en yaygın nedeni budur.

Ekran görüntüsünü kolaylaştırmak için IPv6'yı devre dışı bırakmayın

IPv6'yı sistem genelinde kapatmak semptomu ortadan kaldırır ve sizi tanısız bırakır. Ayrıca yalnızca IPv6 olan her hedefi bozar ve aynı hatayı bir sonraki uygulama için gizler. Bir makine gerçekten IPv6 kullanmamalıysa, bu bir sahibi ve testi olan bilinçli bir ilkedir. Bir olay sırasında kapatmak ikisi de değildir.

İstemcinin aileyle ne yapması gerektiğine karar verin ve bunu açıkça yapılandırın: onu tünelden geçirin ya da desteklenen bir yolla engelleyin ki seçim asla ulaşılamaz bir aday önermesin. İkisi de meşru tasarımdır. Genel kapatma ikisi de değildir, çünkü hiç tasarım değildir.

Bilete ne yazmalı

Dört şey kaydedin: ana makine adını, başarısız olan aileyi, çekirdeğin seçtiği yolu ve aileye özgü isteğin sonucunu. Bu küme, başka birinin hatayı yeniden üretmesi için yeterlidir; iki yoldan hangisini kastettiğinizi tahmin etmesi gerekmez.

RFC 6724 adres seçimi kuralları istemcinin neden o adayı tercih ettiğini açıklar ve RFC 8305 gecikmeyi gizleyen yarış davranışını açıklar. Hiçbiri sizin için paketi yönlendirmez ve tünelin yapması gereken tam olarak bu kısımdır.