Kontrol af en headless VPN: én strøm ad gangen, med bevis
En headless boks har brug for en anmodning, hvis svar du kan læse. Test hver adressefamilie, kontekst og destination, og notér derefter, hvad resultatet ikke dækkede.
På en headless boks er der ingen browser at åbne og ingen hængelås at kigge på, så kontrollen skal være en anmodning, hvis svar du kan læse. Det lyder trivielt, indtil du bemærker, at et enkelt exit-adresseresultat bruges til at certificere en enhed, der kører et dusin tjenester, to adressefamilier og en proxy. Gennemgangen nedenfor opbygger ét afgrænset bevis ad gangen, i den samme kontekst, som arbejdsbyrden faktisk kører i.
Beslut, hvad testen skal bevise
Før du kører noget, så skriv forventningen på én linje: hvilken strøm, gennem hvilket interface, til hvilken destination, og hvad der bør ses i den anden ende. En test uden en angivet forventning giver et tal, som ingen kan fortolke.
Den mest nyttige version navngiver et godkendt endepunkt, der rapporterer den kildeadresse, det så.
Det endepunkt er den eneste del, du skal arrangere. Alt andet er en observation på klientsiden, og observationer på klientsiden går galt på interessante måder.
Kør observationen i den rigtige kontekst
En administrators shell er ikke arbejdsbyrdens miljø. Den kan bære en anden proxyvariabel, en anden routingtabel i et andet namespace eller en anden brugers miljøfil. Kør testen i samme værts-, container-, namespace- eller tjenestekontekst som det, du kontrollerer. Ellers måler du din shell.
På en normal vært betyder det den samme bruger og den samme unit. I et containerlandskab betyder det at gå ind i containerens netværksnamespace i stedet for at teste fra værten. På en systemd-tjeneste kan det betyde en midlertidig unit med de samme indstillinger.
Den følgende anmodning er kun meningsfuld, når du er i den rigtige kontekst.
Kontroller adressefamilier hver for sig
Spørg udtrykkeligt til hver familie, fordi en vellykket IPv4-anmodning slet ikke udøver en IPv6-sti. Vælgerne --ipv4 og --ipv6 tvinger valget, og forskellen mellem de to resultater er i sig selv information.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceEn mislykket IPv6-anmodning er ikke bevis for en effektiv blokering. Det kan betyde, at endepunktet ikke har en IPv6-adresse, at DNS ikke returnerede noget brugbart, eller at enheden slet ikke har en IPv6-rute. Læs fejlen, før du drager en konklusion af den. En vellykket IPv6-anmodning gennem tunnelen er det eneste resultat, der beviser, at IPv6-stien er dækket.
Notér begge svar side om side. Ét af dem alene er halvdelen af en kendsgerning.
Tilføj de fire ting, en exit-kontrol overser
En exit-adresse besvarer ét spørgsmål. Fire mere afgør, om tunnelen opfører sig som designet.
| 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 |
Destinationspolitik kommer først: test en strøm, der bør medtages, og en, der bør udelades, når designet har en opdeling. Derefter DNS, hvor du undersøger den faktiske resolver-sti i stedet for den konfigurerede værdi, fordi et cachelagret svar eller en udskrevet indstilling intet siger om, hvor en ny forespørgsel gik hen.
Fejladfærd kræver en plan og en bevaret gendannelsessti. Observer en ny anmodning, mens tunnelen er utilgængelig, og husk, at en gammel åben forbindelse ikke er bevis om fejlpolitikken. Livscyklus kommer sidst: gentag observationen efter en genopkobling eller en tjenestegenstart, hvis disse hændelser påvirker kravet.
Notér bevis, ikke en dom
For hvert resultat skal du gemme proceskonteksten, destinationen, adressefamilien, tidspunktet og den observerede kilde. Det sæt er afgrænset bevis om de strømme, du har udøvet, og det er forsvarligt netop, fordi det siger, hvad det dækkede.
Det er ikke en revision af VPN-operatørens registreringer og ikke et certifikat for enhver fremtidig applikation på enheden.
Skriv grænserne ved siden af resultatet. En test, der angiver, hvad den ikke dækkede, overlever gennemgang, mens en, der hævder, at enheden er verificeret, ikke gør. Hold curl-manualen ved siden af de familie-vælgere, du brugte, og hold tabellen med fire rækker sammen med resultaterne.