IPv6 vaikimisi marsruut kadus pärast edastamise lubamist Linuxis

Seadsin Debiani lüüsile net.ipv6.conf.all.forwarding=1, et see saaks VPN-klientide liiklust edasi saata, ja umbes poole tunni pärast ei olnud masinal enam ühtegi IPv6 vaikimisi marsruuti. Ülemvõrgu ruuter oli töös, link-local naaber vastas endiselt ja uplink hoidis oma globaalset aadressi. See, mis oli lakanud, oli kerneli valmisolek sellel liidesel router advertisements vastu võtta. Marsruut ei kadunud hetkel, mil ma sysctli sisestasin; see kadus siis, kui RA-st õpitud vaikimisi marsruudi eluiga lõppes ja miski ei uuendanud seda.

Esmapilgul ei tundunud miski katki olevat. Edastamine töötas, kliendid pääsesid läbi seni, kuni vana marsruut oli veel vahemälus, ja rike saabus hiljem kui selle põhjustanud muudatus. Just see viivitus on põhjus, miks seda pannakse ülemvõrgu või tulemüürireegli süüks, mis ei olnud kunagi asjaga seotud.

Lugege marsruuditabelit enne, kui puudutate ükskõik millist sysctli

Alustage käsuga ip -6 route show default ja lugege atribuute, mitte ainult lüüsi. RA-st õpitud vaikimisi marsruut on märgitud proto ra, kannab eelistust ja näitab expires loendurit. Käsitsi lisatud marsruudil ei ole kumbagi, ja see erinevus ütleb, milline mehhanism marsruuti omab.

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

Seejärel vaadake aadressi: ip -6 addr show dev eth0. Globaalne aadress, mille eelistatud ja kehtivad eluead on mõõdetud tundides, elab üle vaikimisi marsruudi, mille ruuteri eluiga mõõdetakse minutites. Aadress on olemas, vaikimisi marsruut aga puudub, see on teadete probleemi tunnus. Kui ka aadress puudub, tuleb esmalt tegeleda lingi, prefiksi teabe või duplikaataadresside tuvastamisega.

Miks edastamine RA töötlemise välja lülitab

RA on 134 tüüpi ICMPv6 pakett, mis saadetakse link-local allikast hüppe piiranguga 255. Enne kui kernel seda kasutab, kontrollib ta liidese accept_ra väärtust. Vaikeväärtus on 1 ja 1 ei tähenda jah. See tähendab: võta vastu ainult seni, kuni see host ei edasta. Määrake forwarding=1 ja see tingimus ei kehti, seega teade visatakse ära enne, kui selles sisalduvat prefiksit või vaikimisi ruuterit arvestatakse.

Väärtusi on kolm ja edastamise elab üle ainult kolmas:

Veel kaks lippu otsustavad, mis tegelikult paigaldatakse. accept_ra_defrtr juhib, kas teates olev vaikimisi ruuterist saab marsruut, ja accept_ra_pinfo juhib, kas prefiksi teavet kasutatakse aadressi konfiguratsiooniks. accept_ra_defrtr välja lülitamine on tavaline viis hoida SLAAC-aadresse edastaval hostil ilma vaikimisi marsruuti õppimata. See on teine hoob kui accept_ra ja selle järele haaratakse siis, kui aadresse tahetakse, marsruuti aga mitte. Kerneli IP sysctli viide loetleb kõik kolm.

Kinnitage seda kolme käsuga

Kõigepealt lugege elavaid väärtusi, mitte faili, mida arvate olevat laaditud:

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

Teiseks tõestage, et teated veel saabuvad. ICMPv6 tüübibaidi järgi filtreerimine on piisav ja säästab teid naabrite avastamise liikluse seina lugemisest:

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

Kui mitme minuti jooksul ei ilmu midagi, ei ole accept_ra teie probleem. Ülemvõrk lõpetas teavitamise, midagi teel filtreerib ICMPv6-t või ei ole see liides tegelikult segmendis, mida arvate. Kolmandaks küsige teadet ise ja lugege selle välju:

rdisc6 eth0

rdisc6 tuleb Debianis ja Ubuntus paketiga ndisc6. Väljundist vaadake ruuteri eluiga ja eelistust enne, kui midagi muud muudate. Teade, mille ruuteri eluiga on 0, on korraldus vaikimisi ruuter eemaldada, ja ükski accept_ra väärtus ei tee sellest kasutatavat marsruuti. Nii tabate ka silla režiimis ülemvõrgu CPE-d, mis jagab prefikse, kuid ei paku end kunagi ruuterina.

Tee uplinkist ainus lubav liides

Kui ülemvõrk peaks olema vaikimisi ruuter, võtke teateid vastu seal hoolimata edastamisest, ja mitte kusagil mujal:

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

Piiramine on oluline, sest IPv6 edastamine on Linuxis üks globaalne lüliti, mitte üks lingi kohta. Kirjutage 1 väärtusesse net.ipv6.conf.wg0.forwarding ja seejärel lugege net.ipv6.conf.all.forwarding: globaalne väärtus pöördub ja iga liides hakkab edastama. Te ei saa olla ruuter tunnelis ja tavaline host LAN-is. Piirata saate vastuvõttu. Hoidke accept_ra=2 uplinkil ja jätke tunneli ja LAN-i liidesed 1 või 0 peale, et tunnelist saabuv eksinud teade ei saaks paigaldada sellesse suunavat vaikimisi marsruuti.

Ajutine sysctl -w ei ela järgmist käivitust üle ning nii systemd-networkd kui ka NetworkManager kirjutavad need väärtused oma konfiguratsioonist. networkd-is määrake IPv6Forwarding=yes ja IPv6AcceptRA=yes uplinki .network failis; networkd dokumenteerib IPv6Forwardingi globaalsena sama kerneli põhjuse tõttu. NetworkManageri puhul juhib uplinkil ipv6.method=auto accept_ra väärtust, seega lugege sysctli uuesti pärast nmcli connection up, selle asemel et usaldada esimest kontrolli.

Staatiline alternatiiv, ip -6 route add default via fe80::1 dev eth0, töötab tõesti ja on mõistlik vastus, kui ülemvõrgu ruuteril on stabiilne link-local aadress. Olge selge selles, millest loobute. Staatilist vaikimisi marsruuti ei uuendata kunagi ja seda ei võeta kunagi tagasi, seega jääb see pärast ülemvõrgu väljavahetamist osutama surnud naabrile. RA marsruut ebaõnnestub turvaliselt; staatiline ebaõnnestub vaikselt.

Testige edastatud paketti, mitte lüüsi enda oma

Lüüsi enda pingid võivad õnnestuda marsruudil, mida ükski klient kasutada ei saa, ja need võivad õnnestuda ka seetõttu, et lüüs on allikas. Testige ühendatud kliendilt ja seejärel küsige lüüsilt, mida see selle kliendi aadressi jaoks teeks:

# 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

Seejärel oodake üks ruuteri eluiga ja vaadake uuesti. Soovitud püsiseisund on vaikimisi marsruut, mis on märgitud proto ra ja mille expires väärtus lähtestub pidevalt, pluss all.forwarding=1. Kui expires ainult loeb alla, visatakse teateid ikka veel kuskil ära, ja tavaline süüdlane on võrguhaldur, mis kirjutab accept_ra üle pärast seda, kui alglaadimise sysctl on juba jooksnud.

Enne kui selle lõpetate, kinnitage neli asja: vaikimisi marsruut on proto ra ja uueneb, accept_ra=2 kehtib ainult uplinkil, edastamine on pärast taaskäivitust ja halduri taaskäivitust endiselt 1, ning IPv6 pingi sooritab klient, mitte lüüs. Kui klient ei saa tervisliku marsruudiga ikka hakkama, on järgmine kahtlusalune tagasitee või ülemvõrgu tulemüür, mitte teade.