Doar includere sau doar excludere: care este implicitul?
Alege implicitul înainte de a construi lista: tunelează doar ce numești, sau tunelează tot și decupează excepțiile. Apoi testează aplicația pe care nimeni nu o adăugase.
Deschide secțiunea de rutare a clientului tău VPN și vezi două controale de formă diferită care poartă adesea aceeași etichetă. Unul îți cere să listezi destinațiile care aparțin tunelului, iar tot restul continuă să folosească rețeaua locală. Celălalt presupune că totul trece prin tunel și întreabă ce trebuie decupat. Ambele îți dau un tunel funcțional la primul test, și ambele se întrețin adăugând linii într-o listă, motiv pentru care diferența rămâne invizibilă până când cineva instalează ceva nou.
Alegerea este un implicit, nu o funcție. Stabilește-l înainte ca lista să aibă douăzeci de intrări.
Citește implicitul pe client, nu în broșură
WireGuard face decizia neobișnuit de vizibilă, pentru că AllowedIPs este o listă de includere și nimic altceva. Un peer cu 0.0.0.0/0, ::/0 tunelează tot; un peer cu 10.20.0.0/16 tunelează doar asta. Nu există sintaxă de excludere, așa că dacă vrei să lași o subrețea pe dinafară trebuie fie să enumeri toate celelalte prefixe, fie să adaugi rutare pe politici în afara interfeței.
OpenVPN ajunge în același loc din cealaltă direcție, cu redirect-gateway def1 instalând un tunel complet și directive route explicite care adaugă sau suprascriu prefixe anume. Clienții comerciali ascund de obicei ambele în spatele unei casete de bifare și al unui tabel de destinații, așa că citește care dintre cele două este editat efectiv de tabel înainte să te bazezi pe etichetă.
Întrebarea nu este cum se numește caseta de bifare. Întrebarea este ce se întâmplă cu un pachet a cărui destinație nu apare în niciuna dintre cele două liste. Răspunde la asta în scris, iar restul configurației decurge de acolo. Dacă sari peste întrebare, prima defecțiune neexplicată va fi decisă de cine se află în acea zi cel mai aproape de client.
Urmărește o aplicație pe care nimeni nu a adăugat-o
Într-un proiect doar cu includere, aplicația respectivă merge direct, pe rețeaua locală, cu DNS-ul local. Într-un proiect doar cu excludere, trece prin tunel, în limitele a ceea ce permite serverul, și de multe ori aceasta este diferența dintre un instrument SaaS nou care funcționează din prima zi și un tichet care spune că VPN-ul l-a stricat.
Niciunul dintre cele două implicite nu este mai sigur în sine. Includerea restrânge ce transportă tunelul și face din rețeaua locală calea de cea mai mică rezistență; excluderea ia tunelul ca traseu normal și tratează excepțiile ca excepții, ceea ce este mai aproape de ceea ce majoritatea politicilor corporative intenționează de fapt.
| Question | Include-only | Exclude-only |
|---|---|---|
| Unlisted new app | goes direct | goes through the tunnel |
| A site that breaks over the VPN | add it to the list | carve it out |
| Internal names still resolve | only if routed and served | usually, until split DNS says otherwise |
| Upkeep | one entry per internal service | one entry per misbehaving public service |
Observă ce tip de obiect listează platforma
Componenta VpnService.Builder din Android expune o listă de aplicații permise și o listă de aplicații interzise ca două modele separate, iar regulile pe aplicație aleg după pachet, nu după destinație. Un browser pus într-o astfel de listă duce cu el fiecare destinație pe care o deschide, ceea ce este o granularitate diferită de un tabel de rutare și nu poate repara un singur site stricat în interiorul unei aplicații care funcționează.
Clienții desktop amestecă de obicei ambele tipuri într-o singură interfață, așa că verifică dacă rândul pe care îl adaugi este un pachet, un nume de gazdă sau un prefix. Eșuează în moduri diferite și se rezolvă în locuri diferite. Un rând de nume de gazdă devine de obicei o rută plus un nume, în timp ce un rând de pachet devine o decizie de politică în interiorul clientului. Notează pe care dintre cele două l-ai adăugat, pentru că persoana care depanează mai târziu o va presupune pe cealaltă.
Testează starea de eșec, nu doar calea fericită
O aplicație exclusă din tunel nu primește automat acces direct curat. Dacă clientul impune suplimentar o regulă care blochează fără VPN, traficul exclus poate fi aruncat complet, ceea ce arată ca o aplicație stricată și nu ca o decizie de rutare. Testează acel caz intenționat, în loc să îl afli dintr-un raport de utilizator.
Verifică apoi DNS și IPv6 ca puncte separate. Un tunel care transportă doar IPv4 lasă unei aplicații capabile de v6 o cale pe lângă el, iar DNS-ul divizat decide dacă numele interne se rezolvă pentru trafic care nu trece deloc prin tunel. Rulează o aplicație listată, una nelistată, o interogare de nume și o reconectare, și păstrează rezultatele împreună cu configurația.
Scrie implicitul acolo unde îl va găsi următoarea persoană
Consemnează implicitul ales, excepțiile și cine răspunde de ele în același loc cu profilul clientului, pentru că următorul administrator va adăuga o intrare fără să citească acest raționament. Notează data și motivul fiecărei excepții, ca o excepție devenită inutilă pentru un site între timp reparat să poată fi scoasă cu încredere. O listă fără motive crește la nesfârșit.
Când cineva raportează o singură destinație stricată, modifică excepția, nu linia de bază. Inversarea implicitului pentru a repara un singur site mută în tăcere fiecare aplicație nelistată pe cealaltă parte a tunelului.