Comprovar una VPN sense interfície: un flux cada vegada, amb evidència
Una caixa sense interfície necessita una petició la resposta de la qual pugueu llegir. Proveu cada família d'adreces, context i destinació, i després anoteu què no va cobrir el resultat.
En una caixa sense interfície no hi ha navegador per obrir ni cadenat per mirar, així que la comprovació ha de ser una petició la resposta de la qual pugueu llegir. Sembla trivial fins que us adoneu que un sol resultat d'adreça de sortida s'utilitza per certificar un dispositiu que executa una dotzena de serveis, dues famílies d'adreces i un proxy. El recorregut següent construeix una peça d'evidència limitada cada vegada, en el mateix context en què s'executa realment la càrrega de treball.
Decidiu què ha de demostrar la prova
Abans d'executar res, escriviu l'expectativa en una línia: quin flux, per quina interfície, cap a quina destinació i què s'ha d'observar a l'altre extrem. Una prova sense una expectativa declarada produeix un nombre que ningú no pot interpretar.
La versió més útil nomena un punt final aprovat que informa de l'adreça d'origen que ha vist.
Aquest punt final és l'única part que heu d'organitzar. Tota la resta és una observació del costat del client, i les observacions del costat del client fallen de maneres interessants.
Executeu l'observació en el context correcte
L'intèrpret d'ordres d'un administrador no és l'entorn de la càrrega de treball. Pot portar una variable de proxy diferent, una taula d'encaminament diferent en un altre espai de noms o un fitxer d'entorn d'un altre usuari. Executeu la prova en el mateix context d'amfitrió, contenidor, espai de noms o servei que allò que comproveu. Si no, esteu mesurant el vostre intèrpret d'ordres.
En un amfitrió normal això vol dir el mateix usuari i la mateixa unitat. En un entorn de contenidors vol dir entrar a l'espai de noms de xarxa del contenidor en lloc de provar des de l'amfitrió. En un servei de systemd pot vol dir una unitat transitòria amb la mateixa configuració.
La petició següent només té sentit quan sou en el context correcte.
Comproveu les famílies d'adreces per separat
Demaneu cada família explícitament, perquè una petició IPv4 correcta no exercita gens un camí IPv6. Els selectors --ipv4 i --ipv6 forcen l'elecció, i la diferència entre els dos resultats és en si mateixa informació.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceUna petició IPv6 fallida no és prova d'un bloqueig efectiu. Pot voler dir que el punt final no té cap adreça IPv6, que DNS no ha retornat res d'utilitzable o que el dispositiu no té cap ruta IPv6. Llegiu la fallada abans de treure'n una conclusió. Una petició IPv6 correcta a través del túnel és l'únic resultat que demostra que el camí IPv6 està cobert.
Anoteu les dues respostes costat a costat. Una de sola és la meitat d'un fet.
Afegiu les quatre coses que una comprovació de sortida no veu
Una adreça de sortida respon una pregunta. Quatre més decideixen si el túnel es comporta com es va dissenyar.
| 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 destinacions va primer: proveu un flux que s'hauria d'incloure i un que s'hauria d'excloure, quan el disseny té una divisió. Després DNS, on inspecteu el camí real del resolutor en lloc del valor configurat, perquè una resposta en memòria cau o una configuració impresa no diu res sobre on ha anat una consulta nova.
El comportament davant d'un error necessita un pla i un camí de recuperació preservat. Observeu una petició nova mentre el túnel no està disponible, i recordeu que una connexió oberta antiga no és evidència sobre la política d'error. El cicle de vida va al final: repetiu l'observació després d'una reconnexió o un reinici del servei si aquests esdeveniments afecten el requisit.
Anoteu evidència, no un veredicte
Per a cada resultat conserveu el context del procés, la destinació, la família d'adreces, l'hora i l'origen observat. Aquest conjunt és evidència limitada sobre els fluxos que heu exercitat, i és defensable precisament perquè diu què ha cobert.
No és una auditoria dels registres de l'operador de VPN, ni un certificat per a cada aplicació futura del dispositiu.
Escriviu els límits al costat del resultat. Una prova que declara què no ha cobert sobreviu a la revisió, mentre que una que afirma que el dispositiu està verificat no ho fa. Tingueu el manual de curl al costat dels selectors de família que heu fet servir, i tingueu la taula de quatre files amb els resultats.