Păstrați rutele private și renunțați la redirecționare: tunel OpenVPN divizat

Tunelul urcă, aplicația se încarcă, iar apoi tot restul de pe laptop începe să se comporte ciudat. Aceasta este forma obișnuită a unei politici doar pentru rețele private, implementată prin ștergerea unei linii. Eliminarea unei rute implicite împinse schimbă într-adevăr unde merge traficul, dar nu spune unde ar trebui să meargă traficul în schimb, și nu atinge deloc rezolvarea numelor. O politică are nevoie de două jumătăți pozitive înainte de a putea fi testată.

Ștergerea redirecționării este doar jumătate din schimbare

O redirecționare a tunelului complet și o politică doar pentru rețele private diferă prin ceea ce afirmă despre lume. Redirecționarea revendică fiecare destinație, în timp ce politica privată revendică o listă și lasă restul în pace. Ștergerea revendicării fără a scrie lista produce un client care nu ajunge nicăieri în afara rețelei locale, ceea ce arată ca o defecțiune de rutare și nu ca o lacună în politică. Scrieți lista înainte de a elimina revendicarea, iar ordinea acelor două pași încetează să mai conteze.

Ambele jumătăți sunt cerințe, nu valori implicite. Prefixele private trebuie să intre în tunel, iar destinațiile obișnuite trebuie să păstreze calea pe care o aveau înainte de conexiune.

Dacă o organizație impune tunelul complet, nimic din toate acestea nu se aplică. Proiectarea doar pentru rețele private aparține implementărilor în care rutarea divizată este aprobată.

pull-filter este o potrivire, nu un comutator

Directiva pull-filter elimină opțiunile împinse ale căror nume se potrivesc cu un prefix, și asta este tot ce face. Ignorarea redirecționării lasă fiecare altă opțiune împinsă la locul ei, ceea ce de obicei este ceea ce doriți: rutele, setările DNS și valoarea porții de rutare ajung în continuare. Nu poate elimina nici o directivă scrisă în profilul local, pentru că filtrarea se aplică la ceea ce împinge serverul.

Rezistați tentației de a ignora fiecare opțiune care începe cu route. Acel model aruncă și rutele private de care are nevoie conexiunea, și poate pierde informații despre poartă de care depinde tunelul.

route-nopull este o decizie mai largă decât pare. Împiedică clientul să accepte rutele împinse și opțiunile în stil DHCP ca grup, ceea ce este o politică diferită de filtrarea unei singure opțiuni.

Scrieți lista de rute dinspre aplicație spre exterior

Începeți cu ceea ce utilizatorul deschide de fapt, apoi adăugați piesele de sprijin. O aplicație la 10.60.20.15 implică subrețeaua sa 10.60.0.0/16, iar un nume privat implică rezolvatorul care răspunde la el. Prin urmare, un utilizator care a cerut o singură aplicație are nevoie de două destinații și de o decizie DNS. Tot ce depășește acea listă este în afara sferei prin construcție, și exact asta menține politica verificabilă.

Pe un server care cooperează, acestea devin două rute împinse, și niciuna nu este o redirecționare. Păstrați topologia tunelului și valorile porții de rutare pe care le furnizează serviciul existent.

Când doar unii utilizatori au nevoie de această politică, aplicați-o per client sau per grup. Schimbarea rutării tuturor pentru a corecta cerința unei singure echipe este felul în care un tunel divizat devine o întrerupere.

Faceți DNS-ul să urmeze aceeași cale

O rută către rezolvator nu este o politică a rezolvatorului. Pe un client systemd-resolved rezultatul semantic este un domeniu de rutare pentru spațiul de nume privat care indică rezolvatorul intern, și asta face ca doar acele nume să îl folosească. Un client Windows are nevoie în schimb de propriul mecanism de politică a spațiilor de nume. O linie de server DNS în profil nu instalează niciuna dintre ele de la sine.

Verificați ce a selectat sistemul de operare, nu ce a cerut profilul. În Linux, resolvectl status arată domeniul și serverul pentru fiecare legătură; în Windows, tabelul de politici ale spațiilor de nume este dovada echivalentă.

Mențineți rezolvatorul accesibil prin tunel, altfel politica indică o adresă care nu poate fi interogată. O adresă de rezolvator la care tunelul nu ajunge transformă o politică funcțională într-o expirare de timp.

Verificați ambele jumătăți la o reconectare

Reconectați clientul după modificare și inspectați ruta efectivă către o adresă privată și către una publică. Apoi rezolvați un nume privat și un nume public și confirmați că fiecare a folosit rezolvatorul dorit. Încărcarea unui site public dovedește doar a doua jumătate, iar aceea este jumătatea care de obicei funcționează din întâmplare.

Notați politica finală într-o propoziție: aceste prefixe și nume folosesc această conexiune, tot restul urmează calea locală. Apoi păstrați-o în profil în loc să reparați setările adaptorului după fiecare autentificare.