Dezactivăm IPv6 ca să reparăm o scurgere VPN? Mai bine decideți politica
O adresă link-local nu este o scurgere, iar o rută IPv6 globală nici atât. Alegeți mai întâi între blocare, transportare și lăsare în pace.
O adresă din intervalul IPv6 apare pe o pagină de test, tunelul clar nu o transportă, iar cel mai popular sfat de pe internet este să dezactivați IPv6 peste tot. Comanda aceea chiar face panoul tăcut. Însă elimină și un protocol de care rețeaua de acces poate depinde, și vă lasă fără nicio idee dacă adresa era o scurgere reală, o adresă de interfață link-local sau un resolver care își face treaba. Trei condiții decid controlul corect, și doar una duce la blocare.
Identificați ce a măsurat de fapt instrumentul
Cea mai frecventă alarmă falsă este o adresă link-local, care începe cu fe80: și există pe fiecare interfață compatibilă IPv6, indiferent dacă mașina ajunge la internet prin IPv6. Apare în listele de interfețe și în unele diagnostice ale aplicațiilor, și nu spune nimic despre calea traficului.
A doua alarmă falsă este o adresă locală unică în fc00::/7, care este un interval privat folosit în interiorul unei rețele. Un instrument care tipărește fiecare adresă a gazdei o va lista bucuros lângă cea publică. Cine citește în grabă o numește scurgere și apoi petrece o oră pe o problemă care nu există.
A treia nu este deloc o alarmă falsă. O adresă globală care ajunge la internet în afara tunelului este scurgerea reală, și merită măsurată înainte de a decide ceva:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coDacă prima comandă tipărește o adresă globală, iar a treia returnează o adresă IPv6 publică care nu este a tunelului, aveți o cale reală în afara tunelului. Dacă prima nu tipărește nimic altceva decât intrări link-local, nu a existat niciodată o scurgere de reparat.
Trei condiții decid controlul
Decizia nu este "IPv6 bun" sau "IPv6 rău". Este în care dintre trei situații vă aflați, iar fiecare are un răspuns corect diferit cu un cost diferit dacă greșiți.
| Situation | Correct control | Cost if you disable IPv6 instead |
|---|---|---|
| Exit has no IPv6, host does | Block IPv6 deliberately in the tunnel policy | Same visible result, no documentation of intent |
| Exit carries IPv6, host leaks | Route IPv6 into the tunnel and verify | You lose IPv6 reachability entirely |
| Access network is IPv6-only | Change nothing; use the tunnel's IPv6 | Machine loses connectivity completely |
Primul rând este ceea ce oamenii înțeleg de obicei, și este legitim. Un client a cărui ieșire nu suportă IPv6 nu ar trebui să lase în tăcere traficul IPv6 nativ al gazdei să iasă, pentru că aceea este scurgerea documentată la stivă dublă. Ideea este să o blocați ca politică declarată, nu să dezactivați un protocol în nucleu. Rezultatul vizibil este identic și doar unul dintre ele poate fi reverificat mai târziu.
Al treilea rând este locul unde sfatul general devine activ dăunător. Operatorii mobili și unele conexiuni de acasă rulează rețele IPv6-only cu traducere pentru destinații IPv4. Scoateți IPv6 acolo și scoateți singurul transport pe care rețeaua îl oferă, ceea ce produce o cădere mult mai gravă decât cea pe care o depanați.
Dacă ieșirea nu are IPv6, blocați-o intenționat
Preferați mecanismul clientului însuși, pentru că se aplică exact cât timp tunelul este ridicat și revine când acesta cade. OpenVPN are o opțiune pentru asta, iar iptables are o regulă echivalentă pentru alți clienți:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableDirectiva aparține profilului; regula aparține unui firewall pe care îl puteți reverifica și elimina. Ambele eșuează închis, ceea ce doriți, și ambele sunt vizibile într-un diff de configurație, ceea ce un sysctl de nucleu îngropat într-un script de pornire nu este.
Notați de ce este acolo. O regulă de blocare fără comentariu va fi eliminată de următoarea persoană care are nevoie de IPv6 pentru altceva, iar apoi scurgerea revine în tăcere.
Dacă ieșirea transportă IPv6, rutți-l și testați ambele familii
Transportarea IPv6 este răspunsul mai bun când serverul îl suportă, și nu este mult mai dificil. Cerința este ca interfața tunelului să aibă o adresă în acea familie și ca ruta implicită să indice în tunel, nu în afara interfeței fizice:
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.coCăutarea rutei este testul decisiv: dacă numește interfața tunelului, traficul IPv6 este transportat. Cele două apeluri curl confirmă apoi ce vede fiecare familie, iar compararea lor este modul de a demonstra că ambele căi ies acum prin aceeași ieșire.
Nu vă opriți la o conexiune reușită. Reconectați tunelul și verificați din nou, pentru că o rută IPv6 împinsă se poate pierde la restabilire dacă serverul o trimite doar în configurația inițială. Apoi verificați o destinație exclusă, pentru că regulile de tunel divizat sunt locul unde cele două familii se contrazic cel mai des.
Dacă rețeaua de acces este doar IPv6, lăsați-o în pace
Unele rețele oferă doar IPv6 și se așteaptă ca dispozitivul să ajungă la serviciile IPv4 printr-un mecanism de traducere din partea operatorului. Dezactivarea IPv6 pe o astfel de mașină nu este o îmbunătățire de securitate; elimină singura rută către orice. Este o cădere auto-provocaată de dragul unui rezultat de test de care nimeni nu avea nevoie.
Simptomul acestei greșeli este distinct și neplăcut: tunelul pare să se stabilească, rezolvarea numelor funcționează și nimic nu se încarcă. Dacă vedeți asta după o schimbare de IPv6, restabiliți setarea imediat și continuați diagnosticul în altă parte.
Orice ați alege, țineți decizia explicită în profil sau în firewall, legați-o de ceea ce ieșirea suportă cu adevărat, și notați comportamentul de stivă dublă pe care îl descrie discuția despre stiva dublă din RFC 7359 . O blocare declarată este o politică. Un protocol dezactivat este o ocolire pe care nimeni nu o poate audita, iar de pe pagina de test par identice.