OpenVPN stumiamų maršrutų neįdiegia: laikas, teisės ar politika

Serveris sako, kad maršrutą stūmė, klientas sako, kad prisijungė, o paskirties vieta vis tiek nepasiekiama. Būtent tokį vaizdą sukuria trys priežastys. Maršruto pridėjimas įvyko prieš atsirandant įrenginiui, klientui trūko teisių keisti lentelę, arba politika liepė klientui nepaisyti stumiamų parinkčių.

Iš išorės jie atrodo vienodai ir reikalauja skirtingų pataisymų. Skaitykite kliento žurnalą toje vietoje, kur priimamas sprendimas dėl maršruto.

Įrodykite, kad maršruto nėra, o ne tik kad jis sugedęs

Pradėkite įrodydami, kad maršruto nėra, o ne kad jis sugedęs. Linux sistemoje ip route show dev tun0 išvardija, ką klientas įdiegė tunelio įrenginyje. Windows sistemoje route print arba Get-NetRoute rodo tą patį lentelės forma.

Maršrutas, kuris egzistuoja, bet neperduoda srauto, yra kita problema. Tai perkelia tyrimą prie perdavimo ir užkardos taisyklių, o ne prie maršruto diegimo.

Laikas: pridėjimas įvyko prieš atsirandant įrenginiui

Klientas analizuoja serverio PUSH_REPLY po to, kai valdymo kanalas pakilo ir kai jis sukonfigūravo sąsają. Tik tada jis paliečia maršrutizavimo lentelę, naudodamas bet kokį platformos teikiamą mechanizmą. Linux eina per netlink; Windows naudoja API, kuriam reikia padidintų teisių žetono. Scenarijus ar klientas, kuris prideda maršrutus vos perskaitęs konfigūraciją, gali veikti prieš atsirandant TUN/TAP įrenginiui, ir branduolys atmeta pridėjimą.

Tos pačios lenktynės paaiškina, kodėl ranka įvestas maršrutas veikia, o automatinis ne: kai jį įvedate, sąsaja jau pakilusi.

route-delay egzistuoja būtent šiam atvejui, o route-up nurodo scenarijų, kuris paleidžiamas sukonfigūravus sąsają ir maršrutus. Maršrutus, kurie priklauso nuo tunelio adreso, dėkite į tą kabliuką, o ne į ankstyvą etapą.

Teisės: kas gali keisti lentelę

Windows maršrutizavimo lentelės keitimui reikia padidintų teisių žetono. Standartinio naudotojo paleista GUI gali nustatyti adapterio adresą per paslaugą ir vis tiek negalėti pridėti maršruto. Tada žurnalas rodo prieigos atmesta tipo klaidą, o ne trūkstamą stūmimą.

GUI paleidimas administratoriaus teisėmis arba paslaugomis pagrįsto kliento naudojimas pakeičia tą rezultatą. Suplanuota užduotis, kuri paleidžia klientą be reikiamo žetono, to nekeičia.

Prieš ką nors keisdami patikrinkite, kokia paskyra klientas iš tikrųjų veikia. Versija ir paslaugos režimas lemia, kurios priežastys apskritai galimos, todėl abu užsirašykite prie maršruto išvesties.

Politika: stumiamus maršrutus galima sąmoningai atmesti

route-nopull verčia klientą nepaisyti serverio stumiamų maršrutų, įskaitant stumiamą numatytąjį maršrutą, o tunelio adresas vis dar priimamas. Stumiamos DNS ir DHCP parinktys atmetamos ta pačia direktyva. Toks klientas nėra sugedęs; jis tikisi aiškių maršruto eilučių savo konfigūracijoje.

route-noexec yra kita kontrolė: ji visiškai sustabdo klientą nuo maršruto pakeitimų vykdymo. Topologija, kurios klientas negali atvaizduoti, gali duoti panašų rezultatą, o maršrutas registruojamas kaip atmestas, o ne pridėtas. Skaitykite žurnalo eilutę, kuri praneša sprendimą, o ne spėliokite, kuri iš trijų priežasčių galioja. Tada patikrinkite faktinį profilį, nes importuotojas ar valdymo įrankis gali pridėti parinkčių, kurių naudotojas niekada neredagavo.

Profilis, kuris teksto redaktoriuje atrodo švarus, vis tiek gali turėti pridėtą direktyvą vykdymo metu.

Palyginkite stūmimo sąrašą su lentele

Prisijungę padėkite serverio stūmimo sąrašą šalia kliento lentelės. Linux sistemoje tai ip route show dev tun0; Windows sistemoje route print arba Get-NetRoute. Jei maršruto nėra, pirmiausia pataisykite diegimą. Jei jis yra, o srautas nepraeina, pereikite prie perdavimo ir užkardos politikos.

Užrašykite kliento versiją, paskyrą, kuria jis veikia, ir tai, ar jis pagrįstas paslauga. Šie trys faktai pasakys kitam žmogui, kurios priežastys buvo atmestos.