Full tunnel kontra delt tunnel: de fire forskjellene
Etiketten avgjør hvor resten av en bærbars trafikk går ut, ikke hvor rask den er. Sammenlign utgang, belastning, DNS og feilatferd før du velger.
Tunneletiketter beskriver hvor resten av en bærbars trafikk går, ikke hvor raskt den går. Med full tunnel passerer offentlige forespørsler VPN-gatewayen før de forlater til internett. Med delt tunnel bruker private destinasjoner tunnelen, og alt annet tar den lokale veien. Begge når den interne applikasjonen, så tilgjengelighetstesten folk kjører først, sier ingenting om hvilken policy som er rullet ut.
Test utgangen i stedet: hvilken adresse en offentlig ekkoside rapporterer, og hvilken resolver som svarte.
Myte: delt tunnel er bare det raskere alternativet
Delt tunnel selges ofte som en ytelsesfunksjon, og det kan den være, men det er en bivirkning og ikke definisjonen. Definisjonen er en rutingbeslutning om hvilke destinasjoner som går inn i tunnelen. Hastighetsforskjellen vises bare når den direkte veien virkelig er bedre enn omveien gjennom kontoret. På en overbelastet hjemmelinje og en lett belastet gateway kan full tunnel være den raskeste av de to.
Så den ærlige rammen handler om veiens eierskap og kontroll, mens ytelse er noe man måler etterpå. En policy valgt for hastighet som stille flytter DNS-en og den offentlige utgangen din, er valgt av feil grunn.
Hva som faktisk endres: utgangen
Under full tunnel ser et offentlig nettsted kontorets utgangsadresse, og kontorets filtrering ser forespørselen. Under delt tunnel ser samme nettsted brukerens hjemadresse, og kontoret ser ingenting. Dette er forskjellige synlighetsmodeller, og ingen av dem er automatisk sikrere. Det nyttige spørsmålet er hvilken organisasjonen faktisk kan drifte.
Kontroller det direkte i stedet for å stole på et Tilkoblet-merke. En offentlig adresseekko viser utgangen, og en resolvertest viser hvis DNS som svarte.
| 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 |
Hva gatewayen så må bære
En gateway som bærer videosamtaler, nedlastinger og private applikasjoner trenger kapasitet for en helt annen arbeidsbelastning enn en som bare bærer interne forespørsler. Nettstedets internettforbindelse bærer både brukerens ankomst og den påfølgende offentlige utgangen, så to linjer kan mettes samtidig.
Lokal utgang fjerner den belastningen og omveien, og den garanterer ikke en bedre opplevelse, fordi den direkte veien også kan være overbelastet. Sammenlign den faktiske applikasjonen i stedet for å behandle en rutingetikett som en ytelsesmåling.
Det finnes unntak under en full tunnel
En standardrute er ikke en fortegnelse over hver pakke. Mer spesifikke ruter, tillatelser for lokale nettverk, applikasjonsunntak og separate IPv6-regler flytter alle trafikk, og derfor kan en policy beskrevet som full tunnel fortsatt lekke. Operativsystemets rutingdokumentasjon gjør den forskjellen for tvungne tunnelstandarder, og klientens unntaksliste er der lekkasjen vanligvis bor. Verifiser atferd, ikke intensjon.
IPv6 fortjener et eget blikk, fordi en tunnel som bare bærer IPv4, lar en hel stabel stå utenfor policyen.
DNS er en egen policy
Interne navn trenger en resolver som kjenner dem, og den resolveren kan bare være tilgjengelig gjennom tunnelen. En nettleser med sin egen krypterte DNS kan omgå systemets resolver helt, noe som skaper en deling der interne navn feiler og offentlige virker, eller omvendt.
Bestem hvor oppslag skal gå, og få deretter klienten og nettleseren til å være enige. Vellykket offentlig surfing tester aldri intern navneoppløsning, så det er det feil beviset å vise til når et intranettsted forsvinner.
Skriv feilpolicyen, og test den så
Bestem hva som skjer når tunnelen faller: blokker alt, blokker bare private ressurser, eller tillat direkte tilkoblinger. Automatisk gjenoppkobling svarer ikke på det spørsmålet, og en kill switch som bare dekker tunnelgrensesnittet, kan la unntatte applikasjoner snakke fritt. Test en ekte frakobling og en nettverksendring, og les deretter klientens tilstand, fordi dokumentasjonen beskriver den tiltenkte atferden og ikke den installerte.
Skriv ned de private rutene, den offentlige utgangen, DNS-serverne, de lokale unntakene og feilatferden i ett kort notat. Det notatet er det som gjør policyen verifiserbar for noen som ikke skrev den.