Ce împiedică de fapt route-nopull din OpenVPN să fie împins de server

Ați pus route-nopull într-un profil de client ca să împiedicați tunelul să înghită ruta implicită, iar acum subrețeaua biroului este inaccesibilă în timp ce clientul spune în continuare că este conectat. Ambele observații sunt adevărate și nimic nu a eșuat. Fanionul îi spune clientului să sară peste rutele și înregistrările DHCP pe care serverul le împinge, o instrucțiune mai îngustă decât se așteaptă majoritatea când îl adaugă. Ce rămâne este un tunel funcțional fără opinie despre care destinații ar trebui să îl folosească.

Acel decalaj este întreaga decizie despre care este acest articol. Fie serverul descrie rețeaua, fie clientul, iar fanionul predă acea sarcină clientului fără a face nimic din ea pentru dumneavoastră.

Ce oprește fanionul la conectare

Un client OpenVPN care trage primește de obicei de la server, după autentificare, un pachet: rute, o redirecționare a gateway-ului implicit, servere DNS și câteva directive de reglaj. Cu route-nopull în vigoare, clientul acceptă în continuare sesiunea, verifică în continuare certificatele, negociază în continuare cifrurile și keepalive-urile și ridică în continuare interfața. Ce aruncă este aplicarea liniilor route împinse și a liniilor dhcp-option împinse, inclusiv DNS.

Confuzia vine de la un indicator verde lângă o aplicație moartă. Tunelul există; maparea destinațiilor către acel tunel nu. Nimic din panoul de stare al clientului nu distinge «conectat și rutează» de «conectat și inert», pentru că din punctul de vedere al tunelului ambele sunt aceeași stare.

De ce un tunel viu poate totuși să nu ruteze nimic

Interfața apare cu propria adresă și, pe o legătură punct-la-punct, adesea nu are nimic mai specific decât o rută de gazdă către partener. O subrețea privată devine accesibilă doar când o rută arată spre acea interfață cu prefixul corect, iar cu împingerea dezactivată acea rută nu sosește niciodată. Nici profilul descărcat nu poate ajuta de obicei, pentru că a fost scris presupunând că serverul va furniza exact aceste informații. De aceea interfața poate părea sănătoasă în timp ce subrețeaua rămâne întunecată.

Citirea profilului dovedește prin urmare foarte puțin. Citiți starea de execuție, pe mașina conectată:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

O adresă fără rută de subrețea în a doua comandă este semnătura acestei probleme. A treia comandă răspunde apoi la întrebarea care contează cu adevărat pentru utilizatori, pentru că raportează interfața pe care nucleul ar alege-o pentru o destinație anume în locul listei la care sperați că o va folosi. Dacă răspunde prin legătura dumneavoastră fizică, tunelul nu este deloc pe traseu.

Rezolvarea numelor eșuează dintr-un motiv înrudit, nu dintr-unul separat. Înregistrările dhcp-option DNS împinse sunt sărite de același fanion, așa că interogările pentru gazde interne merg la orice resolver a furnizat rețeaua locală. Acel resolver nu are zonă pentru birou, așa că interogarea eșuează sau returnează un răspuns public, iar defecțiunea arată ca o problemă de server când este o problemă de configurare a clientului. Testarea unei adrese înaintea unui nume este ceea ce le separă pe cele două.

Alegerea între fanion și un filtru de prefix

Cele două opțiuni rezolvă forme diferite ale aceleiași plângeri, iar alegerea proastă este cea care produce starea conectat-dar-inutil. Una înlocuiește politica împinsă în întregime, cealaltă o editează după prefix. Tabelul dă versiunea scurtă, iar paragraful de după el acoperă partea care prinde oamenii.

pull-filter este un comparator de prefixe cu trei verbe, așa că poate accepta o familie de linii, le poate ignora în tăcere sau poate respinge conexiunea cu totul când apare un prefix. Exact ultimul comportament merită cunoscut: o regulă de respingere transformă un dezacord de politică într-o strângere de mână eșuată în loc de o omisiune tăcută. Manualul OpenVPN 2.6 listează prefixele acceptate și semantica exactă a fiecărui verb.

O cale de mijloc obișnuită este să respingeți doar redirect-gateway și să lăsați rutele biroului și DNS-ul să sosească așa cum s-a intenționat. Asta menține împingerea funcțională pentru părțile pe care serverul le înțelege mai bine decât dumneavoastră, împiedicând în același timp singura linie care ar prelua ruta implicită.

Adăugarea rutelor și a unui resolver manual

Dacă păstrați fanionul, profilul trebuie să spună ce ar fi spus serverul. Directivele route de pe partea clientului se aplică după stabilirea conexiunii, așa că funcționează alături de fanion în loc să fie blocate de el. Puneți-le în profil, nu într-o linie de comandă interactivă, altfel următoarea reconectare nu va reproduce starea funcțională.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

Linia DNS stă într-o poziție incomodă: este o directivă de pe partea clientului, dar unii clienți o aplică doar prin integrarea DNS a platformei, care o poate suprascrie când legătura se schimbă. Pe un host systemd, setarea resolverului direct pe interfața tunelului este mai previzibilă decât speranța că clientul va câștiga competiția de priorități:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Domeniul de rutare contează la fel de mult ca adresa. Fără el, interogările pentru nume publice pot fi trimise și către resolverul intern, iar orice resolver intern care refuză recursiunea va strica navigarea lăsând zona privată funcțională. Cu el, doar numele de sub acel sufix sunt rutate către resolverul tunelului și tot restul urmează legătura fizică.

Verificarea rezultatului: adresă, nume și calea exterioară

Trei teste separă defecțiunile posibile. Obțineți adresa privată după IP, apoi aceeași gazdă după nume, apoi un site public obișnuit. Un IP care funcționează cu un nume care eșuează indică resolverul; un IP care eșuează cu un nume care funcționează indică rutarea; ambele eșuând înseamnă de obicei că tunelul nu este pe traseu.

Apoi priviți spre exterior, nu spre interior. Ruta proprie a punctului final al tunelului trebuie să supraviețuiască schimbării, iar orice blocare trebuie limitată la tunel fără a captura punctul final. Un client care continuă să navigheze după căderea tunelului este o problemă de politică, nu de rutare, și nu va apărea în niciunul dintre cele trei teste de mai sus.

Scrieți lista finală în documentația profilului: rutele, resolverul, domeniile și motivul pentru care există fiecare. O reconectare care reproduce același tabel este singura dovadă că politica locală este completă. Dacă aplicațiile eșuează în continuare cu tunelul ridicat și toate cele trei teste trecute, următorul loc de privit este clasa problemelor conectat-dar-offline, nu certificatele deja verificate.