Com provar IPv6 a través d'una VPN amb el teu propi recurs

Una pàgina pública de comprovació d'IP respon una pregunta, i normalment no la que has fet. Et diu l'adreça de sortida que ha observat la pàgina; no et diu si la ruta IPv6 a través del túnel funciona, si l'amfitrió ha preferit IPv6 o ha retrocedit, ni si una aplicació exclosa ha agafat un camí diferent. Un recurs autoritzat que controles respon correctament la pregunta més estreta, perquè veus els dos extrems. El procediment de sota tracta d'obtenir una conclusió que puguis defensar, no d'obtenir un resultat verd.

Pas 1: digues quina ruta IPv6 estàs provant

Digues-ho en una frase. Una petició a l'adreça IPv6 pròpia del servidor del túnel prova el túnel; una petició a un amfitrió més enllà de la sortida prova la sortida IPv6 de la sortida; una petició a una adreça IPv6 privada prova una ruta interna.

Són tres afirmacions diferents i una sola petició reeixida no pot sostenir-les totes. Tria la que importa per a la decisió que tens davant i escriu-la abans d'executar res. Si la preocupació és si IPv6 s'escapa al voltant del túnel, la pregunta és sobre la selecció de ruta de l'amfitrió, no sobre l'abast de la sortida. Si la preocupació és si el costat llunyà pot arribar a un servei intern, la sortida és irrellevant.

Pas 2: confirma que l'amfitrió selecciona aquesta ruta

ip -6 route get 2001:db8:1::10 imprimeix la ruta, l'adreça d'origen i la interfície que faria servir el nucli, i és el fet del qual depèn la resta de la prova.

Que existeixi una interfície no és el mateix que sigui seleccionada. Els amfitrions de doble pila tenen una taula de precedència, i /etc/gai.conf a Linux pot canviar quina família guanya per a un nom que es resol a les dues.

Pas 3: fes servir una destinació i un nom legítims

Si proves HTTPS, fes servir el nom d'amfitrió per al qual es va emetre el certificat i mantén la verificació activa; passar a una adreça literal per fer passar la prova desactiva exactament la comprovació que demostra que has arribat a l'amfitrió previst. Un servei de diagnòstic que controlis, que respongui en un nom conegut amb un certificat vàlid, és l'objectiu més net. També et dona una línia de registre al costat del servidor per correlacionar, cosa que un comprovador de tercers mai no farà.

Executa la petició en una forma que mostri l'adreça que ha utilitzat: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/. El -6 força la família, i així separen IPv6 no funciona de IPv6 no es va preferir.

Per a una comprovació pura d'abast on es permet ICMPv6, ping -6 -c 3 2001:db8:1::10 és suficient. Demostra el camí i res per sobre.

Pas 4: correlaciona els dos extrems

Quan tens accés als dos extrems, executa tcpdump -ni any ip6 and host 2001:db8:1::10 al client i l'equivalent al recurs, amb marques de temps, i confirma que el mateix flux apareix als dos. Això és el que converteix un resultat plausible en evidència: la visió del client sola no pot distingir una resposta del recurs d'una resposta d'alguna cosa entremig. Mantén la captura estreta a una sola destinació perquè la sortida segueixi llegible i la sessió no relacionada de ningú no acabi al fitxer.

Repeteix la prova després d'una reconnexió si la preocupació és si la política sobreviu a un reinici. L'estat de ruta i de tallafoc aplicat un cop en connectar pot diferir de l'estat que es torna a aplicar, i la diferència només es veu a la segona connexió.

Prova el cas de fallada per separat si el necessites. Un túnel que bloqueja IPv6 quan cau i un que el deixa escapar són dissenys diferents, i només un d'ells es pot verificar amb una petició reeixida.

Pas 5: escriu què no ha demostrat la prova

El pas cinc és escriure què no ha demostrat la prova, i és la part que es deixa caure. Una prova reeixida d'un extrem privat no demostra la sortida IPv6 pública, no demostra el comportament del DNS i no cobreix les aplicacions que has exclòs del túnel. Cadascuna d'aquestes necessita la seva pròpia destinació i la seva pròpia observació. Una nota que diu que IPv6 funciona després d'una petició a un amfitrió no és una troballa; és una conjectura amb una marca de temps.

El registre que val la pena guardar és curt: la destinació, el nom, l'adreça d'origen que ha triat l'amfitrió, l'adreça remota observada i l'hora. RFC 7359 discuteix com provar que una ruta IPv6 rellevant és realment utilitzable, i és l'estàndard al qual aquest procediment s'aproxima amb eines més simples. Si la conclusió necessita un comprovador públic per ser certa, la prova no era prou específica.