Skal vi slå av IPv6 for å rette ein VPN-lekkasje? Avgjer policyen i staden

Ei adresse frå IPv6-området dukkar opp på ei testside, tunnelen ber henne tydeleg ikkje, og det mest populære rådet på internett er å slå av IPv6 overalt. Den kommandoen får panelet til å teie. Han fjernar òg ein protokoll som aksessnettet kan vere avhengig av, og han lèt deg stå utan noko aning om adressa var ein ekte lekkasje, ei link-local-grensesnittadresse eller ein resolver som gjer jobben sin. Tre vilkår avgjer rett kontroll, og berre eitt av dei fører til blokkering.

Finn ut kva verktøyet faktisk målte

Den vanlegaste falske alarmen er ei link-local-adresse, som byrjar med fe80: og finst på kvart IPv6-kompatible grensesnitt, same om maskina når internett over IPv6 eller ikkje. Ho dukkar opp i grensesnittlister og i nokre programdiagnostikkar, og seier ingenting om trafikkvegen din.

Den andre falske alarmen er ei unik lokal adresse i fc00::/7, som er eit privat område brukt inne i eit nettverk. Eit verktøy som skriv ut kvar adresse verten har, viser henne gjerne ved sida av den offentlege. Den som les snøgt, kallar det ein lekkasje og brukar deretter ein time på eit problem som ikkje finst.

Den tredje er slett ikkje ein falsk alarm. Ei global adresse som når internett utanfor tunnelen, er den ekte lekkasjen, og ho er verd å måle før du avgjer noko:

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

Viss den første kommandoen skriv ut ei global adresse og den tredje returnerer ei offentleg IPv6-adresse som ikkje er tunnelens, har du ein reell veg utanfor tunnelen. Viss den første ikkje skriv ut anna enn link-local-oppføringar, har det aldri vore ein lekkasje å rette.

Tre vilkår avgjer kontrollen

Avgjerda er ikkje "IPv6 bra" eller "IPv6 dårleg". Det er kva av tre situasjonar du er i, og kvar har eit anna rett svar med ein annan kostnad viss du tek feil.

Den første rada er det folk vanlegvis meiner, og ho er legitim. Ein klient der utgangen ikkje støttar IPv6, bør ikkje i det stille sleppe verten sin eigen IPv6-trafikk ut, for det er den dokumenterte dual-stack-lekkasjen. Poenget er å blokkere det som ein erklært policy, ikkje å slå av ein protokoll i kjernen. Det synlege resultatet er identisk, og berre eitt av dei kan gjennomgåast seinare.

Den tredje rada er der det generelle rådet blir aktivt skadeleg. Mobiloperatørar og nokre heimeforbindingar køyrer IPv6-only-nettverk med omsetjing for IPv4-destinasjonar. Fjern IPv6 der, og du fjernar den einaste transporten nettverket byr på, noko som gir eit mykje verre avbrot enn det du feilsøkte.

Viss utgangen ikkje har IPv6, blokker han med vilje

Føretrekk mekanismen til klienten sjølv, fordi han gjeld nøyaktig medan tunnelen er oppe og går tilbake når han fell. OpenVPN har eit alternativ for dette, og iptables har ein tilsvarande regel for andre klientar:

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

Direktivet høyrer heime i profilen; regelen høyrer heime i ein brannmur du kan gjennomgå og fjerne. Begge feilar lukka, som er det du vil, og begge er synlege i ein konfigurasjonsdiff, noko ein kjerne-sysctl gravlagd i eit oppstartsskript ikkje er.

Skriv ned kvifor han er der. Ein blokkeringsregel utan kommentar blir fjerna av den neste som treng IPv6 til noko anna, og då kjem lekkasjen stille tilbake.

Viss utgangen ber IPv6, rut det og test begge familiar

Å bera IPv6 er det betre svaret når tenaren støttar det, og det er ikkje mykje vanskelegare. Kravet er at tunnelgrensesnittet har ei adresse i den familien, og at standardruta for henne peikar inn i tunnelen og ikkje ut av det fysiske grensesnittet:

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

Ruteoppslaget er den avgjerande testen: viss det nemner tunnelgrensesnittet, blir IPv6-trafikk boren. Dei to curl-kalla stadfester deretter kva kvar familie ser, og å samanlikne dei er måten å prove at begge vegane no forlèt same utgang.

Ikkje stopp ved ei vellukka tilkopling. Kople tunnelen på nytt og kontroller igjen, fordi ei skyvd IPv6-rute kan gå tapt ved gjenoppretting viss tenaren berre sender henne i den første konfigurasjonen. Kontroller deretter ein utelukka destinasjon, fordi split-tunnel-reglar er der dei to familiane oftast er usamde.

Viss aksessnettet berre er IPv6, la det vere

Nokre nettverk leverer berre IPv6 og ventar at eininga når IPv4-tenester gjennom ein omsetjingsmekanisme på operatørsida. Å slå av IPv6 på ei slik maskin er ikkje ei sikkerheitsbetring; det fjernar den einaste vegen til noko som helst. Det er eit sjølvpåført avbrot til ære for eit testresultat ingen trong.

Symtomet på å gjere dette feil er umiskjenneleg og ubehageleg: tunnelen ser ut til å etablere seg, namneoppslag verkar, og ingenting blir lasta. Viss du ser det etter ei IPv6-endring, gjenopprett innstillinga straks og hald fram diagnostikken ein annan stad.

Uansett kva du vel, hald avgjerda eksplisitt i profilen eller brannmuren, bind henne til det utgangen faktisk støttar, og noter dual-stack-åtferda som RFC 7359-diskusjonen om dual stack skildrar. Ein erklært blokkering er ein policy. Ein avslått protokoll er ein omveg ingen kan revidere, og frå testsida ser dei identiske ut.