route-gateway nu este redirect-gateway: ce se schimbă de fapt

Tunelul tău urcă, subrețeaua privată răspunde, iar navigarea obișnuită dispare în continuare în VPN, deși cineva a șters linia gateway-ului din profil. Combinația aceea este amprenta directivei greșite care a fost editată. Ce a fost eliminat îi dădea clientului un următor salt pentru rutele pe care le instalează; ce a continuat să prindă traficul a venit de altundeva și a fost împins de server. Acoperirea și următorul salt sunt sarcini separate, și doar una dintre ele decide dacă destinațiile publice folosesc tunelul.

Linia pe care ai eliminat-o era un următor salt, nu un comutator de politică

Fiecare rută pe care clientul o instalează are nevoie de o adresă de gateway către care să indice, iar directiva de gateway este sursa acelei adrese atunci când o rută nu numește niciuna. Șterge-o și acele rute nu au de ce să se prindă, așa că fie nu se instalează, fie ajung pe o cale care nu duce nicăieri. Subrețeaua privată este exact ceea ce transporta o astfel de rută.

Între timp, comportamentul care a supraviețuit are alt autor: o opțiune de redirecționare în blocul împins, care mută traficul obișnuit de ieșire în tunel conform steagurilor sale. Eliminarea gateway-ului nu o dezactivează și nu o slăbește. Rezultatul este cel mai rău dintre cele două stări, cu traficul public încă prins și destinația privată care justifica tunelul acum inaccesibilă. De aceea și a doua editare, făcută în același spirit, nu schimbă nimic.

Patru pârghii, patru sarcini diferite

În această discuție patru directive sunt citate interschimbabil, iar doar una dintre ele guvernează acoperirea, adică ce destinații trec prin tunel. A doua stabilește următorul salt folosit de rute, a treia instalează un singur prefix, iar a patra aruncă tot ce a împins serverul, inclusiv rutele private de care are nevoie implementarea. Tabelul le ordonează după ce încearcă un administrator să schimbe și nu după nume, pentru că numele sunt cele care provoacă confuzia. Tratează-le ca patru decizii separate și alege-o pe cea pe care vrei cu adevărat să o anulezi.

În practică, toate patru sosesc adesea într-un singur bloc împins, linie după linie, ceea ce le face să pară părți ale unei singure setări. Nu sunt, iar referința OpenVPN le documentează ca mecanisme distincte exact din acest motiv. A afla ce decizie anulezi este munca; editarea este o singură linie.

Filtrează linia împinsă, păstrează următorul salt

Dacă acoperirea față de care ai obiecții sosește ca opțiune împinsă, răspunsul îngust este să ignori acea opțiune după nume și să lași restul blocului împins intact. Scris ca filtru, arată ca linia de mai jos, iar locul lui este în profilul clientului afectat, nu în configurația serverului.

pull-filter ignore "redirect-gateway"

Îngustimea este ideea. Deoarece filtrul compară un prefix de text, un model mai scurt se potrivește și cu directiva următorului salt, ceea ce desprinde exact informația de care depind rutele private și repetă eroarea inițială într-o haină nouă. Un filtru acționează și doar asupra opțiunilor împinse, așa că nu atinge niciodată o linie echivalentă scrisă local sau impusă de un manager de rețea. Reconectează-te după aceea, pentru că o sesiune activă nu reevaluează ce a împins serverul.

Citește căutarea, nu tabelul

După reîncărcarea profilului, întreabă nucleul unde ar merge de fapt două destinații: una în interiorul prefixului privat și una pe internetul public. O descărcare completă a tabelului principal este mai greu de citit și mai ușor de citit greșit, pentru că o rută poate exista și totuși poate pierde în fața unei potriviri mai specifice. La rutarea bazată pe politici, regula, tabelul și adresa sursă fac și ele parte din verificare.

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

Varianta def1 merită familiaritate, pentru că lasă vizibilă vechea intrare implicită în timp ce o pereche de jumătăți-implicite câștigă căutarea. Așadar, o linie 0.0.0.0/0 în ieșire nu dovedește nimic prin ea însăși. Căutarea răspunde la întrebarea la care listarea doar pare să răspundă.

DNS, IPv6 și ruta privată trebuie să funcționeze în continuare

Refuzul unei redirecționări IPv4 nu spune nimic despre resolver, așa că o opțiune DNS împinsă poate continua să trimită interogări în tunel în timp ce rutele par corecte. Un implicit IPv6 poate face același lucru pentru o familie de adrese pe care verificarea IPv4 nu a atins-o niciodată. Ambele au nevoie de o decizie explicită în loc de o presupunere. Apoi confirmă că serviciul privat încă răspunde, pentru că un tunel divizat care și-a pierdut ruta privată nu este un tunel divizat, este unul stricat.

Un instrument mai larg merită un avertisment: route-nopull aruncă fiecare rută împinsă și fiecare opțiune DNS împinsă, ceea ce oprește cu siguranță tunelul complet și, la fel de sigur, rupe rutele private de care depinde implementarea, deci este un ciocan mult mai mare decât un filtru de nume îndreptat spre o singură opțiune. Verifică destinația privată, o destinație publică și resolverul după orice modificare, și tratează un handshake finalizat drept dovadă pentru nimic altceva decât handshake-ul.