IPv6-verstekroete het verdwyn nadat aanstuur op Linux aangeskakel is

Ek het net.ipv6.conf.all.forwarding=1 op 'n Debian-deurlaat gestel sodat dit VPN-kliëntverkeer kon deurstuur, en omtrent 'n halfuur later het die masjien geen IPv6-verstekroete oor gehad nie. Die opstroomroeteerder was aan, die skakel-plaaslike buur het steeds geantwoord, en die opstroom het steeds sy globale adres gehad. Wat opgehou het, was die kernel se bereidheid om aan te hou om routeraankondigings op daardie koppelvlak te aanvaar. Die roete het nie verdwyn toe ek die sysctl getik het nie; dit het verdwyn toe die leeftyd van die RA-geleerde verstek verstryk het en niks dit vernuwe het nie.

Niks het op die oog af stukkend gelyk nie. Aanstuur het gewerk, kliënte het deurgekom terwyl die ou roete nog gekas was, en die fout het later opgedaag as die verandering wat dit veroorsaak het. Dié vertraging is hoekom dit aan die opstroom of aan 'n vuurmuurreël wat nooit betrokke was nie, toegeskryf word.

Lees die roetetabel voordat jy enige sysctl aanraak

Begin met ip -6 route show default en lees die eienskappe, nie net die poort nie. 'n RA-geleerde verstek is gemerk proto ra, dra 'n voorkeur, en wys 'n expires-aftelling. 'n Roete wat jy met die hand bygevoeg het, het nie een van die twee nie, en daardie verskil sê vir jou watter meganisme die roete besit.

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

Kyk dan na die adres: ip -6 addr show dev eth0. 'n Globale adres met voorkeur- en geldige leeftye gemeet in ure sal 'n verstekroete oorleef waarvan die roeteerderleeftyd in minute gemeet word. Adres teenwoordig plus verstek ontbreek is die kenmerk van 'n aankondigingsprobleem. Adres ook ontbreek beteken die skakel, die voorvoegselinligting of duplikaatadresopsporing is die ding om eerste na te jaag.

Hoekom aanstuur RA-verwerking afskakel

'n RA is 'n ICMPv6-pakket van tipe 134, gestuur vanaf 'n skakel-plaaslike bron met hoplimiet 255. Voordat die kernel dit gebruik, raadpleeg dit die koppelvlak se accept_ra. Die verstekwaarde is 1, en 1 beteken nie ja nie. Dit beteken aanvaar net terwyl hierdie gasheer nie aanstuur nie. Stel forwarding=1 en daardie voorwaarde misluk, so die aankondiging word laat vaar voordat enige voorvoegsel of verstekroeteerder daarin oorweeg word.

Drie waardes bestaan, en net die derde oorleef aanstuur:

Twee ander vlae besluit wat werklik geïnstalleer word. accept_ra_defrtr beheer of die verstekroeteerder in die aankondiging 'n roete word, en accept_ra_pinfo beheer of voorvoegselinligting vir adreskonfigurasie gebruik word. Om accept_ra_defrtr af te skakel is die gewone manier om SLAAC-adresse op 'n aansturende gasheer te hou sonder om 'n verstek te leer. Dit is 'n ander hefboom as accept_ra, en dit is die een om te gebruik wanneer jy adresse wil hê maar nie 'n roete nie. Die kernel IP-sysctl-verwysing lys al drie.

Bevestig dit met drie opdragte

Lees eers die lewende waardes in plaas van die lêer wat jy dink gelaai is:

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

Bewys tweedens dat die aankondigings steeds aankom. Filter op die ICMPv6-tipegreep is genoeg, en dit vermy om 'n muur buurontdekkingverkeer te lees:

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

As niks oor etlike minute verskyn nie, is accept_ra nie jou probleem nie. Die opstroom het opgehou adverteer, iets op die pad filter ICMPv6, of daardie koppelvlak is nie regtig op die segment wat jy dink nie. Vra derdens self 'n aankondiging aan en lees die velde:

rdisc6 eth0

rdisc6 kom in die pakket ndisc6 op Debian en Ubuntu. Kyk in die uitset na die roeteerderleeftyd en die voorkeur voordat jy iets anders verander. 'n Aankondiging met 'n roeteerderleeftyd van 0 is 'n opdrag om die verstekroeteerder te verwyder, en geen accept_ra-waarde maak daarvan 'n bruikbare roete nie. Dit is ook hoe jy 'n opstroom-CPE in bruggmodus vang wat voorvoegsels uitdeel maar homself nooit as 'n roeteerder aanbied nie.

Maak die opstroom die enigste toelatende koppelvlak

As die opstroom veronderstel is om die verstekroeteerder te wees, aanvaar aankondigings daar ten spyte van aanstuur, en nêrens anders nie:

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

Die begrensing maak saak omdat IPv6-aanstuur een globale skakelaar in Linux is, nie een per skakel nie. Skryf 1 na net.ipv6.conf.wg0.forwarding en lees dan net.ipv6.conf.all.forwarding: die globale waarde draai om en elke koppelvlak begin aanstuur. Jy kan nie 'n roeteerder op die tonnel en 'n gewone gasheer op die LAN wees nie. Wat jy wel kan begrens, is aanvaarding. Hou accept_ra=2 op die opstroom en laat die tonnel- en LAN-koppelvlakke op 1 of 0, sodat 'n verdwaalde aankondiging wat oor die tonnel aankom nie 'n verstek kan installeer wat daarin wys nie.

'n Tydelike sysctl -w sal nie die volgende herbegin oorleef nie, en beide systemd-networkd en NetworkManager skryf hierdie waardes vanuit hul eie konfigurasie. Stel in networkd IPv6Forwarding=yes en IPv6AcceptRA=yes in die opstroom se .network-lêer; networkd dokumenteer IPv6Forwarding as globaal om dieselfde kernelrede. Met NetworkManager is ipv6.method=auto op die opstroom wat die accept_ra-waarde dryf, so lees die sysctl weer ná nmcli connection up eerder as om die eerste kontrole te vertrou.

Die statiese alternatief, ip -6 route add default via fe80::1 dev eth0, werk wel, en dit is 'n redelike antwoord wanneer die opstroomroeteerder 'n stabiele skakel-plaaslike adres het. Wees duidelik oor wat jy prysgee. 'n Statiese verstek word nooit vernuwe nie en nooit teruggetrek nie, so dit bly wys na 'n dooie buur nadat die opstroom vervang is. Die RA-roete faal veilig; die statiese een faal stil.

Toets 'n deurgestuurde pakket, nie die deurlaat se eie nie

Die deurlaat se eie pings kan slaag op 'n roete wat geen kliënt kan gebruik nie, en hulle kan ook slaag omdat die deurlaat die bron is. Toets vanaf 'n gekoppelde kliënt en vra dan die deurlaat wat dit vir daardie kliënt se adres sou doen:

# 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

Wag dan een roeteerderleeftyd en kyk weer. Die bestendige toestand wat jy wil hê, is 'n verstek gemerk proto ra waarvan die expires-waarde aanhou herstel, plus all.forwarding=1. As expires net aftel, word aankondigings steeds êrens laat vaar, en die gewone skuldige is 'n netwerkbestuurder wat accept_ra herskryf nadat die sysctl by die selflaai reeds geloop het.

Voordat jy dit afsluit, bevestig vier dinge: die verstekroete is proto ra en vernuwe, accept_ra=2 geld net vir die opstroom, aanstuur is steeds 1 ná 'n herbegin en ná 'n bestuurder-herbegin, en 'n kliënt eerder as die deurlaat voltooi 'n IPv6-ping. As die kliënt steeds misluk met 'n gesonde roete, is die volgende verdagte die terugpad of 'n opstroom-vuurmuur, nie die aankondiging nie.