La implicita IPv6-itinero malaperis post ŝalti plusendadon en Linukso

Mi agordis net.ipv6.conf.all.forwarding=1 sur Debian-pordego por ke ĝi povu plusendi la trafikon de VPN-klientoj, kaj proksimume duonhoron poste la maŝino havis neniun implicitan IPv6-itinerojn plu. La supra enkursigilo funkciis, la link-local najbaro ankoraŭ respondis, kaj la suprenligo ankoraŭ tenis sian tutmondan adreson. Tio, kio ĉesis, estis la pretemo de la kerno daŭre akcepti router advertisements sur tiu interfaco. La itinero ne malaperis kiam mi tajpis la sysctl; ĝi malaperis kiam la vivdaŭro de la RA-lernita implicita itinero finiĝis kaj nenio ĝin renovigis.

Nenio ŝajnis rompita unuavide. La plusendado funkciis, la klientoj ankoraŭ trapasis dum la malnova itinero estis en la kaŝmemoro, kaj la paneo alvenis pli malfrue ol la ŝanĝo, kiu ĝin kaŭzis. Ĝuste tiu prokrasto klarigas, kial oni kulpigas la supran flankon aŭ fajroŝirmilan regulon, kiu neniam estis implikita.

Legu la itineran tabelon antaŭ ol tuŝi ajnan sysctl

Komencu per ip -6 route show default kaj legu la atributojn, ne nur la pordegon. RA-lernita implicita itinero estas markita per proto ra, portas preferon kaj montras expires-kalkulon malantaŭen. Itinero aldonita permane havas nek unu nek la alian, kaj tiu diferenco diras al vi, kiu mekanismo posedas la itineron.

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

Poste rigardu la adreson: ip -6 addr show dev eth0. Tutmonda adreso kun preferataj kaj validaj vivdaŭroj mezuritaj en horoj postvivos implicitan itineron, kies enkursigila vivdaŭro mezuriĝas en minutoj. Adreso ĉeestas kaj implicita itinero mankas, tio estas la subskribo de anonca problemo. Se ankaŭ la adreso mankas, unue oni devas postkuri la ligon, la prefiksan informon aŭ la detekton de duoblaj adresoj.

Kial plusendado malŝaltas RA-traktadon

RA estas ICMPv6-paketo de tipo 134, sendita el link-local fonto kun saltlimo 255. Antaŭ ol la kerno uzas ĝin, ĝi konsultas la accept_ra de la interfaco. La implicita valoro estas 1, kaj 1 ne signifas jes. Ĝi signifas: akceptu nur dum ĉi tiu gastiganto ne plusendas. Agordu forwarding=1 kaj tiu kondiĉo malsukcesas, do la anonco estas forĵetita antaŭ ol konsideri ajnan prefikson aŭ implicitan enkursigilon en ĝi.

Ekzistas tri valoroj, kaj nur la tria postvivas plusendadon:

Du pliaj flagoj decidas, kio efektive estas instalita. accept_ra_defrtr regas ĉu la implicita enkursigilo en la anonco fariĝas itinero, kaj accept_ra_pinfo regas ĉu prefiksa informo estas uzata por adresa agordo. Malŝalti accept_ra_defrtr estas la kutima maniero konservi SLAAC-adresojn sur plusendanta gastiganto sen lerni implicitan itineron. Ĝi estas alia levilo ol accept_ra, kaj oni uzas ĝin kiam oni volas adresojn sed ne itineron. La referenco de la kerno pri IP sysctl listigas ĉiujn tri.

Konfirmu per tri komandoj

Unue, legu la vivajn valorojn anstataŭ la dosieron, kiun vi kredas ŝargita:

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

Due, pruvu, ke la anoncoj ankoraŭ alvenas. Filtri laŭ la ICMPv6-tipa bitoko sufiĉas, kaj ĝi ŝparas al vi legi muron da najbara malkovra trafiko:

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

Se dum pluraj minutoj nenio aperas, accept_ra ne estas via problemo. La supra flanko ĉesis anonci, io sur la vojo filtras ICMPv6, aŭ tiu interfaco ne vere estas en la segmento, kiun vi pensas. Trie, petu anoncon mem kaj legu ĝiajn kampojn:

rdisc6 eth0

rdisc6 venas en la pako ndisc6 ĉe Debian kaj Ubuntu. En la eligo rigardu la enkursigilan vivdaŭron kaj la preferon antaŭ ol ŝanĝi ion ajn alian. Anonco kun enkursigila vivdaŭro 0 estas instrukcio forigi la implicitan enkursigilon, kaj neniu accept_ra-valoro faras el tio uzeblan itineron. Tiel ankaŭ vi kaptas supran CPE en ponta reĝimo, kiu disdonas prefiksojn sed neniam proponas sin kiel enkursigilon.

Faru la suprenligon la sola permesa interfaco

Se la supra flanko devas esti la implicita enkursigilo, akceptu anoncojn tie malgraŭ plusendado, kaj nenie alie:

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

La limigo gravas ĉar IPv6-plusendado en Linukso estas unu tutmonda ŝaltilo, ne unu por ligo. Skribu 1 en net.ipv6.conf.wg0.forwarding kaj poste legu net.ipv6.conf.all.forwarding: la tutmonda valoro renversiĝas kaj ĉiu interfaco komencas plusendi. Vi ne povas esti enkursigilo sur la tunelo kaj ordinara gastiganto sur la loka reto. Tion, kion vi povas limigi, estas la akcepto. Tenu accept_ra=2 sur la suprenligo kaj lasu la tunelajn kaj lokretajn interfacojn je 1 aŭ 0, por ke vaganta anonco alvenanta tra la tunelo ne povu instali implicitan itineron montrantan en ĝin.

Provizora sysctl -w ne postvivos la sekvan restarigon, kaj kaj systemd-networkd kaj NetworkManager skribas tiujn valorojn el sia propra agordo. En networkd agordu IPv6Forwarding=yes kaj IPv6AcceptRA=yes en la .network-dosiero de la suprenligo; networkd dokumentas IPv6Forwarding kiel tutmondan pro la sama kerna kialo. Ĉe NetworkManager, ipv6.method=auto sur la suprenligo estas tio, kio stiras la valoron accept_ra, do relegu la sysctl post nmcli connection up anstataŭ fidi la unuan kontrolon.

La statika alternativo, ip -6 route add default via fe80::1 dev eth0, ja funkcias, kaj ĝi estas racia respondo kiam la supra enkursigilo havas stabilan link-local adreson. Estu klara pri tio, kion vi cedas. Statika implicita itinero neniam renoviĝas kaj neniam retiriĝas, do ĝi daŭre montras al mortinta najbaro post kiam la supra flanko anstataŭiĝis. La RA-itinero paneas sekure; la statika paneas silente.

Testu plusenditan paketon, ne tiun de la pordego mem

La propraj pingoj de la pordego povas sukcesi sur itinero, kiun neniu kliento povas uzi, kaj ili povas sukcesi ankaŭ ĉar la pordego estas la fonto. Testu el konektita kliento kaj poste demandu la pordegon, kion ĝi farus por la adreso de tiu kliento:

# 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

Poste atendu unu enkursigilan vivdaŭron kaj rigardu denove. La stabila stato, kiun vi volas, estas implicita itinero markita per proto ra, kies expires-valoro konstante rekomenciĝas, plus all.forwarding=1. Se expires nur kalkulas malantaŭen, anoncoj ankoraŭ forĵetiĝas ie, kaj la kutima kulpulo estas retadministrilo, kiu reskribas accept_ra post kiam la sysctl de la startigo jam ekzekutiĝis.

Antaŭ ol fermi ĉi tion, konfirmu kvar aferojn: la implicita itinero estas proto ra kaj renoviĝas, accept_ra=2 validas nur por la suprenligo, plusendado estas ankoraŭ 1 post restarigo kaj post restarigo de la administrilo, kaj kliento, ne la pordego, finplenumas IPv6-pingon. Se la kliento ankoraŭ malsukcesas kun sana itinero, la sekva suspektato estas la revena vojo aŭ supra fajroŝirmilo, ne la anonco.