Ska vi stänga av IPv6 för att fixa ett VPN-läckage? Bestäm policyn i stället

En adress från IPv6-området dyker upp på en testsida, tunneln bär den uppenbarligen inte, och internets populäraste råd är att stänga av IPv6 överallt. Det kommandot får panelen att tystna. Det tar också bort ett protokoll som åtkomstnätet kan vara beroende av, och det lämnar dig utan en aning om adressen var ett riktigt läckage, en link-local-gränssnittsadress eller en resolver som gör sitt jobb. Tre villkor avgör rätt kontroll, och bara ett av dem leder till blockering.

Ta reda på vad verktyget faktiskt mätte

Det vanligaste falska larmet är en link-local-adress, som börjar med fe80: och finns på varje IPv6-kapabelt gränssnitt, oavsett om maskinen når internet över IPv6. Den dyker upp i gränssnittslistor och i vissa applikationsdiagnostiker, och säger ingenting om din trafikväg.

Det andra falska larmet är en unik lokal adress i fc00::/7, vilket är ett privat område som används inne i ett nätverk. Ett verktyg som skriver ut varje adress värden har visar den gärna bredvid den offentliga. Den som läser snabbt kallar det ett läckage och lägger sedan en timme på ett problem som inte finns.

Det tredje är inte alls ett falskt larm. En global adress som når internet utanför tunneln är det riktiga läckaget, och det är värt att mäta innan du bestämmer något:

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

Om det första kommandot skriver ut en global adress och det tredje returnerar en offentlig IPv6-adress som inte är tunnelns, har du en verklig väg utanför tunneln. Om det första inte skriver ut något annat än link-local-poster har det aldrig funnits ett läckage att fixa.

Tre villkor avgör kontrollen

Beslutet är inte "IPv6 bra" eller "IPv6 dåligt". Det är vilken av tre situationer du är i, och var och en har ett annat rätt svar med en annan kostnad om du har fel.

Den första raden är vad folk vanligtvis menar, och den är legitim. En klient vars utgång inte stöder IPv6 bör inte i tysthet släppa ut värdens egen IPv6-trafik, eftersom det är det dokumenterade dual-stack-läckaget. Poängen är att blockera det som en deklarerad policy, inte att stänga av ett protokoll i kärnan. Det synliga resultatet är identiskt och bara en av dem kan granskas senare.

Den tredje raden är där det allmänna rådet blir aktivt skadligt. Mobiloperatörer och vissa hemanslutningar kör IPv6-only-nätverk med översättning för IPv4-destinationer. Ta bort IPv6 där och du tar bort den enda transport nätverket erbjuder, vilket ger ett mycket värre avbrott än det du felsökte.

Om utgången inte har IPv6, blockera den med avsikt

Föredra klientens egen mekanism, eftersom den gäller exakt så länge tunneln är uppe och återgår när den faller. OpenVPN har ett alternativ för detta, och iptables har en motsvarande regel för andra klienter:

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

Direktivet hör hemma i profilen; regeln hör hemma i en brandvägg du kan granska och ta bort. Båda misslyckas stängda, vilket är vad du vill, och båda syns i en konfigurationsdiff, vilket en kärn-sysctl begravd i ett startskript inte gör.

Skriv ner varför den finns. En blockeringsregel utan kommentar tas bort av nästa person som behöver IPv6 till något annat, och då kommer läckaget tyst tillbaka.

Om utgången bär IPv6, rutta det och testa båda familjerna

Att bära IPv6 är det bättre svaret när servern stöder det, och det är inte mycket svårare. Kravet är att tunnelgränssnittet har en adress i den familjen och att standardrutten för den pekar in i tunneln och inte ut ur det fysiska gränssnittet:

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

Ruttuppslaget är det avgörande testet: om det namnger tunnelgränssnittet bärs IPv6-trafik. De två curl-anropen bekräftar sedan vad varje familj ser, och att jämföra dem är sättet att bevisa att båda vägarna nu lämnar via samma utgång.

Stanna inte vid en lyckad anslutning. Återanslut tunneln och kontrollera igen, eftersom en pushad IPv6-rutt kan gå förlorad vid återupprättande om servern bara skickar den i den inledande konfigurationen. Kontrollera sedan en utesluten destination, eftersom split-tunnel-regler är där de två familjerna oftast går isär.

Om åtkomstnätet bara är IPv6, låt det vara

Vissa nätverk levererar bara IPv6 och förväntar sig att enheten når IPv4-tjänster genom en översättningsmekanism på operatörens sida. Att stänga av IPv6 på en sådan maskin är ingen säkerhetsförbättring; det tar bort den enda vägen till något alls. Det är ett självförvållat avbrott för ett testresultat som ingen behövde.

Symtomet på att göra detta fel är omisskännligt och obehagligt: tunneln verkar upprättas, namnmatchning fungerar och ingenting laddas. Om du ser det efter en IPv6-ändring, återställ inställningen omedelbart och fortsätt diagnostiken någon annanstans.

Vad du än väljer, håll beslutet explicit i profilen eller brandväggen, bind det till vad utgången verkligen stöder, och notera det dual-stack-beteende som RFC 7359-diskussionen om dual stack beskriver. En deklarerad blockering är en policy. Ett avstängt protokoll är en kringgång som ingen kan granska, och från testsidan ser de identiska ut.