Gesplitste tunnel: waarom een link buiten de VPN opent die je hebt ingesteld

Een app door een tunnel leiden draagt de routering niet mee naar alles wat die app start, ook al suggereert de interface het tegendeel. Een link geeft een verzoek door aan een ander programma, dat programma opent zijn eigen socket, en het platform past de regels toe op het nieuwe proces in plaats van op het proces dat de tekst toonde. Dat tweede proces is wat het tunnelbeleid werkelijk ziet, en het is niet het proces dat je hebt ingesteld.

Een ingesloten app kan dus een browser openen die buiten de tunnel staat. Een uitgesloten browser kan werk teruggeven aan een app die erbinnen staat. Beide richtingen van die verrassing zijn normaal gedrag.

Het deel van de werkstroom dat niemand heeft ingesteld

Beleid per app wordt geschreven tegen de identiteit van een uitvoerbaar bestand of pakket, en elke verbinding wordt beoordeeld op het moment dat hij ontstaat. De browser, de documentviewer, de mediaspeler en het deelblad van het systeem dragen elk hun eigen identiteit, en elk krijgt zijn eigen oordeel. Een diepe link draagt gegevens, geen beleid.

Daarom voelt de waarneming willekeurig: dezelfde klik wordt op twee manieren gerouteerd, afhankelijk van welke handler antwoordt. Een mailclient in de tunnel opent een link in een browser die buiten de tunnel leeft, en de pagina laadt vanaf je thuisadres. Een browser buiten de tunnel opent een document in een viewer die erbinnen leeft, en het bestand komt via de uitgang binnen. Geen van beide resultaten is een fout in de client.

Een handler die al draait maakt het erger. Als de browser al open is, wordt de link een bericht aan een bestaand proces, en dat proces houdt de routering die het bij de start had. De handler sluiten en opnieuw openen verandert de uitkomst, en daarom is het probleem nooit op verzoek te reproduceren.

Welk proces de verbinding werkelijk maakte

Meet de ontvangende kant in plaats van erover te redeneren. Houd de tunnel actief, klik op een onschadelijke link en kijk naar de sockets die het nieuwe programma vasthoudt.

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

Het eerste commando noemt het proces achter elke tot stand gebrachte socket op Linux, en het tweede doet hetzelfde op Windows door de identificatie van het eigendomsproces op te lossen. Vergelijk de procesnaam met de namen in je beleid. Is de naam de browser en is de browser uitgesloten, dan verliet de klik de tunnel door ontwerp en niet door een fout. Een beleidsregel aan een levende socket koppelen is de hele methode.

Herhaal de controle met de handler al draaiend en daarna gesloten. De twee resultaten kunnen verschillen, en dat verschil verklaart de meeste sporadische meldingen over links die aan een tunnel ontsnappen.

Dekking is een eigenschap van de werkstroom

Als een taak van begin tot eind in de tunnel moet blijven, moet elk onderdeel dat hij kan bereiken binnen het beleid vallen: de launcher, de handler, de viewer en elke bemiddelaar die het platform ertussen zet. Bredere dekking is vaak het eerlijke antwoord, en het is goedkoper dan elk deeldoel te controleren.

Een systeembemiddelaar uitsluiten om één applicatie te repareren is een veelgemaakte fout. Bemiddelaars worden gedeeld, dus de uitsluiting volgt elke andere app die hetzelfde pad gebruikt, meestal zonder dat iemand het merkt tot er weken later een melding komt. Lees wat er nog meer van het onderdeel afhangt voordat je het uitsluit.

Houd identiteit ook gescheiden van routering. Een link kan een sessietoken of een accountidentificatie dragen, ongeacht welke uitgang het verzoek ontvangt. Een correct gerouteerde klik kan de bestemming nog steeds precies vertellen wie hem volgde.

Documenteer de werkstroom, niet het eerste selectievakje. Wanneer een taak vier programma's omvat, is het diagram met vier programma's het diagram dat voorspelt waar het verkeer naartoe gaat, en de instelling voor één app is daarvan slechts één rij.