IPv6 link-local VPN üzerinden çalışmıyor: fe80 neden bağlantıda durur

Tüneli ayağa kaldırıp tüneli kaynak arabirim olarak kullanarak fe80::1'e ping atarsınız ve hiçbir yanıt gelmez. Bu unuttuğunuz bir güvenlik duvarı kuralı değildir. Link-local adres yalnızca oluştuğu tek bağlantıda anlam taşır ve yönlendirilmiş VPN o bağlantı değildir. Uzak yönlendiricinin fe80::1 adresi uzak LAN segmentinde yaşar; siz başka bir segmentte bir atlama uzaktasınız ve IPv6'da bir yönlendiricinin link-local paketleri iletmesini sağlayan hiçbir mekanizma yoktur.

fe80 öneki bir aralığı değil, bir kapsamı tanımlar

Link-local unicast fe80::/10'dur ve tanımlayıcı özellik sayı değil kapsamdır. Adres yalnızca tek bir bağlantıda geçerlidir ve her arabirim kendi tanımlayıcısından bir tane oluşturur, bu yüzden birbiriyle ilgisiz iki ağdaki birbiriyle ilgisiz iki makine en ufak çakışma olmadan fe80::1'e yanıt verebilir. Önek aslında “bir bağlantıda” der; bağlantının kendisi bağlamdan gelir.

Bir ana makinede bu bağlam, yüzde işaretinden sonra eklediğiniz bölge, yani scope ID'dir: Linux'ta fe80::1%eth0, Windows'ta ve arabirim dizinlerini gösteren araçlarda fe80::1%3 veya fe80::1%12. Çekirdek adresi arabirim diziniyle birlikte çözer ve sonra gönderir. Bölgeyi kaldırırsanız hedef belirsizleşir, bu yüzden yığının segment seçmesinin bir yolu yoktur.

Yönlendirilmiş bir tünel neden onu teslim edemez

Yönlendirilmiş VPN, kendi adreslerini taşıyan noktadan noktaya bir arabirimdir, genellikle tünelin içindeki unique-local veya özel IPv6 alanının /64'ü. Uzak LAN ayrı bir bağlantıdır; tünelin uç noktası sizin adınıza yönlendirip ileterek oraya ulaşır. Bunlar iki ayrı segmenttir, bu yüzden birinden gelen adres diğerinde geçerli bir hedef değildir.

İletme kuralı istemcinizin tuhaflığı değil, standartta açıkça yazılıdır: yönlendiriciler link-local kaynaklı veya hedefli paketleri iletmez. Bu yüzden yönlendirme tablosu doğru görünse bile paket ölür. fe80::/64 için tünele doğru bir rota eklerseniz, standarda uygun bir yığın onu ya reddeder ya da kabul edip eşleşen her paketi düşürür: hedefin kapsamı “yalnızca bu bağlantı” der ve giden arabirim o bağlantı değildir.

Komşu keşfi aynı sınırı güçlendirir. Ana makineler link-local sonraki atlamaları, 255 atlama sınırıyla bağlantı kapsamlı multicast'e gönderilen komşu isteğiyle çözer, böylece yönlendiriciler iletilen her şeyi reddedebilir. Bunu tünel üzerinden çalıştırmak, uzak bir segment için keşfi proxy'lemek anlamına gelir; bu başka bir şapka giymiş Layer 2 köprülemesidir.

Daha sessiz ikinci bir arıza vardır ve rotayı yine de zorlamaya çalışanları yakalar: bölge. Yerel olarak yazdığınız hangi bölge olursa olsun tünel arabirimini adlandırır, oysa istediğiniz adres uzak LAN arabirimine bağlıdır. İkisi asla eşleşmez, bu yüzden paket uzak uçta doğru arabirime yönlendirilemez.

Arıza pratikte nasıl görünür

Kapsam hatası için araç çıktısı yönlendirme veya güvenlik duvarı hatası gibi okunur ve insanların yanlış katmanda bir öğleden sonra harcamasının nedeni tam olarak budur.

Üçüncü satır en çok zaman kaybettirir, çünkü çıktısı olmayan bir ssh istemcisi dinleyen hizmet sorunu gibi görünür. İçeri girmenin herhangi bir yolu varsa uzak tarafı kontrol edin ve sshd'nin tüm adreslere mi yoksa yalnızca birine mi bağlı olduğunu doğrulayın.

Yönlendirilmek için tasarlanmış bir adres kullanın

Tünel üzerinden ulaşmanız gereken her şey için hizmete tam da bu amaçla verilen adresi kullanın: küresel bir unicast adres veya fc00::/7 içinden unique-local bir adres, tam olarak bu iç durum için ayrılmış aralık. Dinleyicinin onu gerçekten bağladığını doğrulayın ve dönüş yolunu ve ana makinenin herhangi bir güvenlik duvarı kuralını kontrol edin.

Tahmin etmek yerine uzak ana makineye bakın. ip -6 addr show var olan adresleri listeler ve ss -6 -ltn daemonun neyi dinlediğini listeler. Yalnızca fe80:: adresine bağlı bir hizmet yalnızca kendi segmentinden erişilebilir; bu genellikle kimsenin bilerek seçmediği ve yöneticinin onayıyla değiştirilebilen bir varsayılandır.

Hizmet gerçekten yeniden bağlanamıyorsa köprüyü ağ katmanı yerine uygulama katmanına taşıyın. Uzak ana makinede yönlendirilebilir bir adreste dinleyen ve link-local adrese bağlanan bir aktarıcı sorunu herhangi bir segmenti genişletmeden çözer:

socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80

Burada bölge doğru tarafta, o bağlantıda gerçekten eth0 bulunan ana makinede. İstemciniz normal olarak yönlendirilen fd00:1:2::10 ile konuşur ve aktarıcı link-local atlamayı yerel olarak yapar. Aynı numara yalnızca link-local adres duyuran bir cihazın web arayüzü veya eski bir BMC için de çalışır.

Köprüleme gerçekten yanıt olduğunda ve ne kontrol edilmeli

Bazı kurulumlar gerçekten tek bir paylaşılan segmente ihtiyaç duyar: yalnızca link-local keşfi konuşan bir cihaz, multicast'e bağımlı bir aygıt, düz bir LAN'ı yeniden üreten bir laboratuvar. Bu bir Layer 2 sorunudur ve Layer 2 yanıtı gerektirir; örneğin uzak arabirime köprülenmiş bir tap aygıtı veya açık köprü modlu bir istemci ürünü. Bunun bedeli tüneli geçen broadcast ve multicast trafiği ile uçtan uca çalışması gereken komşu keşfidir.

Yönlendirilmiş bir profile fe80::/64 ekleyerek buna yaklaşmayın. Bu en kötü durumu üretir: yapılandırma bitmiş görünür, yönlendirme tablosu bir girdi gösterir ve her paket hâlâ ikisi de doğru davranan iki yığın arasında bir yerde atılır.

Ping ile değil arabirimle doğrulayın. ip -6 addr show tun0 tünel bağlantısının kendi link-local adresini oluşturup oluşturmadığını söyler ve ip -6 route get fe80::1%tun0 çekirdeğin kapsamlı bir hedefle gerçekte ne yapacağını söyler. Çekirdek o arabirimde hedefe ulaşılamadığını söylüyorsa hiçbir tünel ayarı bunu değiştirmez ve profili düzenlemeyi bırakma zamanı gelmiştir.

Soruyu çözen kısa bir sıra:

• Uzak ana makinedeki adresi okuyun ve fe80:: mi yoksa yönlendirilebilir bir önek mi olduğunu not edin.
• fe80:: ise hizmeti yeniden bağlayın, o ana makinede aktarma yapın veya segmenti köprüleyin; yönlendirilebilirse rotayı, güvenlik duvarını veya bağlama adresini düzeltin.
• Her yeniden testte bölgeyi yeniden kontrol edin, çünkü kopyalanan komut genellikle yanlış arabirimi korur.

Kaynaklar: RFC 4291, IPv6 adresleme mimarisi.