Privzeta pot IPv6 je izginila po omogočitvi posredovanja v Linuxu

Na prehodu Debian sem nastavil net.ipv6.conf.all.forwarding=1, da bi lahko posredoval promet odjemalcev VPN, in približno pol ure pozneje naprava ni imela več nobene privzete poti IPv6. Nadrejeni usmerjevalnik je bil pokonci, sosed na lokalni povezavi se je še odzival, uplink pa je še vedno imel svoj globalni naslov. Kar se je ustavilo, je bila pripravljenost jedra, da na tem vmesniku še naprej sprejema router oglase. Pot ni izginila, ko sem vtipkal sysctl; izginila je, ko je potekla življenjska doba poti, naučene iz RA, in nič je ni obnovilo.

Na prvi pogled ni bilo videti ničesar pokvarjenega. Posredovanje je delovalo, odjemalci so še prihajali skozi, dokler je bila stara pot še v predpomnilniku, in napaka se je pojavila pozneje kot sprememba, ki jo je povzročila. Ta zamik je razlog, da se to pripiše uplinku ali pravilu požarnega zidu, ki sploh ni bilo vpleteno.

Preberite usmerjevalno tabelo, preden se dotaknete katerega koli sysctl

Začnite z ip -6 route show default in preberite atribute, ne samo prehoda. Privzeta pot, naučena iz RA, je označena z proto ra, nosi prednost in kaže expires odštevanje. Pot, ki ste jo dodali ročno, nima ne enega ne drugega, in ta razlika vam pove, kateri mehanizem ima pot v lasti.

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

Nato poglejte naslov: ip -6 addr show dev eth0. Globalni naslov s prednostnimi in veljavnimi življenjskimi dobami, merjenimi v urah, bo preživel privzeto pot, katere življenjska doba usmerjevalnika se meri v minutah. Naslov je prisoten, privzeta pot pa manjka, to je podpis težave z oglasi. Če manjka tudi naslov, morate najprej loviti povezavo, podatke o predponi ali zaznavanje podvojenih naslovov.

Zakaj posredovanje izklopi obdelavo RA

RA je paket ICMPv6 vrste 134, poslan z vira na lokalni povezavi z omejitvijo skoka 255. Preden ga jedro uporabi, preveri accept_ra vmesnika. Privzeta vrednost je 1, in 1 ne pomeni da. Pomeni: sprejmi samo, dokler ta gostitelj ne posreduje. Nastavite forwarding=1 in ta pogoj pade, zato se oglas zavrže, preden se v njem upošteva katera koli predpona ali privzeti usmerjevalnik.

Obstajajo tri vrednosti in samo tretja preživi posredovanje:

Dve drugi zastavici odločata, kaj se dejansko namesti. accept_ra_defrtr nadzira, ali privzeti usmerjevalnik iz oglasa postane pot, accept_ra_pinfo pa nadzira, ali se podatki o predponi uporabijo za konfiguracijo naslova. Izklop accept_ra_defrtr je običajen način, da naslove SLAAC obdržite na gostitelju, ki posreduje, ne da bi se naučili privzeto pot. To je drug vzvod kot accept_ra, in po njem posežete, ko želite naslove, ne pa poti. Referenca jedra za IP sysctl navaja vse tri.

Potrdite s tremi ukazi

Najprej preberite žive vrednosti namesto datoteke, za katero mislite, da je naložena:

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

Drugič, dokažite, da oglasi še prihajajo. Filtriranje po bajtu vrste ICMPv6 zadostuje in se izogne branju zidu prometa odkrivanja sosedov:

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

Če se v nekaj minutah ne pojavi nič, accept_ra ni vaša težava. Nadrejena stran je prenehala oglaševati, nekaj na poti filtrira ICMPv6 ali pa ta vmesnik v resnici ni na segmentu, ki ga mislite. Tretjič, sami zahtevajte oglas in preberite njegova polja:

rdisc6 eth0

rdisc6 je v paketu ndisc6 na Debianu in Ubuntuju. V izpisu poglejte življenjsko dobo usmerjevalnika in prednost, preden karkoli drugega spremenite. Oglas z življenjsko dobo usmerjevalnika 0 je navodilo za odstranitev privzetega usmerjevalnika in nobena vrednost accept_ra tega ne spremeni v uporabno pot. Tako tudi ujamete nadrejeni CPE v načinu mosta, ki deli predpone, a se nikoli ne ponudi kot usmerjevalnik.

Naj bo uplink edini popustljivi vmesnik

Če naj bo nadrejena stran privzeti usmerjevalnik, tam sprejemajte oglase kljub posredovanju in nikjer drugje:

# /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

Omejitev je pomembna, ker je posredovanje IPv6 v Linuxu eno globalno stikalo, ne eno na povezavo. Vpišite 1 v net.ipv6.conf.wg0.forwarding in nato preberite net.ipv6.conf.all.forwarding: globalna vrednost se obrne in vsak vmesnik začne posredovati. Ne morete biti usmerjevalnik na tunelu in navaden gostitelj na lokalnem omrežju. Kar lahko omejite, je sprejemanje. Držite accept_ra=2 na uplinku, vmesnika tunela in lokalnega omrežja pa pustite na 1 ali 0, da zablodeli oglas, ki prispe po tunelu, ne more namestiti privzete poti, ki kaže vanj.

Začasni sysctl -w ne bo preživel naslednjega zagona, in tako systemd-networkd kot NetworkManager zapisujeta te vrednosti iz svoje konfiguracije. V networkd nastavite IPv6Forwarding=yes in IPv6AcceptRA=yes v datoteki .network uplinka; networkd opisuje IPv6Forwarding kot globalno iz istega razloga v jedru. Pri NetworkManagerju je ipv6.method=auto na uplinku tisto, kar poganja vrednost accept_ra, zato po nmcli connection up znova preberite sysctl, namesto da bi zaupali prvi preveritvi.

Statična alternativa, ip -6 route add default via fe80::1 dev eth0, res deluje in je razumen odgovor, ko ima nadrejeni usmerjevalnik stabilen naslov na lokalni povezavi. Bodite jasni glede tega, čemu se odrekate. Statična privzeta pot se nikoli ne obnovi in nikoli ne umakne, zato še naprej kaže na mrtvega soseda, potem ko nadrejeni usmerjevalnik zamenjate. Pot RA odpove varno; statična odpove tiho.

Preizkusite posredovani paket, ne prehodovega lastnega

Prehodovi lastni pingi lahko uspejo na poti, ki je noben odjemalec ne more uporabiti, in lahko uspejo tudi zato, ker je prehod vir. Preizkusite s povezanega odjemalca in nato prehod vprašajte, kaj bi storil za naslov tega odjemalca:

# 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

Nato počakajte eno življenjsko dobo usmerjevalnika in poglejte znova. Stabilno stanje, ki ga želite, je privzeta pot z oznako proto ra, katere vrednost expires se nenehno ponastavlja, plus all.forwarding=1. Če expires samo odšteva, se oglasi še vedno nekje zavržejo, običajni krivec pa je upravitelj omrežja, ki prepiše accept_ra, potem ko se je sysctl ob zagonu že izvedel.

Preden to zaključite, potrdite štiri stvari: privzeta pot je proto ra in se obnavlja, accept_ra=2 velja samo za uplink, posredovanje je po ponovnem zagonu in po ponovnem zagonu upravitelja še vedno 1, in odjemalec, ne prehod, dokonča ping IPv6. Če odjemalec ob zdravi poti še vedno ne uspe, je naslednji sumljivec povratna pot ali nadrejeni požarni zid, ne oglas.