Kontrollér, at en split tunnel virker: ét IP-resultat er ikke en test

En enkelt browserside, der viser en IP-adresse, beviser næsten intet om en split tunnel. En synlig adresse kan være den rigtige af den forkerte grund, og et udelukket flow bliver aldrig prøvet af den. Skriv det forventede resultat ned, før du tester: hvilken applikation eller destination der skal bruge tunnelen, hvilken der skal forblive direkte, og hvad der skal stoppe, når tunnelen fejler. Uden den plan ser ethvert plausibelt tal ud som succes.

Myten: et adresseopslag beviser dækning

IP-tjekket besvarer ét spørgsmål: hvad omverdenen ser fra én applikation på ét tidspunkt. Det siger intet om et internt præfiks, en anden browserprofil eller et navn, der skal opløses privat. Det siger heller intet om fejl, og det er den halvdel af et split-tunnel-design, der brækker i produktion.

En adresseside kan heller ikke vise ruten, resolveren eller fejlpolitikken. Behandl den som én observation, ikke som en dom.

Prøv et inkluderet flow og et udelukket et

Send en harmløs anmodning fra den applikation, der skal inkluderes, eller til det præfiks, du forventer at route gennem tunnelen, og log kilden, destinationen, adressefamilien og den observerede vej. Gør det samme for et flow, der skal forblive direkte. Den udelukkede side er den, folk springer over, og det er det eneste bevis for, at opdelingen er bevidst og ikke tilfældig. En hjælpeproces kan bære en separat politikidentitet, så test i den proces, der ejer socket'en.

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

Derfor kan en test i den forkerte applikation vise det modsatte af, hvad designet tilsigter. Skriv de fire felter ned for begge sider, før du drager nogen konklusion.

Tilføj DNS og fejltilfældet

Forespørg systemets resolver og den resolver, appen bruger, og sammenlign derefter de svar med den udgangsadresse, som webstedet rapporterer. De to lag kan være uenige med vilje, og et enkelt browseropslag prøver ikke operativsystemets politik af. En shell gør sammenligningen gentagelig: Bryd tunnelen med vilje, og lav derefter en anmodning, som browseren ikke har cachelagret; en side, der serveres fra cachen, fortæller dig intet om, hvilken vej fallbacken gik. Registrér, hvad der faktisk skete, i stedet for hvad designet forudsagde.

curl -s https://ifconfig.me
nslookup intranet.example

En split tunnel, der fejler lukket, og en, der fejler åben, ser identiske ud, indtil du bryder tunnelen med vilje. Registrér, hvilken adfærd du observerede, ikke hvilken du forventede.

Gentag, efter at tilstanden har ændret sig

Gentag de samme observationer efter en genopkobling, et netværksskift og en relevant applikationsopdatering. En gemt udelukkelse kan blive ved med at pege på en vej eller en applikationsidentitet, der ikke længere findes, og designet holder stille op med at matche sin dokumentation. De tre hændelser er der, hvor split tunnels driver, og hver af dem er billig at teste igen. En test, der kun kører én gang ved udrulningen, beskriver en konfiguration, der ikke længere findes.

Hvis et resultat afviger, så find regelejeren og behandlingstrinnet, før du ændrer flere indstillinger på én gang. At ændre fem ting og observere ét resultat er ikke en diagnose, det er en ny konfiguration.

Hvad resultatet skal fastslå

Knyt observationerne til den politik og klientversion, du faktisk testede. Målet er at vise, at denne udrulning matcher den dækning, den hævder, ikke at enhver fremtidig applikation vil være privat. Det er en snævrere påstand, og det er den, du faktisk kan understøtte med beviser. Skriv påstanden, versionen og firefeltresultaterne i ændringsregistreringen.

Så kan den næste anmelder se, om designet ændrede sig, eller testen gjorde. En split tunnel er verificeret, når begge sider, resolver-opdelingen og fejladfærden matcher det, du skrev ned i starten. Ét IP-resultat verificerer ingen af dem.