Dues pàgines de prova no coincideixen: una informa de l’adreça del proveïdor pel túnel, la segona informa del vostre prefix de casa, i la conclusió òbvia és que la VPN filtra. Aquesta conclusió salta un pas, perquè els dos informes van exercir dues decisions d’encaminament diferents i només una havia d’entrar al túnel. L’escletxa sol ser real, i és un problema de cobertura més que un túnel trencat. Tres preguntes ho resolen: quin flux va sortir realment, quina ruta va triar el nucli per a ell i quin comportament pretenia el client.

Treballeu en aquest ordre. Respondre-les fora d’ordre produeix una llarga discussió sobre si el client és defectuós quan la resposta real és que mai no es va instal·lar cap ruta IPv6.

Quin flux va sortir realment, i per quin adaptador

Comenceu amb una prova que anomeni la família que ha utilitzat, després anoteu l’aplicació, la xarxa d’accés, el perfil vigent i si la connexió ofereix IPv6. Aquests quatre fets fan comparables dues execucions, i el quart és el que la gent oblida: una xarxa sense prefix v6 no pot filtrar v6, i una xarxa que n’afegeix un més tard canvia la resposta.

Envieu una petició per família en lloc de carregar una pàgina i llegir-ne el resultat. Una sola pàgina pot barrejar recursos v6 i v4, un procés en segon pla pot comportar-se diferent de la pestanya que teniu davant, i una resposta emmagatzemada pot sobreviure al canvi de xarxa que intenteu provar. Fixeu el destí que proveu i anoteu-lo, perquè una execució repetida mesuri el mateix.

Llegir la ruta que va triar el nucli

La taula de rutes respon la pregunta que el navegador no pot. Pregunteu al sistema on aniria un destí concret, i incloeu les regles de política així com el valor per defecte visible, perquè qualsevol dels dos el pot alterar:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

Un prefix més específic és el motiu habitual que un destí quedi fora del túnel mentre la resta es queda a dins, i una regla de política pot fer el mateix amb una prioritat més alta que qualsevol ruta. Llegiu també la mètrica, perquè dues entrades per al mateix prefix es resolen per mètrica i no pel seu ordre a la pantalla. A Windows la llista equivalent és Get-NetRoute -AddressFamily IPv6, ordenada per mètrica per coincidir amb l’ordre de decisió. Una regla que sembla correcta a la taula encara pot perdre davant una regla de política amb un número més baix, i per això la llista de regles pertany al mateix alè que la llista de rutes.

D’on ve la política IPv6 del client

Un client es pot construir perquè porti v6 pel túnel, perquè el refusi o perquè permeti una excepció anomenada, i aquestes tres intencions produeixen tres resultats correctes diferents. Llegiu el perfil i la documentació del propi client abans de qualificar una observació de filtració, perquè un client que bloqueja v6 mentre el sistema operatiu encara envia descobriment de veïns per l’enllaç físic es comporta tal com està dissenyat.

Una aplicació exclosa deliberadament del túnel és un cas diferent d’una família que el túnel mai no va portar. El primer és una decisió sobre un programa, el segon és una escletxa de cobertura, i la reparació difereix en conseqüència. Llegiu la llista de programes exclosos del client abans de buscar una ruta que mai no havia d’existir.

Observació estreta, quan la taula no coincideix

Quan la consulta de ruta és ambigua, una sola observació d’interfície a l’amfitrió ho pot resoldre, però només si apunta a la pregunta. El trànsit cap al punt final de la VPN travessarà l’adaptador físic per disseny; el que importa és si el flux de l’aplicació, adreçat en un altre lloc completament, també hi apareix. Filtreu la captura al destí que proveu en lloc de recollir-ho tot.

Una captura àmplia exposa molt més trànsit personal del que exigeix la pregunta. També respon la pregunta menys clarament, perquè el flux que us importa arriba enterrat en un corrent de connexions no relacionades. Filtreu al destí provat, atureu-vos després d’unes quantes trames i suprimiu la captura.

Tres maneres de tancar l’escletxa

Porteu la família pel túnel, bloquegeu-la al client quan el túnel no la pot portar, o registreu una excepció deliberada amb un propietari i una data de revisió. Cadascuna és defensable, i l’única cosa que no ho és, és deixar l’elecció implícita, perquè una elecció implícita és el que la filtració és en realitat. Si el túnel no té cap sortida v6, refusar v6 al client és alhora honest i provable. L’important és que l’elecció estigui escrita on la propera persona la trobarà, no inferida del comportament sis mesos després.

Repetiu la comprovació després de reconnectar i després de moure-us entre xarxes, perquè una ruta instal·lada per a l’enllaç anterior pot sobreviure al canvi. Després anoteu el destí, la ruta seleccionada, la política del client i la família que va utilitzar la prova, perquè la propera persona llegeixi una decisió en lloc de tornar a deduir-la. RFC 7359 documenta la filtració de doble pila com un problema de disseny i no com un error, i és la referència que cal citar quan algú afirma que un túnel v4 que funciona ho cobreix tot.

Articles relacionats