Kontroll av ein headless VPN: éin straum om gongen, med prov
Ein headless boks treng ei førespurnad du kan lese svaret på. Test kvar adressefamilie, kontekst og destinasjon, og noter deretter kva resultatet ikkje dekte.
På ein headless boks finst det ingen nettlesar å opne og ingen hengelås å sjå på, så kontrollen må vere ei førespurnad du kan lese svaret på. Det høyrest trivielt ut til du legg merke til at eitt einskild exit-adresseresultat vert brukt til å sertifisere eininga som køyrer eit dusin tenester, to adressefamiliar og ein proxy. Gjennomgangen nedanfor byggjer eitt avgrensa prov om gongen, i same kontekst som arbeidslasta faktisk køyrer i.
Avgjer kva testen skal prove
Før du køyrer noko, skriv forventninga på éi linje: kva straum, gjennom kva grensesnitt, til kva destinasjon, og kva som bør sjåast i den andre enden. Ein test utan ei uttalt forventning gjev eit tal ingen kan tolke.
Den mest nyttige varianten nemner eit godkjent endepunkt som rapporterer kjeldeadressa det såg.
Det endepunktet er den einaste delen du må ordne. Alt anna er ei observasjon på klientsida, og observasjonar på klientsida går gale på interessante måtar.
Køyr observasjonen i rett kontekst
Ein administrators shell er ikkje miljøet til arbeidslasta. Han kan bere ein annan proxyvariabel, ein annan rutetabell i eit anna namnerom eller miljøfila til ein annan brukar. Køyr testen i same verts-, container-, namneroms- eller tenestekontekst som det du kontrollerer. Elles måler du din eigen shell.
På ein vanleg vert tyder det same brukar og same eining. I eit containerlandskap tyder det å gå inn i nettverksnamneromet til containeren i staden for å teste frå verten. På ei systemd-teneste kan det tyde ei mellombels eining med dei same innstillingane.
Førespurnaden som følgjer er berre meiningsfull når du er i rett kontekst.
Kontroller adressefamiliar kvar for seg
Spør eksplisitt om kvar familie, fordi ei vellukka IPv4-førespurnad ikkje trenar ein IPv6-sti i det heile. Veljarane --ipv4 og --ipv6 tvingar valet, og skilnaden mellom dei to resultata er i seg sjølv informasjon.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceEi mislukka IPv6-førespurnad er ikkje prov på ei effektiv blokkering. Det kan tyde at endepunktet ikkje har ei IPv6-adresse, at DNS ikkje returnerte noko brukbart, eller at eininga ikkje har nokon IPv6-rute i det heile. Les feilen før du dreg ei slutning. Ei vellukka IPv6-førespurnad gjennom tunnelen er det einaste resultatet som provar at IPv6-stien er dekt.
Noter begge svara side om side. Eitt av dei åleine er halvparten av eit faktum.
Legg til dei fire tinga ein exit-kontroll overser
Ei exit-adresse svarar på eitt spørsmål. Fire til avgjer om tunnelen oppfører seg som designa.
| 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 |
Destinasjonspolitikken kjem først: test ein straum som bør inkluderast og ein som bør utelatast, når designet har ei deling. Deretter DNS, der du undersøkjer den faktiske resolver-stien i staden for den konfigurerte verdien, fordi eit buft svar eller ei utskriven innstilling ikkje seier noko om kvar ei ny spørjing gjekk.
Feilåtferd treng ei plan og ein bevart attopprettingssti. Observer ei ny førespurnad medan tunnelen er utilgjengeleg, og hugs at ei gammal open tilkobling ikkje er prov om feilpolitikken. Livssyklusen kjem sist: gjer observasjonen om att etter ei attkobling eller ein tenestestart om desse hendingane påverkar kravet.
Noter prov, ikkje ein dom
For kvart resultat held du på prosesskonteksten, destinasjonen, adressefamilien, tida og den observerte kjelda. Det settet er avgrensa prov om straumane du har øvd på, og det er forsvarleg nettopp fordi det seier kva det dekte.
Det er ikkje ein revisjon av registra til VPN-operatøren, og ikkje eit sertifikat for kvar framtidig applikasjon på eininga.
Skriv grensene ved sida av resultatet. Ein test som seier kva han ikkje dekte, overlever gjennomgang, medan ein som hevdar at eininga er verifisert, ikkje gjer det. Hald curl-handboka ved sida av familieveljarane du brukte, og hald tabellen med fire radene saman med resultata.