IPv6 trafiği VPN üzerinden mi, doğrudan mı geçmeli?

Geçen ay iki kişi benden birbirine zıt sonuçlar istedi: biri IPv6'nın VPN kapsamına alınmasını, diğeri ofis yazıcısının çalışmaya devam etmesini istiyordu. Tek bir ::/0 rotası ikisini de kendi başına sağlayamaz. Bu rotanın tünelin içine ait olup olmadığı üç koşula bağlıdır ve ilk koşul onu çoğu ticari çıkış için dışarıda bırakır. Çıkış IPv6 taşımıyorsa, varsayılan rotayı oraya yönlendirmek trafiğinizi gönderecek yeri olmayan bir tünelde saklar.

Cevabı üç koşul belirler

Varsayılan rota tek bir satırdır, ::/0, ve daha belirli bir rotası olmayan her IPv6 hedefine uyar (RFC 4291). Kurulumu kolaydır. Bunu yapmanız gerekip gerekmediğine karar vermek üç koşula indirgenir.

Birinci koşul: bağlandığınız çıkışta çalışan IPv6 vardır ve onu iletmeye hazırdır. İkinci koşul: istemciniz tünelin uç noktasına giden yolu koruyabilir; bu nokta genellikle rota vereceğiniz aralığın içindedir. Üçüncü koşul: tünelin dışında kalması gereken yerel IPv6 hedeflerini adlandırabilirsiniz.

Her koşul kendine özgü biçimde başarısız olur, bu yüzden tahmin etmek bütün bir akşama mal olur. Başarısız birinci koşul size sessizlik ve doğru görünen bir rota tablosu verir. Başarısız ikinci koşul, el sıkışmayı başladıktan birkaç saniye sonra öldürür. Başarısız üçüncü koşul, çalışan bir tünel ve yazıcının yanında memnuniyetsiz bir iş arkadaşı bırakır.

Çıkış gerçekten IPv6 taşıyor mu?

IPv6 adresi olan bir tünel arayüzü karşı taraf hakkında hiçbir şey kanıtlamaz. Birçok ticari profil içeride yalnızca IPv4'tür: sunucu size bir v4 adresi verir ve gerisini atar. Üstüne AllowedIPs üzerinden bir varsayılan rota kurun, çekirdek IPv6'yı eşinin hiç görmediği bir arayüze memnuniyetle gönderir.

Tünel açıkken istemciden test edin. ping -6 -c 3 2001:4860:4860::8888 ve ip -6 route get 2001:4860:4860::8888 farklı soruları yanıtlar: yanıt dönüyor mu ve çekirdek hangi aygıtı seçti. İkincisi tünelinizi adlandırdığında ve birincisi hiçbir şey döndürmediğinde sorun rotada değil, çıkıştadır.

Çıkışı kendiniz işletiyorsanız istemci testi geçebilir ve yol yine de çıkmaz sokakta bitebilir. Ağ geçidinde net.ipv6.conf.all.forwarding=1 açık olduğunu ve güvenlik duvarının tünelden iletilen paketleri kabul ettiğini doğrulayın. İletmeyi reddeden bir çıkışa doğru düzgün yönlendirilmiş bir paket, istemci tarafından tam olarak bir yönlendirme hatası gibi görünür.

İstemci uç noktaya giden yolunu koruyabilir mi?

Bu, beni yalnızca IPv6 çalışan WireGuard uç noktası olan bir dizüstü bilgisayarda yakalayan durumdur. Uç noktanın adresi sıradan bir küresel adrestir, bu yüzden ::/0 içine düşer. Tüm öneki arayüze yönlendirin, el sıkışma paketleri hâlâ kurmaya çalıştıkları tünelin içine kendilerini sürer. Tünel hiçbir zaman açılmaz ve istemci çıktısında nedeni söyleyen hiçbir şey yoktur.

wg-quick bunu Linux'ta ele alır. Rotaları AllowedIPs üzerinden türetir, kendi tablosuna kurar ve uç noktaya giden trafiğin önce ana tablo üzerinden çözülmesi için bir ilke kuralı ekler: suppress_prefixlength 0 kuralı, onu ip -6 rule içinde bulursunuz. Bu yüzden wg-quick up, elle yazılmış ip -6 route add default dev wg0 sizi kestiği yerde başarılı olur.

Tüneli açmadan önce ve sonra iki durumu da ip -6 route get <endpoint-v6> ile kontrol edin. Yanıt tünel aygıtınıza değişirse, tünelin ihtiyaç duyduğu yolu kaldırmış olursunuz. Rotaları kendiniz yazarken, uç noktaya özgün ağ geçidi üzerinden bir ana bilgisayar rotası ekleyin ya da uç noktaya IPv4 üzerinden bağlanın ve IPv6'yı yüke bırakın.

Tünelin dışında ne kalmalı?

Daha belirli rotalar varsayılanı yener, bu yüzden bağlantı üzerindeki bir önek veya kendi rotası olan bir ULA aralığı ek çaba olmadan çalışmaya devam eder. Bu, birçok tam tünelli IPv4 kurulumunun hayatta kalmasının sessiz nedenidir: LAN önekleri varsayılandan daha belirlidir ve asla tünele girmez.

Yerel bir aygıt küresel bir adresle erişilebilir olduğunda bu bozulur; aynı yönlendiricinin genel bir önek verdiği yazıcı, NAS veya televizyon için bu normaldir. Bu adresler ::/0 ile eşleşir ve başka hiçbir şeyle eşleşmez, bu yüzden diğer her şeyle birlikte tünele taşınır ve kaybolur.

Protokole göre değil, hedefe göre karar verin. İki veya üç yerel ana bilgisayar önemliyse, öneklerine fiziksel arayüzden dışarı çıkan bir rota verin veya onları görüşülen kümeden çıkarın. Liste büyümeye devam ederse dürüst cevap, yazılı bir istisna listesiyle IPv6 için bölünmüş tünellemedir; sürekli yamadığınız bir varsayılan değil.

Cevap hayırsa, engelleyin

IPv6'yı rotasız bırakmak, onu kendi hâline bırakmakla aynı şey değildir. Çalışan bir IPv6 varsayılanı olan ana bilgisayar, tünel IPv4 taşırken onu kullanmaya devam eder, bu yüzden trafik VPN'in yanından çıkar ve IPv6'yı yeğleyen her hizmet gerçek adresinizi görür. Bu bir sızıntıdır, bölünmüş tünel değil.

Birini seçin ve hangisini seçtiğinizi yazın. Varsayılanı yönlendirin ve yukarıdaki ödünleşimleri kabul edin ya da tünel sürdüğü sürece IPv6'yı devre dışı bırakın. Öneki AllowedIPs içinden çıkarmak tek başına yeterli değildir, çünkü işletim sistemi kendi varsayılanını tutar. Linux'ta kaba sürüm sysctl -w net.ipv6.conf.all.disable_ipv6=1; daha ince sürüm IPv6'yı bir güvenlik duvarı kuralıyla tünelin dışına düşürür. Telefon istemcileri aynı işi yapan açık bir IPv6 engelleme anahtarıyla gelir.

Sızıntı gibi doğrulayın

Tüneli açın ve anahtara güvenmek yerine durumu okuyun. ip -6 route show default tek bir varsayılan göstermeli ve LAN'ınızın dışındaki bir hedef için ip -6 route get tünel aygıtını adlandırmalıdır. Bağlantı koptuktan sonra ikisini de yineleyin: tünelden daha uzun yaşayan bir varsayılan, aradığınız hatadır.

Ardından ters yönü test edin. Yerel ağdaki bir ana bilgisayardan istemciye yerel IPv6 adresinde ulaşın. Bu çalışmayı durdurursa, üçüncü koşul hiçbir zaman yerine getirilmemiştir; o anda rota tablosu ne iddia ederse etsin.

Sonucu bir sonraki kişinin bulacağı yere yazın: hangi önekler yerel kalır, neden ve bağlantı koptuktan sonra istemci ne yapar. Bir runbook'taki iki satır, bir sonraki mühendisi gece yarısı uç nokta döngüsünü yeniden keşfetmekten kurtarır.