Gesplete tonnel: hoekom ’n skakel buite die VPN oopmaak wat jy opgestel het

Om ’n toep deur ’n tonnel te stuur, dra nie sy roetering saam met enigiets wat daardie toep begin nie, selfs al suggereer die koppelvlak die teendeel. ’n Skakel gee ’n versoek aan ’n ander program oor, daardie program maak sy eie sokket oop, en die platform pas die reëls op die nuwe proses toe eerder as op die een wat die teks gewys het. Daardie tweede proses is wat die tonnelbeleid werklik sien, en dit is nie die een wat jy opgestel het nie.

’n Ingeslote toep kan dus ’n blaaier oopmaak wat buite die tonnel sit. ’n Uitgeslote blaaier kan werk teruggee aan ’n toep wat binne-in dit sit. Albei rigtings van daardie verrassing is gewone gedrag.

Die deel van die werkvloei wat niemand opgestel het nie

Beleid per toep word teen ’n uitvoerbare lêer of pakketidentiteit geskryf, en elke verbinding word beoordeel op die oomblik dat dit geskep word. Die blaaier, die dokumentkyker, die mediaklankspeler en die stelsel se deelblad dra elkeen sy eie identiteit, en elkeen kry sy eie uitspraak. ’n Diep skakel dra data, nie beleid nie.

Dis hoekom die waarneming willekeurig voel: dieselfde klik roeteer twee kante toe, afhangend van watter hanteerder dit antwoord. ’n Getonnelde e-poskliënt maak ’n skakel oop in ’n blaaier wat buite die tonnel leef, en die bladsy laai vanaf jou tuisadres. ’n Blaaier buite die tonnel maak ’n dokument oop in ’n kyker wat binne-in dit leef, en die lêer kom deur die uitgang. Nie een van die twee resultate is ’n fout in die kliënt nie.

’n Hanteerder wat al klaar loop, maak dit erger. As die blaaier reeds oop is, word die skakel ’n boodskap aan ’n bestaande proses, en daardie proses hou die roetering wat hy gehad het toe hy begin het. Om die hanteerder toe te maak en weer oop te maak verander die uitkoms, en dis hoekom die probleem nooit op aanvraag herhaal nie.

Watter proses het werklik die verbinding gemaak

Meet die ontvangende kant eerder as om daaroor te redeneer. Hou die tonnel op, klik op ’n onskadelike skakel, en kyk na die sokkette wat die nuwe program hou.

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

Die eerste opdrag noem die proses agter elke gevestigde sokket op Linux, en die tweede doen dieselfde op Windows deur die eienaarprosesidentifiseerder op te los. Vergelyk die prosesnaam met die name in jou beleid. As die naam die blaaier is en die blaaier is uitgesluit, het die klik die tonnel met opset verlaat eerder as deur ’n fout. Om ’n beleidsreël aan ’n lewende sokket te pas, is die hele metode.

Herhaal die kontrole met die hanteerder wat reeds loop, en dan met dit toegemaak. Die twee resultate kan verskil, en daardie verskil verduidelik die meeste sporadiese verslae oor skakels wat uit ’n tonnel ontsnap.

Dekking is ’n eienskap van die werkvloei

As ’n taak van begin tot einde binne die tonnel moet bly, moet elke komponent wat dit kan bereik binne die beleid wees: die lanseerder, die hanteerder, die kyker, en enige tussenganger wat die platform tussen hulle invoeg. Wyper dekking is dikwels die eerlike antwoord, en dit is goedkoper as om elke deelteiken na te gaan.

Om ’n stelseltussenganger uit te sluit om een toepassing reg te maak, is ’n algemene fout. Tussengangers word gedeel, so die uitsluiting volg elke ander toep wat dieselfde pad gebruik, gewoonlik sonder dat iemand dit raaksien tot ’n verslag weke later opdaag. Lees wat anders van die komponent afhang voordat jy dit uitsluit.

Hou identiteit ook apart van roetering. ’n Skakel kan ’n sessietoken of ’n rekeningidentifiseerder dra, ongeag watter uitgang die versoek ontvang. ’n Korrek geroteerde klik kan steeds vir die bestemming presies sê wie dit gevolg het.

Dokumenteer die werkvloei, nie die eerste blokkie nie. Wanneer ’n taak oor vier programme strek, is die diagram met vier programme daarop die een wat voorspel waar die verkeer heen gaan, en die instelling vir een toep is net een ry daarvan.