Kontroll av en headless VPN: én strøm om gangen, med bevis
En headless boks trenger en forespørsel du kan lese svaret på. Test hver adressefamilie, kontekst og destinasjon, og noter deretter hva resultatet ikke dekket.
På en headless boks finnes det ingen nettleser å åpne og ingen hengelås å se på, så kontrollen må være en forespørsel du kan lese svaret på. Det høres trivielt ut til du legger merke til at ett enkelt exit-adresseresultat brukes til å sertifisere en enhet som kjører et dusin tjenester, to adressefamilier og en proxy. Gjennomgangen nedenfor bygger ett avgrenset bevis om gangen, i samme kontekst som arbeidsbelastningen faktisk kjører i.
Bestem hva testen skal bevise
Før du kjører noe, skriv forventningen på én linje: hvilken strøm, gjennom hvilket grensesnitt, til hvilken destinasjon, og hva som bør sees i den andre enden. En test uten en uttalt forventning gir et tall ingen kan tolke.
Den mest nyttige varianten navngir et godkjent endepunkt som rapporterer kildeadressen det så.
Det endepunktet er den eneste delen du må ordne. Alt annet er en observasjon på klientsiden, og observasjoner på klientsiden går galt på interessante måter.
Kjør observasjonen i riktig kontekst
En administrators shell er ikke arbeidsbelastningens miljø. Den kan bære en annen proxyvariabel, en annen rutingtabell i et annet navnerom eller en annen brukers miljøfil. Kjør testen i samme verts-, container-, navneroms- eller tjenestekontekst som det du kontrollerer. Ellers måler du din egen shell.
På en vanlig vert betyr det samme bruker og samme enhet. I et containerlandskap betyr det å gå inn i containerens nettverksnavnerom i stedet for å teste fra verten. På en systemd-tjeneste kan det bety en midlertidig enhet med de samme innstillingene.
Forespørselen som følger er bare meningsfull når du er i riktig kontekst.
Kontroller adressefamilier hver for seg
Spør eksplisitt om hver familie, fordi en vellykket IPv4-forespørsel ikke trener en IPv6-sti i det hele tatt. Velgerne --ipv4 og --ipv6 tvinger valget, og forskjellen mellom de to resultatene er i seg selv informasjon.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceEn mislykket IPv6-forespørsel er ikke bevis på en effektiv blokkering. Det kan bety at endepunktet ikke har en IPv6-adresse, at DNS ikke returnerte noe brukbart, eller at enheten ikke har noen IPv6-rute i det hele tatt. Les feilen før du trekker en konklusjon. En vellykket IPv6-forespørsel gjennom tunnelen er det eneste resultatet som beviser at IPv6-stien er dekket.
Noter begge svarene side om side. Ett av dem alene er halvparten av et faktum.
Legg til de fire tingene en exit-kontroll overser
En exit-adresse svarer på ett spørsmål. Fire til avgjør om tunnelen oppfører seg 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 |
Destinasjonspolicy kommer først: test en strøm som bør inkluderes og en som bør utelates, når designet har en deling. Deretter DNS, hvor du undersøker den faktiske resolver-stien i stedet for den konfigurerte verdien, fordi et bufret svar eller en utskrevet innstilling ikke sier noe om hvor en ny spørring gikk.
Feilatferd trenger en plan og en bevart gjenopprettingssti. Observer en ny forespørsel mens tunnelen er utilgjengelig, og husk at en gammel åpen forbindelse ikke er bevis om feilpolicyen. Livssyklusen kommer sist: gjenta observasjonen etter en gjenoppkobling eller en tjenestestart hvis disse hendelsene påvirker kravet.
Noter bevis, ikke en dom
For hvert resultat beholder du prosesskonteksten, destinasjonen, adressefamilien, tiden og den observerte kilden. Det settet er avgrenset bevis om strømmene du har øvd på, og det er forsvarlig nettopp fordi det sier hva det dekket.
Det er ikke en revisjon av VPN-operatørens registreringer, og ikke et sertifikat for hver fremtidige applikasjon på enheten.
Skriv grensene ved siden av resultatet. En test som angir hva den ikke dekket, overlever gjennomgang, mens en som hevder at enheten er verifisert, ikke gjør det. Hold curl-håndboken ved siden av familievelgerne du brukte, og hold tabellen med fire rader sammen med resultatene.