IPv6 uitzetten om een VPN-lek te verhelpen? Bepaal liever het beleid

Een adres uit het IPv6-bereik verschijnt op een testpagina, de tunnel draagt het duidelijk niet, en het populairste advies op internet is om IPv6 overal uit te zetten. Dat commando maakt het paneel inderdaad stil. Het verwijdert ook een protocol waarvan het toegangsnetwerk afhankelijk kan zijn, en het laat je achter zonder enig idee of het adres een echt lek was, een link-local interfaceadres, of een resolver die zijn werk doet. Drie voorwaarden bepalen de juiste controle, en slechts één daarvan leidt tot blokkeren.

Stel vast wat het hulpmiddel werkelijk heeft gemeten

De meest voorkomende valse alarm is een link-local adres, dat begint met fe80: en op elke IPv6-geschikte interface bestaat, ongeacht of de machine het internet via IPv6 bereikt. Het verschijnt in interfacelijsten en in sommige applicatiediagnostiek, en het zegt niets over je verkeerspad.

Het tweede valse alarm is een uniek lokaal adres in fc00::/7, een particulier bereik dat binnen een netwerk wordt gebruikt. Een hulpmiddel dat elk adres van de host afdrukt, zet het graag naast het publieke. Wie snel leest, noemt dat een lek en besteedt vervolgens een uur aan een probleem dat niet bestaat.

Het derde is helemaal geen vals alarm. Een globaal adres dat buiten de tunnel het internet bereikt, is het echte lek, en het is de moeite waard dat te meten voordat je iets beslist:

ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co

Als het eerste commando een globaal adres afdrukt en het derde een publiek IPv6-adres teruggeeft dat niet van de tunnel is, heb je een echte route buiten de tunnel. Als het eerste niets anders dan link-local-vermeldingen afdrukt, was er nooit een lek om te verhelpen.

Drie voorwaarden bepalen de controle

De beslissing is niet "IPv6 goed" of "IPv6 slecht". Het is in welke van drie situaties je zit, en elk heeft een ander juist antwoord met een andere prijs als je het mis hebt.

De eerste rij is wat mensen meestal bedoelen, en die is legitiem. Een client waarvan de uitgang geen IPv6 ondersteunt, mag het eigen IPv6-verkeer van de host niet stil laten uitgaan, want dat is het gedocumenteerde dual-stack-lek. Het punt is het als verklaard beleid te blokkeren, niet een protocol in de kernel uit te zetten. Het zichtbare resultaat is identiek en slechts één van beide kan later worden nagegaan.

De derde rij is waar het algemene advies actief schadelijk wordt. Mobiele operators en sommige thuisverbindingen draaien IPv6-only-netwerken met vertaling voor IPv4-bestemmingen. Haal daar IPv6 weg en je haalt het enige transport weg dat het netwerk biedt, wat een veel ergere storing oplevert dan degene die je aan het debuggen was.

Heeft de uitgang geen IPv6, blokkeer het dan bewust

Geef de voorkeur aan het mechanisme van de client zelf, want het geldt precies zolang de tunnel staat en wordt teruggedraaid als hij valt. OpenVPN heeft hiervoor een optie, en iptables heeft een gelijkwaardige regel voor andere clients:

block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachable

De richtlijn hoort in het profiel; de regel hoort in een firewall die je kunt nagaan en verwijderen. Beide falen gesloten, wat je wilt, en beide zijn zichtbaar in een configuratiediff, wat een in een opstartscript begraven kernel-sysctl niet is.

Noteer waarom die er is. Een blokkeerregel zonder commentaar wordt verwijderd door de volgende persoon die IPv6 voor iets anders nodig heeft, en dan komt het lek stilletjes terug.

Draagt de uitgang IPv6, route het dan en test beide families

IPv6 dragen is het betere antwoord wanneer de server het ondersteunt, en het is niet veel moeilijker. De eis is dat de tunnelinterface een adres in die familie heeft en dat de standaardroute daarvoor de tunnel in wijst in plaats van uit de fysieke interface:

ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.co

De routeopzoeking is de beslissende test: als die de tunnelinterface noemt, wordt IPv6-verkeer gedragen. De twee curl-aanroepen bevestigen dan wat elke familie ziet, en ze vergelijken is de manier om te bewijzen dat beide paden nu via dezelfde uitgang vertrekken.

Stop niet bij een geslaagde verbinding. Verbind de tunnel opnieuw en controleer nog eens, want een gepushte IPv6-route kan bij herstel verloren gaan als de server hem alleen in de beginconfiguratie stuurt. Controleer daarna één uitgesloten bestemming, want split-tunnelregels zijn waar de twee families het vaakst van mening verschillen.

Is het toegangsnetwerk alleen IPv6, laat het dan met rust

Sommige netwerken bieden alleen IPv6 en verwachten dat het apparaat IPv4-diensten bereikt via een vertaalmechanisme aan de kant van de operator. IPv6 uitzetten op zo'n machine is geen beveiligingsverbetering; het verwijdert de enige route naar wat dan ook. Dat is een zelfveroorzaakte storing ten behoeve van een testresultaat dat niemand nodig had.

Het symptoom van dit fout doen is onmiskenbaar en onaangenaam: de tunnel lijkt tot stand te komen, naamresolutie werkt, en niets laadt. Zie je dat na een IPv6-wijziging, herstel de instelling dan onmiddellijk en ga verder met de diagnose elders.

Wat je ook kiest, houd de beslissing expliciet in het profiel of de firewall, koppel die aan wat de uitgang werkelijk ondersteunt, en noteer het dual-stackgedrag dat de RFC 7359-discussie over dual stack beschrijft. Een verklaarde blokkade is beleid. Een uitgezet protocol is een omweg die niemand kan controleren, en vanaf de testpagina zien ze er identiek uit.