Delt tunnel: hvorfor en lenke åpnes utenfor VPN-en du satte opp

Å tunnelere en app flytter ikke rutingen dens til alt appen starter, selv om grensesnittet antyder det motsatte. En lenke gir en forespørsel videre til et annet program, det programmet åpner sin egen socket, og plattformen bruker reglene på den nye prosessen i stedet for på den som viste teksten. Det er den andre prosessen tunnelpolitikken faktisk ser, og den er ikke den du konfigurerte.

En inkludert app kan derfor åpne en nettleser som ligger utenfor tunnelen. En ekskludert nettleser kan gi arbeid tilbake til en app som ligger inni den. Begge retningene av den overraskelsen er vanlig oppførsel.

Den delen av arbeidsflyten som ingen konfigurerte

Politikk per app skrives mot identiteten til en kjørbar fil eller en pakke, og hver tilkobling vurderes i det øyeblikket den opprettes. Nettleseren, dokumentviseren, mediespilleren og systemets delingsark bærer hver sin identitet, og hver får sin egen dom. En dyp lenke bærer data, ikke politikk.

Derfor virker observasjonen vilkårlig: det samme klikket rutes to veier avhengig av hvilken behandler som svarer. En e-postklient i tunnelen åpner en lenke i en nettleser som lever utenfor tunnelen, og siden lastes fra hjemmeadressen din. En nettleser utenfor tunnelen åpner et dokument i en viser som lever inni den, og filen kommer gjennom utgangen. Ingen av de to resultatene er en feil i klienten.

En behandler som allerede kjører gjør det verre. Hvis nettleseren allerede er åpen, blir lenken en melding til en eksisterende prosess, og den prosessen beholder rutingen den hadde da den startet. Å lukke og gjenåpne behandleren endrer resultatet, og derfor gjentas aldri problemet på kommando.

Hvilken prosess som faktisk opprettet tilkoblingen

Mål den mottakende siden i stedet for å resonnere om den. Hold tunnelen oppe, klikk på en uskyldig lenke og se på socketene det nye programmet holder.

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

Den første kommandoen navngir prosessen bak hver etablert socket på Linux, og den andre gjør det samme på Windows ved å slå opp identifikatoren til prosessen som eier den. Sammenlign prosessnavnet med navnene i politikken din. Hvis navnet er nettleseren og nettleseren er ekskludert, forlot klikket tunnelen med vilje og ikke på grunn av en feil. Å pare en politikregel med en levende socket er hele metoden.

Gjenta kontrollen med behandleren allerede kjørende, og deretter med den lukket. De to resultatene kan variere, og den forskjellen forklarer de fleste periodiske rapportene om lenker som slipper ut av en tunnel.

Dekning er en egenskap ved arbeidsflyten

Hvis en oppgave skal bli inne i tunnelen fra start til slutt, må hver komponent den kan nå være inne i politikken: starteren, behandleren, viseren og enhver megler plattformen setter inn mellom dem. Bredere dekning er ofte det ærlige svaret, og det er billigere enn å revidere hvert delingsmål.

Å ekskludere en systemmegler for å rette én app er en vanlig feil. Meklere deles, så unntaket følger hver annen app som bruker samme vei, vanligvis uten at noen merker det før en rapport kommer uker senere. Les hva annet som avhenger av komponenten før du ekskluderer den.

Hold identitet atskilt fra ruting. En lenke kan bære et sesjonstoken eller en kontoidentifikator, uansett hvilken utgang som mottar forespørselen. Et riktig rutet klikk kan fortsatt fortelle målet nøyaktig hvem som fulgte det.

Dokumenter arbeidsflyten, ikke den første avkrysningsboksen. Når en oppgave spenner over fire programmer, er diagrammet med fire programmer det som forutsier hvor trafikken går, og innstillingen for én app er bare én rad i det.