Opdelt tunnel: hvorfor et link åbner uden for den VPN, du har sat op

At tunnelere en app flytter ikke dens routing med til alt, hvad appen starter, selv om grænsefladen antyder det modsatte. Et link giver en anmodning videre til et andet program, det program åbner sin egen socket, og platformen anvender reglerne på den nye proces i stedet for på den, der viste teksten. Det er den anden proces, tunnelpolitikken faktisk ser, og det er ikke den, du konfigurerede.

En inkluderet app kan derfor åbne en browser, der ligger uden for tunnelen. En ekskluderet browser kan give arbejde tilbage til en app, der ligger inde i den. Begge retninger af den overraskelse er almindelig adfærd.

Den del af arbejdsgangen, som ingen konfigurerede

Politik per app skrives mod en eksekverbar fils eller et pakkes identitet, og hver forbindelse vurderes i det øjeblik, den oprettes. Browseren, dokumentfremviseren, medieafspilleren og systemets delingsark bærer hver deres identitet, og hver får sin egen dom. Et dybt link bærer data, ikke politik.

Derfor virker observationen vilkårlig: det samme klik rutes to veje afhængigt af, hvilken behandler der svarer. En mailklient i tunnelen åbner et link i en browser, der ligger uden for tunnelen, og siden indlæses fra din hjemadresse. En browser uden for tunnelen åbner et dokument i en fremviser, der ligger inde i den, og filen ankommer gennem udgangen. Ingen af de to resultater er en fejl i klienten.

En behandler, der allerede kører, gør det værre. Hvis browseren allerede er åben, bliver linket en besked til en eksisterende proces, og den proces beholder den routing, den havde, da den startede. At lukke og genåbne behandleren ændrer resultatet, og derfor gentages problemet aldrig på kommando.

Hvilken proces lavede faktisk forbindelsen

Mål den modtagende side i stedet for at ræsonnere om den. Hold tunnelen oppe, klik på et uskyldigt link, og se på de sockets, det nye program holder.

ss -tnp state established '( dport = :443 )'
Get-NetTCPConnection -State Established | Select-Object RemoteAddress,OwningProcess

Den første kommando navngiver processen bag hver etableret socket på Linux, og den anden gør det samme på Windows ved at opløse identifikatoren for den ejende proces. Sammenlign procesnavnet med dem i din politik. Er navnet browseren, og er browseren ekskluderet, forlod klikket tunnelen med vilje og ikke på grund af en fejl. At parre en politikregel med en levende socket er hele metoden.

Gentag kontrollen med behandleren allerede kørende og derefter med den lukket. De to resultater kan variere, og den forskel forklarer de fleste periodiske rapporter om links, der slipper ud af en tunnel.

Dækning er en egenskab ved arbejdsgangen

Hvis en opgave skal blive inde i tunnelen fra start til slut, skal hver komponent, den kan nå, være inde i politikken: starteren, behandleren, fremviseren og enhver mægler, som platformen indsætter mellem dem. Bredere dækning er ofte det ærlige svar, og det er billigere end at revidere hvert delingsmål.

At ekskludere en systemmægler for at rette en enkelt app er en almindelig fejl. Mæglere deles, så undtagelsen følger hver anden app, der bruger samme vej, normalt uden at nogen opdager det, før en rapport dukker op uger senere. Læs, hvad der ellers afhænger af komponenten, før du ekskluderer den.

Hold identitet adskilt fra routing. Et link kan bære en sessionstoken eller en kontoidentifikator, uanset hvilken udgang der modtager anmodningen. Et korrekt rutet klik kan stadig fortælle destinationen præcis, hvem der fulgte det.

Dokumentér arbejdsgangen, ikke det første afkrydsningsfelt. Når en opgave spænder over fire programmer, er diagrammet med fire programmer det, der forudsiger, hvor trafikken går, og indstillingen for en enkelt app er kun én række i det.