Una adreça del rang IPv6 apareix en una pàgina de prova, el túnel és clar que no la transporta, i el consell més popular d'internet és desactivar IPv6 a tot arreu. Aquesta ordre sí que fa callar el tauler. També elimina un protocol del qual la xarxa d'accés pot dependre, i us deixa sense cap idea de si l'adreça era una fuita real, una adreça d'interfície link-local o un resolutor fent la seva feina. Tres condicions decideixen el control correcte, i només una porta a bloquejar.

Identifiqueu què ha mesurat realment l'eina

La falsa alarma més habitual és una adreça link-local, que comença amb fe80: i existeix a cada interfície compatible amb IPv6 tant si la màquina pot arribar a internet per IPv6 com si no. Apareix en llistats d'interfícies i en alguns diagnòstics d'aplicacions, i no diu res sobre el camí del vostre trànsit.

La segona falsa alarma és una adreça local única dins de fc00::/7, que és un rang privat usat dins d'una xarxa. Una eina que imprimeixi totes les adreces que té l'amfitrió la llistarà encantada al costat de la pública. Qui llegeix de pressa ho anomena fuita i després passa una hora en un problema que no existeix.

La tercera no és cap falsa alarma. Una adreça global que arriba a internet fora del túnel és la fuita real, i val la pena mesurar-la abans de decidir res:

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

Si la primera ordre imprimeix una adreça global i la tercera retorna una adreça IPv6 pública que no és la del túnel, teniu un camí real fora del túnel. Si la primera no imprimeix res més que entrades link-local, mai no hi va haver cap fuita a arreglar.

Tres condicions decideixen el control

La decisió no és "IPv6 bo" o "IPv6 dolent". És en quina de tres situacions sou, i cadascuna té una resposta correcta diferent amb un cost diferent si us equivoqueu.

SituationCorrect controlCost if you disable IPv6 instead
Exit has no IPv6, host doesBlock IPv6 deliberately in the tunnel policySame visible result, no documentation of intent
Exit carries IPv6, host leaksRoute IPv6 into the tunnel and verifyYou lose IPv6 reachability entirely
Access network is IPv6-onlyChange nothing; use the tunnel's IPv6Machine loses connectivity completely

La primera fila és el que la gent vol dir normalment, i és legítima. Un client el punt de sortida del qual no té suport IPv6 no hauria de deixar sortir en silenci el trànsit IPv6 natiu de l'amfitrió, perquè aquesta és la fuita documentada de doble pila. La qüestió és bloquejar-ho com a política declarada, no desactivar un protocol al nucli. El resultat visible és idèntic i només un dels dos es pot revisar després.

La tercera fila és on el consell general es torna activament perjudicial. Els operadors mòbils i algunes connexions domèstiques fan funcionar xarxes IPv6-only amb traducció per a destinacions IPv4. Traieu IPv6 allà i traieu l'únic transport que ofereix la xarxa, cosa que produeix una caiguda molt pitjor que la que estàveu depurant.

Si el punt de sortida no té IPv6, bloquegeu-lo a propòsit

Preferiu el mecanisme propi del client, perquè s'aplica exactament mentre el túnel és actiu i es reverteix quan cau. OpenVPN té una opció per a això, i iptables té una regla equivalent per a altres clients:

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

La directiva pertany al perfil; la regla pertany a un tallafoc que podeu revisar i eliminar. Totes dues fallen tancades, que és el que voleu, i totes dues són visibles en un diff de configuració, cosa que un sysctl del nucli enterrat en un script d'inici no és.

Anoteu per què hi és. Una regla de bloqueig sense comentari la elimina la següent persona que necessiti IPv6 per a una cosa no relacionada, i llavors la fuita torna en silenci.

Si el punt de sortida transporta IPv6, encamineu-lo i proveu les dues famílies

Transportar IPv6 és la resposta millor quan el servidor ho admet, i no és gaire més difícil. El requisit és que la interfície del túnel tingui una adreça en aquesta família i que la ruta per defecte hi apunti cap al túnel i no cap a la interfície física:

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

La consulta de ruta és la prova decisiva: si anomena la interfície del túnel, el trànsit IPv6 s'està transportant. Les dues crides a curl confirmen després què veu cada família, i comparar-les és com es demostra que tots dos camins surten ara pel mateix punt de sortida.

No us atureu en una connexió correcta. Torneu a connectar el túnel i comproveu-ho de nou, perquè una ruta IPv6 empenyuda es pot perdre en restablir-se si el servidor només l'envia a la configuració inicial. Després comproveu una destinació exclosa, perquè les regles de túnel dividit són on les dues famílies més sovint discrepen.

Si la xarxa d'accés és només IPv6, deixeu-la estar

Algunes xarxes només ofereixen IPv6 i esperen que el dispositiu arribi als serveis IPv4 mitjançant un mecanisme de traducció al costat de l'operador. Desactivar IPv6 en una màquina així no és cap millora de seguretat; elimina l'única ruta cap a qualsevol cosa. És una caiguda autoinfligida al servei d'un resultat de prova que ningú no necessitava.

El símptoma d'equivocar-se aquí és inconfusible i desagradable: el túnel sembla establir-se, la resolució de noms funciona i no es carrega res. Si ho veieu després d'un canvi d'IPv6, restaureu el paràmetre immediatament i continueu el diagnòstic en un altre lloc.

Trieu el que trieu, mantingueu la decisió explícita al perfil o al tallafoc, lligueu-la al que el punt de sortida realment admet i anoteu el comportament de doble pila que descriu la discussió sobre doble pila del RFC 7359 . Un bloqueig declarat és una política. Un protocol desactivat és una solució provisional que ningú no pot auditar, i des de la pàgina de prova semblen idèntics.

Articles relacionats