Rutele împinse de OpenVPN nu sunt instalate: sincronizare, drepturi sau politică

Serverul spune că a împins ruta, clientul spune că este conectat, iar destinația rămâne inaccesibilă. Exact această imagine este produsă de trei cauze. Adăugarea rutei a rulat înainte ca dispozitivul să existe, clientului îi lipseau drepturile de a schimba tabela, sau o politică i-a spus clientului să ignore opțiunile împinse.

Din exterior arată identic și cer remedieri diferite. Citiți jurnalul clientului în punctul în care se ia decizia privind ruta.

Dovediți că ruta lipsește, nu doar că este stricată

Începeți prin a dovedi că ruta lipsește, nu că este stricată. În Linux, ip route show dev tun0 listează ce a instalat clientul pe dispozitivul de tunel. În Windows, route print sau Get-NetRoute arată același lucru sub formă de tabel.

O rută care există dar nu transmite trafic este o altă problemă. Aceasta mută investigația către regulile de transmitere și firewall, nu către instalarea rutei.

Sincronizare: adăugarea a rulat înainte ca dispozitivul să existe

Clientul analizează PUSH_REPLY serverului după ce canalul de control este activ și după ce a configurat interfața. Abia atunci atinge tabela de rutare, cu mecanismul oferit de platformă. Linux trece prin netlink; Windows folosește un API care necesită un token ridicat. Un script sau un client care adaugă rute imediat ce citește configurația poate rula înainte ca dispozitivul TUN/TAP să existe, iar nucleul respinge adăugarea.

Aceeași cursă explică de ce o rută scrisă manual funcționează, iar cea automată nu: când o scrieți, interfața este deja activă.

route-delay există pentru acest caz, iar route-up numește un script care rulează după configurarea interfeței și a rutelor. Puneți rutele care depind de adresa tunelului în acel cârlig, nu într-o etapă timpurie.

Drepturi: cine poate schimba tabela

Schimbarea tabelului de rutare din Windows necesită un token ridicat. O GUI pornită de un utilizator standard poate seta adresa adaptorului prin serviciu și totuși să nu poată adăuga o rută. Jurnalul arată atunci o eroare de tip acces refuzat în loc de o împingere lipsă.

Pornirea GUI ca administrator, sau folosirea clientului bazat pe serviciu, schimbă acel rezultat. O sarcină programată care pornește clientul fără tokenul necesar nu.

Verificați sub ce cont rulează de fapt clientul înainte de a schimba ceva. Versiunea și modul serviciului decid ce cauze sunt posibile, așa că notați ambele lângă ieșirea rutei.

Politică: rutele împinse pot fi aruncate intenționat

route-nopull face clientul să ignore rutele pe care serverul le împinge, inclusiv o rută implicită împinsă, în timp ce adresa tunelului este încă acceptată. Opțiunile DNS și DHCP împinse sunt aruncate de aceeași directivă. Un astfel de client nu este defect; el așteaptă linii de rută explicite în propria configurație.

route-noexec este un alt control: oprește complet clientul din a executa modificări de rută. O topologie pe care clientul nu o poate mapa poate produce un rezultat similar, iar ruta este înregistrată ca respinsă în loc de adăugată. Citiți linia de jurnal care raportează decizia în loc să ghiciți care dintre cele trei se aplică. Apoi verificați profilul efectiv, deoarece un importator sau un instrument de gestionare poate adăuga opțiuni pe care utilizatorul nu le-a editat niciodată.

Un profil care pare curat într-un editor de text poate transporta totuși o directivă adăugată la momentul execuției.

Comparați lista de împingere cu tabela

După conectare, puneți lista de împingere a serverului lângă tabela clientului. În Linux aceasta este ip route show dev tun0; în Windows, route print sau Get-NetRoute. Dacă ruta lipsește, remediați mai întâi instalarea. Dacă este prezentă și traficul eșuează, treceți la politica de transmitere și firewall.

Notați versiunea clientului, contul sub care rulează și dacă este bazat pe serviciu. Aceste trei fapte îi spun următoarei persoane ce cauze au fost excluse.