Verificarea unui VPN fără interfață: un flux pe rând, cu dovezi
O cutie fără interfață are nevoie de o cerere al cărei răspuns poate fi citit. Testați fiecare familie de adrese, context și destinație, apoi notați ce nu a acoperit rezultatul.
Pe o cutie fără interfață nu există browser de deschis și nici lacăt de privit, așa că verificarea trebuie să fie o cerere al cărei răspuns poate fi citit. Sună trivial până când observați că un singur rezultat de adresă de ieșire este folosit pentru a certifica un dispozitiv care rulează o duzină de servicii, două familii de adrese și un proxy. Parcursul de mai jos construiește o singură dovadă limitată pe rând, în același context în care sarcina de lucru rulează cu adevărat.
Decideți ce trebuie să demonstreze testul
Înainte de a rula ceva, scrieți așteptarea într-o singură linie: care flux, prin ce interfață, către ce destinație și ce ar trebui observat la celălalt capăt. Un test fără o așteptare declarată produce un număr pe care nimeni nu îl poate interpreta.
Cea mai utilă versiune numește un punct final aprobat care raportează adresa sursă pe care a văzut-o.
Acel punct final este singura parte pe care trebuie să o pregătiți. Tot restul este o observație pe partea clientului, iar observațiile pe partea clientului eșuează în moduri interesante.
Executați observația în contextul corect
Shell-ul unui administrator nu este mediul sarcinii de lucru. Poate transporta altă variabilă de proxy, alt tabel de rutare într-un alt spațiu de nume sau fișierul de mediu al altui utilizator. Executați testul în același context de gazdă, container, spațiu de nume sau serviciu ca ceea ce verificați. Altfel măsurați propriul shell.
Pe o gazdă obișnuită asta înseamnă același utilizator și aceeași unitate. Într-un mediu cu containere înseamnă intrarea în spațiul de nume de rețea al containerului în loc de testarea de pe gazdă. Pe un serviciu systemd poate însemna o unitate tranzitorie cu aceleași setări.
Cererea care urmează are sens doar când sunteți în contextul corect.
Verificați familiile de adrese separat
Cereți fiecare familie în mod explicit, deoarece o cerere IPv4 reușită nu exersează deloc o cale IPv6. Selectoarele --ipv4 și --ipv6 forțează alegerea, iar diferența dintre cele două rezultate este ea însăși informație.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceO cerere IPv6 eșuată nu este dovada unui blocaj eficient. Poate însemna că punctul final nu are adresă IPv6, că DNS nu a returnat nimic utilizabil sau că dispozitivul nu are nicio rută IPv6. Citiți eșecul înainte de a trage o concluzie. O cerere IPv6 reușită prin tunel este singurul rezultat care dovedește că calea IPv6 este acoperită.
Notați ambele răspunsuri alături. Unul singur este jumătate dintr-un fapt.
Adăugați cele patru lucruri pe care o verificare de ieșire le ratează
O adresă de ieșire răspunde la o întrebare. Alte patru decid dacă tunelul se comportă conform proiectării.
| 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 |
Politica de destinații vine prima: testați un flux care ar trebui inclus și unul care ar trebui exclus, când proiectul are o divizare. Apoi DNS, unde inspectați calea reală a resolverului în loc de valoarea configurată, deoarece un răspuns din cache sau o setare tipărită nu spune nimic despre unde a mers o interogare nouă.
Comportamentul la eșec are nevoie de un plan și de o cale de recuperare păstrată. Observați o cerere nouă cât timp tunelul nu este disponibil și amintiți-vă că o conexiune veche deschisă nu este dovadă despre politica de eșec. Ciclul de viață vine ultimul: repetați observația după o reconectare sau o repornire a serviciului dacă acele evenimente afectează cerința.
Înregistrați dovezi, nu o sentință
Pentru fiecare rezultat păstrați contextul procesului, destinația, familia de adrese, momentul și sursa observată. Acel set este o dovadă limitată despre fluxurile pe care le-ați exersat și este apărabil exact pentru că spune ce a acoperit.
Nu este un audit al evidențelor operatorului VPN și nici un certificat pentru fiecare aplicație viitoare de pe dispozitiv.
Scrieți limitele lângă rezultat. Un test care declară ce nu a acoperit trece de revizuire, în timp ce unul care susține că dispozitivul este verificat nu trece. Țineți manualul curl lângă selectoarele de familie folosite și țineți tabelul cu patru rânduri împreună cu rezultatele.