Tunel complet versus tunel divizat: cele patru diferențe
Eticheta decide pe unde iese restul traficului unui laptop, nu cât de rapid este. Comparați ieșirea, încărcarea, DNS-ul și comportamentul la eșec înainte de a alege.
Etichetele tunelului descriu unde merge restul traficului unui laptop, nu cât de repede merge. Cu un tunel complet, cererile publice trec prin gateway-ul VPN înainte de a ieși pe internet. Cu un tunel divizat, destinațiile private folosesc tunelul, iar tot restul ia calea locală. Ambele ajung la aplicația internă, așa că testul de accesibilitate pe care oamenii îl fac primul nu spune nimic despre politica implementată.
Testați în schimb ieșirea: ce adresă raportează o pagină publică de ecou și ce resolver a răspuns.
Mit: tunelul divizat este doar opțiunea mai rapidă
Tunelul divizat este adesea vândut ca funcție de performanță și poate fi, dar acesta este un efect secundar, nu definiția. Definiția este o decizie de rutare privind destinațiile care intră în tunel. Diferența de viteză apare doar când calea directă este cu adevărat mai bună decât ocolul prin birou. Pe o conexiune de acasă aglomerată și un gateway slab încărcat, tunelul complet poate fi cel mai rapid dintre cele două.
Deci cadrul onest privește proprietatea și controlul căii, iar performanța este ceva ce se măsoară ulterior. O politică aleasă pentru viteză care mută în tăcere DNS-ul și ieșirea publică a fost aleasă din motivul greșit.
Ce se schimbă de fapt: ieșirea
Sub un tunel complet, un site web public vede adresa de ieșire a biroului, iar filtrarea biroului vede cererea. Sub un tunel divizat, același site vede adresa de acasă a utilizatorului, iar biroul nu vede nimic. Sunt modele de vizibilitate diferite și niciunul nu este automat mai sigur. Întrebarea utilă este pe care organizația o poate opera cu adevărat.
Verificați-o direct în loc să aveți încredere într-o insignă Conectat. Un ecou de adresă publică arată ieșirea, iar un test de resolver arată al cui DNS a răspuns.
| 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 |
Ce trebuie apoi să transporte gateway-ul
Un gateway care transportă apeluri video, descărcări și aplicații private are nevoie de capacitate pentru o încărcătură de lucru complet diferită de cel care transportă doar cereri interne. Conexiunea la internet a site-ului transportă atât sosirea utilizatorului, cât și ieșirea publică ulterioară, așa că două legături se pot satura simultan.
Ieșirea locală elimină acea încărcare și ocolul și nu garantează o experiență mai bună, deoarece și calea directă poate fi aglomerată. Comparați aplicația reală în loc să tratați o etichetă de rutare drept măsurătoare de performanță.
Există excepții sub un tunel complet
O rută implicită nu este un inventar al fiecărui pachet. Rute mai specifice, permisiuni pentru rețeaua locală, excluderi de aplicații și reguli IPv6 separate mută toate traficul, motiv pentru care o politică descrisă ca tunel complet poate încă scăpa. Documentația de rutare a sistemului de operare face această distincție pentru valorile implicite de tunel forțat, iar lista de excepții a clientului este locul unde scurgerea trăiește de obicei. Verificați comportamentul, nu intenția.
IPv6 merită o privire separată, deoarece un tunel care transportă doar IPv4 lasă un întreg stack în afara politicii.
DNS este o politică separată
Numele interne au nevoie de un resolver care le cunoaște, iar acel resolver poate fi accesibil doar prin tunel. Un browser cu propriul DNS criptat poate ocoli complet resolverul sistemului, ceea ce produce o divizare în care numele interne eșuează și cele publice funcționează, sau invers.
Decideți unde trebuie să meargă căutările, apoi faceți clientul și browserul să fie de acord. Navigarea publică reușită nu testează niciodată rezolvarea numelor interne, așa că este dovada greșită de citat atunci când un site de intranet dispare.
Scrieți politica de eșec, apoi testați-o
Decideți ce se întâmplă când tunelul cade: blocați tot, blocați doar resursele private sau permiteți conexiuni directe. Reconectarea automată nu răspunde la această întrebare, iar un întrerupător de siguranță care acoperă doar interfața tunelului poate lăsa aplicațiile excluse să vorbească liber. Testați o deconectare reală și o schimbare de rețea, apoi citiți starea clientului, deoarece documentația descrie comportamentul dorit, nu pe cel instalat.
Notați rutele private, ieșirea publică, serverele DNS, excepțiile locale și comportamentul la eșec într-o notă scurtă. Acea notă este ceea ce face politica verificabilă de cineva care nu a scris-o.