Tunelarea completă este mai simplă decât o listă lungă de tunelare divizată?

O listă de tunelare divizată începe cu trei aplicații și ajunge să acopere cea mai mare parte a mașinii, iar fiecare linie nouă este excepția cuiva. În acel moment lista a devenit discret un implicit cu pași în plus. Tunelarea completă inversează aranjamentul: totul intră în tunel dacă o excludere documentată nu spune altfel. Dacă asta este mai simplu depinde de gateway și de serviciile locale pe care le-ai rupe.

Începe prin a număra regulile pe care le întreții

Numără intrările, apoi numără câte au un proprietar numit și o dată a ultimei verificări. Al doilea număr este cel care contează, pentru că o excepție fără proprietar nu poate fi evaluată când software-ul la care se referă este redenumit sau înlocuit. Regulile legate de calea unui executabil eșuează silențios după o actualizare, iar eșecul arată ca un VPN instabil, nu ca o regulă învechită. Notează lista înainte de a avea o părere despre ea.

Fiecare intrare ar trebui să răspundă la trei întrebări: ce se strică fără ea, cine a decis asta și cum ai observa dacă motivul a expirat. Intrările care nu pot răspunde la toate trei sunt candidate la ștergere, nu la migrare, iar ștergerea lor mai întâi face comparația ulterioară onestă.

Dacă majoritatea intrărilor rută o parte mare a traficului, rulezi deja un tunel complet cu o povară de întreținere atașată. Decizia este atunci despre unde locuiește implicitul, nu despre dacă să ai unul.

Verifică dacă gateway-ul poate duce implicitul

Tunelarea completă mută fiecare pachet către un singur dispozitiv, ceea ce schimbă simultan încărcarea CPU, tabela conntrack, traducerea adreselor și cerința de lățime de bandă upstream a acelui dispozitiv. Un gateway care deservea confortabil câteva subrețele interne poate nu a fost dimensionat pentru toată navigarea unui utilizator. Uită-te la cel mai mare număr de sesiuni simultane pe care îl aștepți, nu la medie, pentru că vârful se rupe primul.

ip -s link show dev tun0
conntrack -C
ss -s

Măsoară aceeași încărcare înainte și după schimbare în loc să raționezi din specificații. O singură după-amiază de utilizare obișnuită pe o mașină va arăta dacă gateway-ul este aproape de o limită, și nu costă nimic față de a descoperi asta într-o dimineață de luni.

Verifică și MTU-ul căii cap la cap, pentru că un implicit complet expune fiecare aplicație la dimensiunea maximă de pachet a tunelului. Aplicațiile care funcționau în afara tunelului pot depinde acum de un comportament de fragmentare la care nu a trebuit să te gândești niciodată.

Confirmă că serviciile locale și DNS-ul privat încă funcționează

Enumeră ce trebuie să rămână local după protocol, nu după numele aplicației: protocoale de descoperire pentru imprimante și ecrane, o punte de casă inteligentă, pagina de administrare a unui router, un server local de dezvoltare accesat printr-un nume care se rezolvă doar în LAN. Acestea se strică atunci când ruta implicită începe să indice într-un tunel și se strică în tăcere pentru că nimic nu înregistrează o eroare la client.

DNS-ul privat este cealaltă dependență. Dacă numele interne erau rezolvate de resolverul tunelului înainte, nimic nu se schimbă; dacă erau rezolvate local, un implicit complet trebuie să le ducă la un resolver care cunoaște zonele. Testează un nume intern și un nume public după schimbare, în loc să presupui că lista de resolvere a supraviețuit.

Scrie excepțiile locale în profilul care le deține. O excepție păstrată doar în memoria cuiva este primul lucru pe care îl pierde următoarea migrare.

Migrează un profil și verifică limitele

Schimbă profilul prin configurația care îl deține, în loc să suprapui un nou implicit peste rute manuale lăsate de experimente anterioare. Acele rute rămase sunt cauza obișnuită a unei migrări care pare să funcționeze și se comportă inconsecvent o zi mai târziu. Ține profilul vechi disponibil, astfel încât o revenire să fie o selecție, nu o reconstrucție.

Apoi verifică separat două limite: că destinațiile publice și private funcționează amândouă, și că traficul nedorit nu iese în afara tunelului. O încărcare reușită de pagină dovedește prima și nu spune nimic despre a doua.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Repetă verificarea după o reconectare și după o întrerupere, pentru că un kill switch care blochează traficul în timpul unei căderi este o proprietate diferită de o rută care se restaurează corect după aceea. Designul mai simplu este cel a cărui acoperire reală o poți încă explica după ce o aplicație sau o rețea se schimbă.