Linux'ta yönlendirme açıldıktan sonra IPv6 varsayılan rotası kayboldu

VPN istemci trafiğini geçirebilmesi için bir Debian geçidine net.ipv6.conf.all.forwarding=1 ayarladım ve yaklaşık yarım saat sonra makinede hiç IPv6 varsayılan rotası kalmadı. Üst yönlendirici çalışıyordu, link-local komşu hâlâ yanıt veriyordu ve uplink kendi genel adresini koruyordu. Duran şey, çekirdeğin o arayüzde router advertisement almaya devam etme isteğiydi. Rota sysctl'i yazdığım anda kaybolmadı; RA'dan öğrenilen varsayılan rotanın ömrü bittiğinde ve hiçbir şey onu yenilemediğinde kayboldu.

İlk bakışta hiçbir şey bozuk görünmüyordu. Yönlendirme çalışıyordu, eski rota önbellekte olduğu sürece istemciler geçiyordu ve arıza, ona neden olan değişiklikten daha sonra geldi. Bu gecikme yüzünden sorun, hiç karışmamış bir üst tarafa ya da güvenlik duvarı kuralına yazılır.

Herhangi bir sysctl'e dokunmadan önce rota tablosunu okuyun

ip -6 route show default ile başlayın ve yalnızca geçidi değil öznitelikleri okuyun. RA'dan öğrenilen varsayılan rota proto ra olarak işaretlidir, bir tercih taşır ve expires geri sayımını gösterir. Elle eklediğiniz rotada ikisi de yoktur ve bu fark, rotaya hangi mekanizmanın sahip olduğunu söyler.

$ ip -6 route show default
default via fe80::1 dev eth0 proto ra metric 1024 expires 1432sec hoplimit 64 pref medium

Sonra adrese bakın: ip -6 addr show dev eth0. Saat cinsinden ölçülen tercih edilen ve geçerli ömürlere sahip bir genel adres, yönlendirici ömrü dakikalarla ölçülen varsayılan rotadan daha uzun yaşar. Adres var, varsayılan rota yok, bu bir duyuru sorununun imzasıdır. Adres de yoksa önce bağlantı, önek bilgisi veya yinelenen adres algılama ile uğraşmanız gerekir.

Yönlendirme neden RA işlemeyi kapatır

RA, 134 tipinde bir ICMPv6 paketidir ve 255 atlama sınırıyla link-local bir kaynaktan gönderilir. Çekirdek onu kullanmadan önce arayüzün accept_ra değerine bakar. Varsayılan değer 1'dir ve 1 evet anlamına gelmez. Şu anlama gelir: yalnızca bu ana bilgisayar yönlendirme yapmadığı sürece kabul et. forwarding=1 ayarlarsanız bu koşul sağlanmaz, bu yüzden duyuru içindeki herhangi bir önek veya varsayılan yönlendirici değerlendirilmeden önce düşürülür.

Üç değer vardır ve yönlendirmeyi yalnızca üçüncüsü atlatır:

Diğer iki bayrak neyin gerçekten kurulacağını belirler. accept_ra_defrtr duyurudaki varsayılan yönlendiricinin rota olup olmayacağını, accept_ra_pinfo ise önek bilgisinin adres yapılandırmasında kullanılıp kullanılmayacağını denetler. accept_ra_defrtr kapatmak, yönlendirme yapan bir ana bilgisayarda varsayılan rota öğrenmeden SLAAC adreslerini tutmanın olağan yoludur. Bu, accept_ra'den farklı bir koldur ve adres isteyip rota istemediğinizde ona başvurursunuz. Çekirdeğin IP sysctl başvurusu üçünü de listeler.

Bunu üç komutla doğrulayın

Önce yüklendiğini düşündüğünüz dosya yerine canlı değerleri okuyun:

sysctl net.ipv6.conf.eth0.forwarding net.ipv6.conf.all.forwarding \
       net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_defrtr

İkincisi, duyuruların hâlâ geldiğini kanıtlayın. ICMPv6 tip baytına göre filtrelemek yeterlidir ve komşu keşif trafiğinden oluşan bir duvarı okumaktan kurtarır:

tcpdump -ni eth0 'icmp6 and ip6[40] == 134'

Birkaç dakika boyunca hiçbir şey görünmezse, accept_ra sizin sorununuz değildir. Üst taraf duyuru yapmayı bıraktı, yolda bir şey ICMPv6 filtreliyor ya da o arayüz gerçekten düşündüğünüz segmentte değil. Üçüncüsü, duyuruyu kendiniz isteyin ve alanlarını okuyun:

rdisc6 eth0

rdisc6 Debian ve Ubuntu'da ndisc6 paketinde gelir. Çıktıda başka bir şeyi değiştirmeden önce yönlendirici ömrüne ve tercihe bakın. Yönlendirici ömrü 0 olan bir duyuru, varsayılan yönlendiricinin kaldırılması talimatıdır ve hiçbir accept_ra değeri bunu kullanılabilir bir rotaya çevirmez. Köprü modundaki bir üst CPE'yi de böyle yakalarsınız; önek dağıtır ama kendini hiçbir zaman yönlendirici olarak sunmaz.

Uplink'i tek izin veren arayüz yapın

Üst taraf varsayılan yönlendirici olacaksa, yönlendirmeye rağmen duyuruları orada kabul edin, başka hiçbir yerde değil:

# /etc/sysctl.d/60-ipv6-router.conf
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.eth0.accept_ra = 2
net.ipv6.conf.eth0.accept_ra_defrtr = 1

Sınırlama önemlidir çünkü Linux'ta IPv6 yönlendirmesi tek bir genel anahtardır, bağlantı başına bir tane değil. net.ipv6.conf.wg0.forwarding içine 1 yazın ve sonra net.ipv6.conf.all.forwarding değerini okuyun: genel değer tersine döner ve her arayüz yönlendirme yapmaya başlar. Tünelde yönlendirici, LAN'da sıradan bir ana bilgisayar olamazsınız. Sınırlayabileceğiniz şey kabuldür. accept_ra=2 değerini uplink'te tutun, tünel ve LAN arayüzlerini 1 veya 0'da bırakın; böylece tünelden gelen başıboş bir duyuru, içine işaret eden bir varsayılan rota kuramaz.

Geçici bir sysctl -w sonraki açılışta kalmaz ve hem systemd-networkd hem de NetworkManager bu değerleri kendi yapılandırmalarından yazar. networkd'de uplink'in .network dosyasında IPv6Forwarding=yes ve IPv6AcceptRA=yes ayarlayın; networkd, IPv6Forwarding'i çekirdekteki aynı nedenle genel olarak belgeler. NetworkManager'da accept_ra değerini uplink'teki ipv6.method=auto sürer, bu yüzden nmcli connection up sonrasında sysctl'i yeniden okuyun, ilk kontrole güvenmeyin.

Statik alternatif, ip -6 route add default via fe80::1 dev eth0, gerçekten çalışır ve üst yönlendiricinin kararlı bir link-local adresi olduğunda makul bir yanıttır. Neyden vazgeçtiğiniz konusunda net olun. Statik varsayılan rota hiç yenilenmez ve hiç geri çekilmez, bu yüzden üst taraf değiştirildikten sonra da ölü bir komşuya işaret eder. RA rotası güvenli biçimde başarısız olur; statik olan sessizce başarısız olur.

Geçidin kendi paketini değil, yönlendirilen paketi test edin

Geçidin kendi ping'leri hiçbir istemcinin kullanamayacağı bir rotada başarılı olabilir ve geçit kaynak olduğu için de başarılı olabilir. Bağlı bir istemciden test edin, sonra geçide o istemcinin adresi için ne yapacağını sorun:

# on the VPN client
ping -6 -c 3 2001:4860:4860::8888

# on the gateway, using a client address
ip -6 route get 2001:4860:4860::8888 from fd42:20::2

Sonra bir yönlendirici ömrü bekleyin ve yeniden bakın. İstediğiniz kararlı durum, proto ra ile işaretlenmiş ve expires değeri sürekli sıfırlanan bir varsayılan rota ile all.forwarding=1 birlikte. Eğer expires yalnızca geri sayıyorsa, duyurular hâlâ bir yerde düşürülüyordur ve olağan suçlu, açılıştaki sysctl zaten çalıştıktan sonra accept_ra değerinin üzerine yazan bir ağ yöneticisidir.

Bunu kapatmadan önce dört şeyi doğrulayın: varsayılan rota proto ra ve yenileniyor, accept_ra=2 yalnızca uplink için geçerli, yönlendirme yeniden başlatmadan ve yönetici yeniden başlatıldıktan sonra hâlâ 1, ve IPv6 ping'ini geçit değil istemci tamamlıyor. İstemci sağlıklı bir rotayla hâlâ başarısız oluyorsa, sıradaki şüpheli dönüş yolu veya üst taraftaki güvenlik duvarıdır, duyuru değil.