Kontroll av en headless VPN: ett flöde i taget, med bevis
En headless burk behöver en förfrågan vars svar du kan läsa. Testa varje adressfamilj, kontext och destination och anteckna sedan vad resultatet inte täckte.
På en headless burk finns ingen webbläsare att öppna och inget hänglås att titta på, så kontrollen måste vara en förfrågan vars svar du kan läsa. Det låter trivialt tills du märker att ett enda exit-adressresultat används för att certifiera en enhet som kör ett dussin tjänster, två adressfamiljer och en proxy. Genomgången nedan bygger ett avgränsat bevis i taget, i samma kontext som arbetsbelastningen faktiskt körs i.
Bestäm vad testet ska bevisa
Innan du kör något, skriv förväntan på en rad: vilket flöde, genom vilket gränssnitt, till vilken destination och vad som bör synas i andra änden. Ett test utan uttalad förväntan ger ett tal som ingen kan tolka.
Den mest användbara versionen namnger en godkänd slutpunkt som rapporterar källadressen den såg.
Den slutpunkten är den enda delen du måste ordna. Allt annat är en observation på klientsidan, och observationer på klientsidan går fel på intressanta sätt.
Kör observationen i rätt kontext
En administratörs shell är inte arbetsbelastningens miljö. Den kan bära en annan proxyvariabel, en annan routingtabell i ett annat namnutrymme eller en annan användares miljöfil. Kör testet i samma värd-, container-, namnutrymmes- eller tjänstekontext som det du kontrollerar. Annars mäter du ditt eget shell.
På en vanlig värd betyder det samma användare och samma enhet. I ett containerlandskap betyder det att gå in i containerns nätverksnamnutrymme i stället för att testa från värden. På en systemd-tjänst kan det betyda en tillfällig enhet med samma inställningar.
Förfrågan som följer är bara meningsfull när du är i rätt kontext.
Kontrollera adressfamiljer var för sig
Fråga uttryckligen efter varje familj, eftersom en lyckad IPv4-förfrågan inte tränar en IPv6-väg alls. Väljarna --ipv4 och --ipv6 tvingar valet, och skillnaden mellan de två resultaten är i sig information.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceEn misslyckad IPv6-förfrågan är inte bevis på ett effektivt block. Det kan betyda att slutpunkten saknar IPv6-adress, att DNS inte returnerade något användbart eller att enheten inte har någon IPv6-rutt alls. Läs felet innan du drar en slutsats. En lyckad IPv6-förfrågan genom tunneln är det enda resultatet som bevisar att IPv6-vägen täcks.
Anteckna båda svaren sida vid sida. Ett av dem ensamt är halva ett faktum.
Lägg till de fyra saker en exit-kontroll missar
En exit-adress svarar på en fråga. Fyra till avgör om tunneln beter sig som designat.
| 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 |
Destinationsprincipen kommer först: testa ett flöde som bör ingå och ett som bör uteslutas, när designen har en delning. Sedan DNS, där du undersöker den faktiska resolvervägen i stället för det konfigurerade värdet, eftersom ett cachat svar eller en utskriven inställning inte säger något om vart en ny fråga tog vägen.
Felbeteende behöver en plan och en bevarad återställningsväg. Observera en ny förfrågan medan tunneln är otillgänglig, och kom ihåg att en gammal öppen anslutning inte är bevis om felprincipen. Livscykeln kommer sist: upprepa observationen efter en återanslutning eller en tjänstomstart om dessa händelser påverkar kravet.
Anteckna bevis, inte en dom
För varje resultat behåller du processkontexten, destinationen, adressfamiljen, tiden och den observerade källan. Den mängden är avgränsat bevis om de flöden du har tränat, och den är försvarbar just därför att den säger vad den täckte.
Det är inte en revision av VPN-operatörens register och inte ett certifikat för varje framtida applikation på enheten.
Skriv gränserna bredvid resultatet. Ett test som anger vad det inte täckte klarar granskning, medan ett som hävdar att enheten är verifierad inte gör det. Håll curl-handboken bredvid de familjeväljare du använde och håll tabellen med fyra rader tillsammans med resultaten.