Controleer of een split-tunnel werkt: één IP-uitkomst is geen test
Schrijf op welke stromen de tunnel moeten gebruiken en welke direct moeten blijven, en test dan beide kanten, de DNS-splitsing en het uitvalgeval.
Eén browserpagina die een IP-adres toont, bewijst bijna niets over een split-tunnel. Een zichtbaar adres kan het juiste zijn om de verkeerde reden, en een uitgesloten stroom wordt er nooit mee getest. Schrijf de verwachte uitkomst op voordat je test: welke toepassing of bestemming de tunnel moet gebruiken, welke direct moet blijven, en wat moet stoppen als de tunnel uitvalt. Zonder dat plan lijkt elk aannemelijk getal op succes.
De mythe: een adresopvraag bewijst dekking
De IP-controle beantwoordt één vraag: wat de buitenwereld op één moment van één toepassing ziet. Ze zegt niets over een intern prefix, een tweede browserprofiel of een naam die privé moet worden opgelost. Ze zegt ook niets over uitval, en dat is de helft van een split-tunnelontwerp die in productie stukgaat.
Een adrespagina kan ook de route, de resolver of het uitvalbeleid niet laten zien. Behandel haar als één waarneming, niet als een oordeel.
Test een inbegrepen stroom en een uitgesloten stroom
Stuur een onschadelijk verzoek vanuit de toepassing die inbegrepen moet zijn, of naar het prefix dat je door de tunnel verwacht te routeren, en leg de bron, bestemming, adresfamilie en waargenomen pad vast. Doe hetzelfde voor een stroom die direct moet blijven. De uitgesloten kant is de kant die mensen overslaan, en het is het enige bewijs dat de splitsing opzettelijk is en niet toevallig. Een hulpproces kan een aparte beleidsidentiteit dragen, dus test in het proces dat de socket bezit.
flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct
Daarom kan een test in de verkeerde toepassing het tegenovergestelde laten zien van wat het ontwerp bedoelt. Schrijf de vier velden voor beide kanten op voordat je een conclusie trekt.
Voeg DNS en het uitvalgeval toe
Bevraag de systeemresolver en de resolver die de app gebruikt, en vergelijk die antwoorden dan met het uitgangsadres dat de site rapporteert. De twee lagen kunnen opzettelijk van elkaar afwijken, en één browseropvraag test het beleid van het besturingssysteem niet. Een shell maakt de vergelijking herhaalbaar: Breek de tunnel expres, doe dan een verzoek dat de browser niet heeft gecachet; een pagina uit de cache vertelt je niets over welke kant de terugval op ging. Leg vast wat er werkelijk gebeurde in plaats van wat het ontwerp voorspelde.
curl -s https://ifconfig.me
nslookup intranet.example
Een split-tunnel die gesloten faalt en een die open faalt, zien er identiek uit tot je de tunnel expres breekt. Leg vast welk gedrag je hebt waargenomen, niet welk je verwachtte.
Herhaal na de statuswijziging
Herhaal dezelfde waarnemingen na een herverbinding, een netwerkwissel en een relevante applicatie-update. Een opgeslagen uitsluiting kan blijven wijzen naar een pad of een applicatie-identiteit die niet meer bestaat, en het ontwerp stopt stilletjes met het matchen van zijn documentatie. Die drie gebeurtenissen zijn waar split-tunnels afdrijven, en elk ervan is goedkoop opnieuw te testen. Een test die maar één keer bij de uitrol loopt, beschrijft een configuratie die niet meer bestaat.
Als een uitkomst afwijkt, zoek dan de eigenaar van de regel en de verwerkingsfase voordat je meerdere instellingen tegelijk wijzigt. Vijf dingen veranderen en één resultaat waarnemen is geen diagnose, het is een nieuwe configuratie.
Wat de uitkomst moet vaststellen
Koppel de waarnemingen aan het beleid en de clientversie die je werkelijk hebt getest. Het doel is aan te tonen dat deze uitrol past bij de dekking die hij claimt, niet dat elke toekomstige toepassing privé zal zijn. Dat is een smallere bewering, en het is de bewering die je echt met bewijs kunt onderbouwen. Schrijf de bewering, de versie en de vierveldresultaten in het wijzigingsrecord.
Dan kan de volgende beoordelaar zien of het ontwerp is veranderd of de test. Een split-tunnel is geverifieerd wanneer beide kanten, de resolversplitsing en het uitvalgedrag passen bij wat je aan het begin hebt opgeschreven. Eén IP-uitkomst verifieert geen van die drie.