Een headless VPN controleren: één flow per keer, met bewijs
Een headless doos heeft een verzoek nodig waarvan u het antwoord kunt lezen. Test elke adresfamilie, context en bestemming en noteer daarna wat het resultaat niet dekte.
Op een headless doos is er geen browser om te openen en geen slot om naar te kijken, dus de controle moet een verzoek zijn waarvan u het antwoord kunt lezen. Dat klinkt triviaal tot u opmerkt dat één enkel exit-adresresultaat wordt gebruikt om een apparaat te certificeren dat een dozijn diensten, twee adresfamilies en een proxy draait. De uiteenzetting hieronder bouwt telkens één begrensd bewijsstuk op, in dezelfde context waarin de werklast werkelijk draait.
Bepaal wat de test moet bewijzen
Voordat u iets uitvoert, schrijft u de verwachting op één regel: welke flow, via welke interface, naar welke bestemming, en wat er aan de andere kant te zien moet zijn. Een test zonder uitgesproken verwachting levert een getal op dat niemand kan interpreteren.
De nuttigste versie noemt een goedgekeurd eindpunt dat het bronadres rapporteert dat het zag.
Dat eindpunt is het enige onderdeel dat u moet regelen. Al het andere is een waarneming aan de clientzijde, en waarnemingen aan de clientzijde gaan op interessante manieren mis.
Voer de waarneming in de juiste context uit
De shell van een beheerder is niet de omgeving van de werklast. Er kan een andere proxyvariabele, een andere routetabel in een andere naamruimte of het omgevingsbestand van een andere gebruiker in zitten. Voer de test uit in dezelfde host-, container-, naamruimte- of servicecontext als wat u controleert. Anders meet u uw eigen shell.
Op een normale host betekent dat dezelfde gebruiker en dezelfde unit. In een containeromgeving betekent dat de netwerknaamruimte van de container binnengaan in plaats van vanaf de host te testen. Op een systemd-service kan het een tijdelijke unit met dezelfde instellingen betekenen.
Het verzoek dat volgt is alleen zinvol als u in de juiste context bent.
Controleer adresfamilies afzonderlijk
Vraag elke familie expliciet, want een geslaagd IPv4-verzoek oefent helemaal geen IPv6-pad. De selectors --ipv4 en --ipv6 dwingen de keuze af, en het verschil tussen de twee resultaten is zelf informatie.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceEen mislukt IPv6-verzoek is geen bewijs van een doeltreffende blokkade. Het kan betekenen dat het eindpunt geen IPv6-adres heeft, dat DNS niets bruikbaars teruggaf, of dat het apparaat helemaal geen IPv6-route heeft. Lees de fout voordat u een conclusie trekt. Een geslaagd IPv6-verzoek via de tunnel is het enige resultaat dat bewijst dat het IPv6-pad gedekt is.
Noteer beide antwoorden naast elkaar. Eén ervan alleen is de helft van een feit.
Voeg de vier dingen toe die een exit-controle mist
Een exit-adres beantwoordt één vraag. Vier andere bepalen of de tunnel zich gedraagt zoals ontworpen.
| 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 |
Het bestemmingsbeleid komt eerst: test een flow die zou moeten worden inbegrepen en een die zou moeten worden uitgesloten, wanneer het ontwerp een splitsing heeft. Dan DNS, waar u het werkelijke resolverpad onderzoekt in plaats van de geconfigureerde waarde, omdat een gecacht antwoord of een afgedrukte instelling niets zegt over waar een nieuwe query heen ging.
Foutgedrag vereist een plan en een behouden herstelpad. Observeer een nieuw verzoek terwijl de tunnel niet beschikbaar is, en onthoud dat een oude open verbinding geen bewijs is over het foutbeleid. De levenscyclus komt als laatste: herhaal de waarneming na een herverbinding of een serviceherstart als die gebeurtenissen de eis raken.
Noteer bewijs, geen oordeel
Bewaar voor elk resultaat de procescontext, de bestemming, de adresfamilie, de tijd en de waargenomen bron. Die verzameling is begrensd bewijs over de flows die u hebt geoefend, en ze is verdedigbaar juist omdat ze zegt wat ze dekte.
Het is geen audit van de administratie van de VPN-operator, en geen certificaat voor elke toekomstige toepassing op het apparaat.
Schrijf de grenzen naast het resultaat. Een test die zegt wat hij niet dekte, doorstaat de beoordeling, terwijl een die beweert dat het apparaat geverifieerd is dat niet doet. Houd de curl-handleiding naast de gebruikte familiesselectors, en houd de tabel met vier rijen bij de resultaten.