İki uplink fe80::1'i paylaştığında IPv6 politika yönlendirmesi

İki uplinkiniz var ve ip -6 route show her ikisinde de aynı sonraki atlamayı yazdırıyor: default via fe80::1 dev uplink0 ve default via fe80::1 dev uplink1. Bu bir yinelenen adres çakışması değildir ve çıplak sonraki atlamayı fe80::1 bir politika tablosuna kopyalamak, çekirdeğe hangi bağlantıyı kastettiğinizi söylemez. Gerçek soru, belirtinin ima ettiğinden daha dar: ikinci tablo tek bir bağlantı mı yoksa ikisi mi gerektiriyor ve yeniden başlatmadan sonra bu rotaları ne hayatta tutuyor. Sırayla kontrol edilen üç koşul çoğunu çözer.

Aynı fe80::1 iki farklı komşudur

Bağlantı yerel adresler tek bir bağlantıyla sınırlıdır, dolayısıyla fe80::1 iki kez yazdırılmış tek bir adres değildir; aynı son eki paylaşan iki komşudur. Bölge indeksi, bir ana makinenin hangisini kastettiğini söyleme biçimidir, bu yüzden fe80::1%uplink0 ve fe80::1%uplink1 çekirdek için farklı hedeflerdir ve bu son ek hiçbir zaman uzak bir yönlendiriciye gitmez. RFC 4007 bunun arkasındaki bölge modelini açıklar ve bu yüzden bir politika tablosu her bağlantı yerel sonraki atlamayla birlikte bir aygıt taşımak zorundadır.

Bir ana makinedeki sayısal bölge ID'sini bir şablona kopyalayan VPN yapılandırma üreteci, yerel bağlamı adresin bir parçasıymış gibi ele alır ve yazdığı dosya, arayüz adları veya indeksleri farklı olan her makinede yanlıştır. Bir politika tablosu iki bağlantıyı tek bir taneye de birleştirmez: yönlendirilen bir VPN ağlar arasında paket taşır, ancak uzak bir Ethernet komşusunun bağlantı yerel kimliğini tünelin karşısına taşımaz, bu yüzden bağlantı yerel trafik kendi bağlantısında kalır.

Aygıtı kaldırın ve rota yazılamaz hale gelir. ip -6 route add default via fe80::1 table 200 ağ geçidini çözemez ve iproute2 bunu Error: Nexthop has invalid gateway. hatasıyla reddeder. dev uplink0 ekleyin ve komut başarılı olur, çünkü sonraki atlamayı o iki komşudan birine sabitleyen şey aygıtın kendisidir. Aygıtın söyleyemediği şey, uplink0'ın bu tablo için doğru bağlantı olup olmadığıdır ve başka bir ana makineden kopyalanan bir rota o makinenin arayüz adlarını yanında getirir; gerçek hatalar da buradan gelir.

Birinci koşul: tabloda tek bağlantı mı iki mi

İkinci uplinkin ne için olduğuyla başlayın. İki bağlantı da aynı trafiği taşıyorsa ve biri yedekse, alternatif tablo iki ağ geçidini farklı metriklerle tutmalıdır: aynı hedefler, tek bir tercih edilen yol, tek bir belirgin ikinci seçenek. Uplinkler, farklı trafiğin farklı sağlayıcılardan çıkması gerektiği için ya da bu, bazı trafiğin VPN'i atlayıp geri kalanın içeride kaldığı bölünmüş bir tünel olduğu için varsa, o iki bağlantı hiçbir şekilde tek bir tabloya ait değildir. İki tabloya aittirler, onları bir kural seçer ve kural tüneli değil tabloyu seçer: atlayan trafik yönlendirilmeden önce işaretlenir ve onu ikinci tabloya gönderen şey o işarettir.

Bu ikinci durumda kural bir tabloya ne zaman bakılacağını, rota ise paketin bakıldıktan sonra nereye gideceğini belirler:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

Hiçbir nesne diğerinin yerini tutmaz ve yalnızca varsayılan içeren bir tablo bile ağ geçidini çözemeyebilir. Ekleme reddedilirse ya da rota var ama kullanılamazsa, o arayüzün bağlı önekini aynı tabloya koyun veya atlamayı onlink olarak işaretleyin (o önek başka bir yerde yönlendirildiğinde). Yukarıdaki blokta 2001:db8:100::/48 keyfi bir hedefi değil, uplink1 üzerindeki o bağlı öneki gösterir. fwmark kuralı yalnızca başka bir şeyin ayarlaması gereken bir işareti tüketir: iletme yolundaki bir nftables veya iptables kuralından ya da SO_MARK sokettekinden, bu yüzden işaret kaynağı olmadan kopyalanan bir blok hiçbir şeyle eşleşmez.

İkinci koşul: metrikler ölü sağlayıcıyı algılamaz

Metrik, var olan rotalar arasında bir tercihtir, sağlık kontrolü değildir. Operatör düştüğünde çekirdek o aygıttaki rotaları kaldırır ve ikinci varsayılan devralır. Kablo açık kaldığında ve arkasındaki sağlayıcı öldüğünde tabloda hiçbir şey değişmez: tercih edilen rota kuruludur, komşu katman 2'de erişilebilir ve paketler bir kara deliğe çıkar. Bu ayrım kurulumunuz için önemliyse, yük devri yolu yoklayan ve rotayı kaldıran bir şeyden gelmelidir; ister bir yönlendirme artalan süreci, ister girdiyi silip yeniden kuran küçük bir betik olsun.

Tablo kurulduktan sonra seçimi doğrulayın ve çekirdeğin göreceği biçimde doğrulayın. ip -6 route get 2001:db8:100::1 kullanılacak rotayı, aygıt ve seçilen kaynak adres dahil yazdırır ve politika kurallarına uyar. Yanlış uplinke ait bir kaynak adres, genellikle bir kuralın beklediğinizden daha erken eşleştiğinin işaretidir.

Üçüncü koşul: kalıcılığın sahibinin kim olduğuna karar verin

Rota, ip -6 route add ile eklendiğinde yeniden başlatmaya ya da bir şey onu temizleyene kadar yaşar. Yönlendirici duyurularından öğrenilen varsayılan bir yaşam süresi taşır ve yönlendirici onu geri çekebilir, elle eklenen varsayılan ise asla kendiliğinden sona ermez. İkisini tek bir tabloda karıştırmak, eski bir kalıcı rotanın taze duyurulan bir rotanın önüne geçmesinin yoludur; hem de onun tanımladığı uplink çoktan yok olduktan sonra.

Her tablo için tek bir sahip seçin. Bir ağ yöneticisi veya yönlendirme artalan süreci arayüzü zaten yönetiyorsa, politika rotasını orada tanımlayın ve çekirdeği rahat bırakın. Betikle yapıyorsanız betiği idempotent yapın ve sökme işlemini aynı anda yazın, çünkü ilk kötü değişiklikte ona ihtiyacınız olacak:

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

Diğer ana makineler için iletme yapan bir yönlendiricide, tabloyu suçlamadan önce net.ipv6.conf.all.forwarding kontrol edin. İletme kapalıyken, başka bir ağa adreslenen paketler tablo 201 ne kadar doğru olursa olsun düşürülür.

Tasarımı kaydedin ki bir sonraki kişi denetleyebilsin

Yalnızca fe80::1 saklayan bir envanter, önemli alanları çöpe atar. Hedefi, sonraki atlamayı, aygıtı, tabloyu ve metriği birlikte kaydedin; ayrıca her rotanın nereden geldiğini: duyurulmuş, yönetici tarafından üretilmiş ya da statik. Birisi sonradan ikinci uplinkin gerçekten trafik taşıyıp taşımadığını sorduğunda, o kayıt tahmin olmadan yanıt verir.

Tabloyu bitti ilan etmeden önce, komşuyu ip -6 neigh show dev uplink0 ile doğrulayın, ip -6 rule show yeniden okuyun — sıralama kazaları için ve varsayılan rotayı alan bir ping yerine kuralla eşleşen trafikle test edin. Sonra bir uplinki bilerek kapatın ve çekirdeğin hangi rotaya geri düştüğünü izleyin; yanıt yazdığınızla eşleşmelidir.