Fuld tunnel kontra opdelt tunnel: de fire ting, der adskiller sig
Etiketten afgør, hvor resten af en bærbars trafik går ud, ikke hvor hurtigt det går. Sammenlign udgang, belastning, DNS og fejlopførsel, før du vælger.
Tunneletiketter beskriver, hvor resten af en bærbars trafik går hen, ikke hvor hurtigt den går. Med en fuld tunnel passerer offentlige anmodninger VPN-gatewayen, før de forlader til internettet. Med opdelt tunnel bruger private destinationer tunnelen, og alt andet tager den lokale vej. Begge når den interne applikation, så den tilgængelighedstest, folk først kører, siger intet om, hvilken politik der er udrullet.
Test i stedet udgangen: hvilken adresse en offentlig ekkoside rapporterer, og hvilken resolver der svarede.
Myte: opdelt tunnel er bare den hurtigere mulighed
Opdelt tunnel bliver ofte solgt som en ydelsesfunktion, og det kan den være, men det er en bivirkning snarere end definitionen. Definitionen er en routingbeslutning om, hvilke destinationer der går ind i tunnelen. Hastighedsforskellen vises kun, når den direkte vej virkelig er bedre end omvejen gennem kontoret. På et overbelastet hjemmenet og en let belastet gateway kan den fulde tunnel være den hurtigste af de to.
Så den ærlige ramme handler om vejens ejerskab og kontrol, mens ydelse er noget, man måler bagefter. En politik valgt for hastighed, som stille flytter din DNS og offentlige udgang, er valgt af den forkerte grund.
Hvad der faktisk ændrer sig: udgangen
Under en fuld tunnel ser et offentligt websted kontorets udgangsadresse, og kontorets filtrering ser anmodningen. Under en opdelt tunnel ser det samme websted brugerens hjemadresse, og kontoret ser intet. Det er forskellige synlighedsmodeller, og ingen af dem er automatisk sikrere. Det nyttige spørgsmål er, hvilken organisationen faktisk kan drive.
Kontroller det direkte i stedet for at stole på et Tilsluttet-mærke. Et offentligt adresseekko viser udgangen, og en resolvertest viser, hvis DNS der svarede.
| Question | Full tunnel | Split tunnel |
|---|---|---|
| Public exit address | Office egress | Local connection |
| Gateway load | All covered traffic | Private destinations only |
| Office visibility | Requests and destinations | Private resource access only |
Hvad gatewayen så skal bære
En gateway, der bærer videoopkald, downloads og private applikationer, har brug for kapacitet til en helt anden arbejdsbyrde end en, der kun bærer interne anmodninger. Webstedets internetforbindelse bærer både brugerens ankomst og den efterfølgende offentlige udgang, så to links kan mættes på én gang.
Lokal udgang fjerner den belastning og omvejen, og den garanterer ikke en bedre oplevelse, fordi den direkte vej også kan være overbelastet. Sammenlign den faktiske applikation i stedet for at behandle en routingetiket som en ydelsesmåling.
Der findes undtagelser under en fuld tunnel
En standardrute er ikke en fortegnelse over hver pakke. Mere specifikke ruter, tilladelser til lokale netværk, applikationsundtagelser og separate IPv6-regler flytter alle trafik, og derfor kan en politik, der beskrives som fuld tunnel, stadig lække. Operativsystemets routingdokumentation drager den skelnen for tvungne tunnelstandarder, og klientens undtagelsesliste er der, hvor lækken normalt bor. Verificer adfærd, ikke hensigt.
IPv6 fortjener sit eget blik, fordi en tunnel, der kun bærer IPv4, efterlader en hel stak uden for politikken.
DNS er en særskilt politik
Interne navne har brug for en resolver, der kender dem, og den resolver kan kun være nåbar gennem tunnelen. En browser med sin egen krypterede DNS kan helt omgå systemets resolver, hvilket skaber en opdeling, hvor interne navne fejler, og offentlige virker, eller omvendt.
Beslut, hvor opslag skal gå hen, og få så klienten og browseren til at være enige. Vellykket offentlig browsing tester aldrig intern navneopløsning, så det er det forkerte bevis at henvise til, når et intranetsted forsvinder.
Skriv fejlpolitikken, og test den så
Beslut, hvad der sker, når tunnelen falder: bloker alt, bloker kun private ressourcer, eller tillad direkte forbindelser. Automatisk genopkobling besvarer ikke det spørgsmål, og en kill switch, der kun dækker tunnelgrænsefladen, kan lade undtagne applikationer tale frit. Test en rigtig afbrydelse og en netværksændring, og læs så klientens tilstand, fordi dokumentationen beskriver den tilsigtede adfærd snarere end den installerede.
Skriv de private ruter, udgangen, DNS-serverne, de lokale undtagelser og fejlopførslen ned i et kort notat. Det notat er det, der gør politikken verificerbar for en, der ikke har skrevet den.