Como probar IPv6 a través dunha VPN co teu propio recurso
Non necesitas un comprobador público de IPv6 para demostrar que un camiño funciona. Usa un recurso que controles, captura os dous extremos e indica o que non cubriu a proba.
Unha páxina pública de comprobación de IP responde a unha pregunta, e normalmente non á que fixeches. Diche o enderezo de saída que observou a páxina; non che di se a ruta IPv6 polo túnel funciona, se o host preferiu IPv6 ou retrocedeu, nin se unha aplicación excluída tomou outro camiño. Un recurso autorizado que controlas responde correctamente á pregunta máis estreita, porque ves os dous extremos. O procedemento de abaixo trata de chegar a unha conclusión que poidas defender, non de obter un resultado verde.
Paso 1: di que ruta IPv6 estás probando
Dio nunha frase. Unha petición ao enderezo IPv6 propio do servidor do túnel proba o túnel; unha petición a un host máis aló da saída proba a saída IPv6 da saída; unha petición a un enderezo IPv6 privado proba unha ruta interna.
Son tres afirmacións distintas e unha soa petición correcta non pode soster todas. Escolle a que importa para a decisión que tes diante e anótaa antes de executar nada. Se a preocupación é se IPv6 se escapa arredor do túnel, a pregunta é sobre a selección de ruta do host, non sobre o alcance da saída. Se a preocupación é se o lado remoto pode chegar a un servizo interno, a saída é irrelevante.
Paso 2: confirma que o host selecciona esa ruta
ip -6 route get 2001:db8:1::10 imprime a ruta, o enderezo de orixe e a interface que usaría o núcleo, e ese é o feito do que depende o resto da proba.
Que exista unha interface non é o mesmo que estea seleccionada. Os hosts de dobre pila teñen unha táboa de precedencia, e /etc/gai.conf en Linux pode cambiar que familia gaña para un nome que resolve a ambas.
Paso 3: usa un destino e un nome lexítimos
Se probas HTTPS, usa o nome de host para o que se emitiu o certificado e mantén a verificación activa; pasar a un enderezo literal para que a proba pase desactiva xustamente a comprobación que demostra que chegaches ao host previsto. Un servizo de diagnóstico que controlas, que responde nun nome coñecido cun certificado válido, é o obxectivo máis limpo. Tamén che dá unha liña de rexistro do lado do servidor coa que correlacionar, algo que un comprobador de terceiros nunca fará.
Executa a petición nunha forma que mostre o enderezo que usou: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/. O -6 forza a familia, e así separas IPv6 non funciona de IPv6 non se preferiu.
Para unha comprobación pura de alcance onde se permite ICMPv6, ping -6 -c 3 2001:db8:1::10 é suficiente. Demostra o camiño e nada por riba.
Paso 4: correlaciona os dous extremos
Cando tes acceso aos dous extremos, executa tcpdump -ni any ip6 and host 2001:db8:1::10 no cliente e o equivalente no recurso, con marcas de tempo, e confirma que o mesmo fluxo aparece nos dous. Iso é o que converte un resultado plausible en evidencia: a visión do cliente por si soa non pode distinguir unha resposta do recurso dunha resposta de algo intermedio. Mantén a captura axustada a un só destino para que a saída siga sendo lexible e a sesión non relacionada de ninguén acabe no ficheiro.
Repite a proba tras unha reconexión se a preocupación é se a política sobrevive a un reinicio. O estado de ruta e de cortalumes aplicado unha vez ao conectar pode diferir do estado que se volve aplicar, e a diferenza só aparece na segunda conexión.
Proba o caso de fallo por separado se o necesitas. Un túnel que bloquea IPv6 cando cae e un que o deixa escapar son deseños distintos, e só un deles pode verificarse cunha petición correcta.
Paso 5: escribe o que non demostrou a proba
O paso cinco é escribir o que non demostrou a proba, e é a parte que se adoita omitir. Unha proba correcta contra un extremo privado non demostra a saída IPv6 pública, non demostra o comportamento de DNS e non cobre as aplicacións que excluíches do túnel. Cada unha desas necesita o seu propio destino e a súa propia observación. Unha nota que di que IPv6 funciona tras unha petición a un host non é un achado; é unha conxectura cunha marca de tempo.
O rexistro que paga a pena gardar é curto: o destino, o nome, o enderezo de orixe que escolleu o host, o enderezo remoto observado e a hora. RFC 7359 trata de como probar que unha ruta IPv6 relevante é realmente utilizable, e ese é o estándar ao que este procedemento se aproxima con ferramentas máis simples. Se a conclusión necesita un comprobador público para ser certa, a proba non foi o bastante específica.