Documentația split-tunnel are nevoie de o regulă DNS lângă fiecare rută
O rută decide după adresă, un resolver decide după nume. Documentați ambii selectori per flux, fiecare cu un test, altfel nota eșuează când DNS-ul se mută.
O notă despre split-tunnel care spune "traficul de birou trece prin VPN" a documentat o decizie și a implicat alte trei. La nivel de pachete, un tabel de rutare alege o interfață după adresa de destinație; la nivel de nume, un resolver alege un server după interogare, iar cele două alegeri se fac independent. De aceea un prefix documentat corect poate produce în continuare o mașină care rezolvă un nume intern într-o adresă publică, sau care nu rezolvă nimic în timp ce ruta pare perfectă.
Doi selectori, o încercare de conexiune
Când o aplicație se conectează la files.corp.example, au loc două căutări înainte de a exista un pachet. Resolverul decide ce server primește interogarea, folosind domenii de căutare, domenii de rutare per legătură sau o regulă explicită de profil. Tabelul de rutare decide apoi unde merge adresa rezultată, folosind cea mai lungă potrivire de prefix cu destinația.
Nimic nu leagă aceste două decizii. O zonă privată poate răspunde cu 10.20.4.11 în timp ce tabelul de rutare trimite 10.20.0.0/16 în tunel, iar conexiunea funcționează. Inversează oricare și eșuează într-un mod care arată ca cealaltă: politică DNS corectă plus o rută lipsă dă un nume rezolvat și un timeout, în timp ce o rută corectă plus un resolver public dă o adresă care se rutează curat către locul greșit.
DNS-ul cu orizont divizat face acest lucru mai ascuțit. Același nume poate returna o adresă privată de la resolverul intern și o adresă publică de la cel orientat spre internet, așa că o notă care înregistrează doar prefixul nu poate prezice ce adresă va folosi clientul de fapt. Scrieți calea resolverului, altfel adresa este o presupunere.
Ce omite o notă doar despre rută
O înregistrare doar despre rută este inutilă pentru cea mai frecventă defecțiune split-tunnel: numele. Utilizatorul raportează că intranetul nu se încarcă, tunelul este activ și prefixul este prezent. Cine preia tichetul nu are nicio înregistrare despre ce resolver ar fi trebuit să răspundă, nicio modalitate de a distinge un sufix de căutare greșit de un server blocat și nicio linie de bază pentru comparație.
A doua omisiune este lista de excepții. Un design split-tunnel este definit la fel de mult de ce rămâne în afara tunelului, cât de ce intră în el, iar intervalele excluse sunt de obicei primele care se strică, deoarece o rută locală mai specifică sau un filtru pe partea clientului poate anula intenția fără a atinge profilul.
A treia este partea îndepărtată a tunelului. O rută de client pune doar pachetul pe fir; gateway-ul trebuie totuși să îl trimită mai departe și să aibă o cale de întoarcere. Ghidul strongSwan pentru redirecționare reamintește că regulile de redirecționare și firewall de pe gateway fac parte din funcționalitate, nu din instalația pe care o poți presupune.
Câmpurile care fac nota executabilă
Un rând per flux, iar un flux este o destinație plus un nume plus un proprietar. Acestea sunt câmpurile care supraviețuiesc contactului cu un incident real:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
Rândul "unde locuiește" este cel pe care oamenii îl sar. Un prefix împins de server, o rută adăugată de un profil de client și o rută tastată într-un shell diferă prin cine le poate schimba și dacă supraviețuiesc unei reconectări. Fără acel câmp, următorul inginer nu poate spune pe care dintre cele trei se uită.
Un test per regulă, nu unul per tunel
Fiecare rând are nevoie de două verificări inofensive: una care exersează ruta și una care exersează numele. Pentru rută, cereți ceva ce trebuie să traverseze tunelul și confirmați calea, nu accesibilitatea, de exemplu tracert -d 10.20.4.11 pe Windows sau ip route get 10.20.4.11 pe Linux. Pentru nume, interogați numele privat și înregistrați ce server a răspuns, folosind resolvectl query files.corp.example sau dig files.corp.example împotriva resolverului pe care nota îl numește.
Adăugați și o așteptare negativă: ce ar trebui să se întâmple când tunelul este oprit. O aplicație exclusă pe un dispozitiv Android sau iOS cu blocare fără VPN activată poate să nu aibă deloc conectivitate, iar un client desktop poate lăsa aceeași aplicație să funcționeze în timp ce tunelul se reconectează. Înregistrarea răspunsului dorit transformă "VPN-ul mi-a stricat aplicația" într-o afirmație verificabilă.
Păstrați înregistrarea împreună cu configurația
Stocați nota lângă profilul pe care îl descrie și versionați-o cu acel profil. Un document într-un wiki pe care nimeni nu îl actualizează este o vorbă; un tabel în același depozit ca rutele împinse și politica resolverului poate fi revizuit în aceeași modificare.
Când ceva se strică, comparați ruta aplicată și resolverul efectiv cu înregistrarea înainte de a adăuga o altă excepție. Două dintre cele trei cauze comune — o regulă veche de spațiu de nume și un proces ajutător din afara politicii aplicației — arată exact ca o defecțiune VPN și sunt invizibile dacă nota listează doar prefixe.
Înainte de a declara nota terminată, confirmați că răspunde în scris la acestea: ce prefix, pentru ce familie de adrese; ce spațiu de nume privat, răspuns de ce resolver; ce nume rămân deliberat publice; unde este configurată fiecare regulă și cine o deține; și singura comandă care dovedește ruta și cea care dovedește numele. Dacă lipsește ceva, următorul incident va fi diagnosticat de la zero.