Comprobar una VPN sin interfaz: un flujo cada vez, con evidencia
Una caja sin interfaz necesita una petición cuya respuesta pueda leer. Pruebe cada familia de direcciones, contexto y destino, y luego anote qué no cubrió el resultado.
En una caja sin interfaz no hay navegador que abrir ni candado que mirar, así que la comprobación tiene que ser una petición cuya respuesta pueda leer. Eso suena trivial hasta que uno repara en que un solo resultado de dirección de salida se usa para certificar un dispositivo que ejecuta una docena de servicios, dos familias de direcciones y un proxy. El recorrido siguiente construye una pieza de evidencia acotada cada vez, en el mismo contexto en el que se ejecuta realmente la carga de trabajo.
Decida qué debe demostrar la prueba
Antes de ejecutar nada, escriba la expectativa en una línea: qué flujo, por qué interfaz, hacia qué destino y qué debería observarse en el otro extremo. Una prueba sin una expectativa declarada produce un número que nadie puede interpretar.
La versión más útil nombra un punto de conexión aprobado que informa de la dirección de origen que vio.
Ese punto de conexión es la única parte que hay que preparar. Todo lo demás es una observación del lado del cliente, y las observaciones del lado del cliente fallan de formas interesantes.
Ejecute la observación en el contexto correcto
El intérprete de un administrador no es el entorno de la carga de trabajo. Puede llevar otra variable de proxy, otra tabla de rutas en otro espacio de nombres u otro archivo de entorno de usuario. Ejecute la prueba en el mismo contexto de host, contenedor, espacio de nombres o servicio que aquello que comprueba. De lo contrario, está midiendo su intérprete.
En un host normal eso significa el mismo usuario y la misma unidad. En un entorno de contenedores significa entrar en el espacio de nombres de red del contenedor en lugar de probar desde el host. En un servicio de systemd puede significar una unidad transitoria con la misma configuración.
La petición siguiente solo tiene sentido cuando está en el contexto correcto.
Compruebe las familias de direcciones por separado
Pregunte por cada familia de forma explícita, porque una petición IPv4 correcta no ejercita en absoluto una ruta IPv6. Los selectores --ipv4 y --ipv6 fuerzan la elección, y la diferencia entre ambos resultados es en sí misma información.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceUna petición IPv6 fallida no es prueba de un bloqueo efectivo. Puede significar que el punto de conexión no tiene dirección IPv6, que DNS no devolvió nada utilizable o que el dispositivo no tiene ninguna ruta IPv6. Lea el fallo antes de extraer una conclusión. Una petición IPv6 correcta a través del túnel es el único resultado que demuestra que la ruta IPv6 está cubierta.
Anote ambas respuestas una al lado de la otra. Una sola de ellas es la mitad de un hecho.
Añada las cuatro cosas que una comprobación de salida pasa por alto
Una dirección de salida responde a una pregunta. Otras cuatro deciden si el túnel se comporta como se diseñó.
| Check | What it proves | What it does not |
|---|---|---|
| Included and excluded destinations | The split behaves as designed for those flows | Coverage of any other destination |
| Resolver path | Where a fresh lookup actually travelled | Where a cached answer came from |
| Tunnel-down behaviour | The failure policy for a new request | What an already open connection does |
| Reconnect and restart | The requirement survives the lifecycle event | Behaviour under load or partial failure |
La política de destinos va primero: pruebe un flujo que debería incluirse y otro que debería excluirse, cuando el diseño tiene una división. Después DNS, donde se inspecciona la ruta real del resolutor en lugar del valor configurado, porque una respuesta en caché o una configuración impresa no dice nada sobre adónde fue una consulta nueva.
El comportamiento ante fallos necesita un plan y una ruta de recuperación preservada. Observe una petición nueva mientras el túnel no está disponible, y recuerde que una conexión abierta antigua no es evidencia sobre la política de fallos. El ciclo de vida va al final: repita la observación tras una reconexión o un reinicio del servicio si esos eventos afectan al requisito.
Registre evidencia, no un veredicto
Para cada resultado conserve el contexto del proceso, el destino, la familia de direcciones, la hora y el origen observado. Ese conjunto es evidencia acotada sobre los flujos que ejercitó, y es defendible precisamente porque dice qué cubrió.
No es una auditoría de los registros del operador de VPN ni un certificado para cada aplicación futura del dispositivo.
Escriba los límites junto al resultado. Una prueba que declara qué no cubrió sobrevive a la revisión, mientras que una que afirma que el dispositivo está verificado no lo hace. Mantenga el manual de curl junto a los selectores de familia que usó, y mantenga la tabla de cuatro filas junto a los resultados.