Comprobar unha VPN sen interfaz: un fluxo cada vez, con evidencia
Unha caixa sen interfaz necesita unha petición cuxa resposta poida ler. Probe cada familia de enderezos, contexto e destino, e logo anote que non cubriu o resultado.
Nunha caixa sen interfaz non hai navegador que abrir nin candado que mirar, así que a comprobación ten que ser unha petición cuxa resposta poida ler. Iso soa trivial ata que un repara en que un só resultado de enderezo de saída se usa para certificar un dispositivo que executa unha ducia de servizos, dúas familias de enderezos e un proxy. O percorrido seguinte constrúe unha peza de evidencia limitada cada vez, no mesmo contexto no que se executa realmente a carga de traballo.
Decida que debe demostrar a proba
Antes de executar nada, escriba a expectativa nunha liña: que fluxo, por que interface, cara a que destino e que debería observarse no outro extremo. Unha proba sen unha expectativa declarada produce un número que ninguén pode interpretar.
A versión máis útil nomea un punto de conexión aprobado que informa do enderezo de orixe que viu.
Ese punto de conexión é a única parte que hai que preparar. Todo o demais é unha observación do lado do cliente, e as observacións do lado do cliente fallan de xeitos interesantes.
Execute a observación no contexto correcto
A consola dun administrador non é a contorna da carga de traballo. Pode levar outra variable de proxy, outra táboa de rutas noutro espazo de nomes ou o ficheiro de contorno doutro usuario. Execute a proba no mesmo contexto de host, contedor, espazo de nomes ou servizo que aquilo que comproba. Se non, está a medir a súa consola.
Nun host normal iso significa o mesmo usuario e a mesma unidade. Nunha contorna de contedores significa entrar no espazo de nomes de rede do contedor en lugar de probar desde o host. Nun servizo de systemd pode significar unha unidade transitoria coa mesma configuración.
A petición seguinte só ten sentido cando está no contexto correcto.
Comprobe as familias de enderezos por separado
Pregunte por cada familia de forma explícita, porque unha petición IPv4 correcta non exercita en absoluto unha ruta IPv6. Os selectores --ipv4 e --ipv6 forzan a elección, e a diferenza entre os dous resultados é en si mesma información.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceUnha petición IPv6 fallida non é proba dun bloqueo efectivo. Pode significar que o punto de conexión non ten enderezo IPv6, que DNS non devolveu nada utilizábel ou que o dispositivo non ten ningunha ruta IPv6. Lea o fallo antes de extraer unha conclusión. Unha petición IPv6 correcta a través do túnel é o único resultado que demostra que a ruta IPv6 está cuberta.
Anote ambas as respostas unha ao lado da outra. Unha soa delas é a metade dun feito.
Engada as catro cousas que unha comprobación de saída pasa por alto
Un enderezo de saída responde a unha pregunta. Outras catro deciden se o túnel se comporta como se deseñou.
| 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 |
A política de destinos vai primeiro: probe un fluxo que debería incluírse e outro que debería excluírse, cando o deseño ten unha división. Despois DNS, onde se inspecciona a ruta real do resolutor en lugar do valor configurado, porque unha resposta en caché ou unha configuración impresa non di nada sobre onde foi unha consulta nova.
O comportamento ante fallos necesita un plan e unha ruta de recuperación preservada. Observe unha petición nova mentres o túnel non está dispoñible, e lembre que unha conexión aberta antiga non é evidencia sobre a política de fallos. O ciclo de vida vai ao final: repita a observación tras unha reconexión ou un reinicio do servizo se eses eventos afectan o requisito.
Rexiste evidencia, non un veredicto
Para cada resultado conserve o contexto do proceso, o destino, a familia de enderezos, a hora e a orixe observada. Ese conxunto é evidencia limitada sobre os fluxos que exercitou, e é defendíbel precisamente porque di que cubriu.
Non é unha auditoría dos rexistros do operador de VPN nin un certificado para cada aplicación futura do dispositivo.
Escriba os límites xunto ao resultado. Unha proba que declara que non cubriu sobrevive á revisión, mentres que unha que afirma que o dispositivo está verificado non. Manteña o manual de curl xunto aos selectores de familia que usou, e manteña a táboa de catro filas cos resultados.