OpenVPN virzītie maršruti netiek instalēti: laiks, tiesības vai politika

Serveris saka, ka ir virzījis maršrutu, klients saka, ka ir savienots, un galamērķis joprojām nav sasniedzams. Tieši šo ainu rada trīs cēloņi. Maršruta pievienošana notika pirms ierīces pastāvēšanas, klientam trūka tiesību mainīt tabulu, vai politika lika klientam ignorēt virzītās opcijas.

No ārpuses tie izskatās vienādi un prasa dažādus labojumus. Lasiet klienta žurnālu vietā, kur tiek pieņemts lēmums par maršrutu.

Pierādiet, ka maršruts trūkst, nevis tikai ir salūzis

Sāciet ar pierādījumu, ka maršruts trūkst, nevis ir salūzis. Linux sistēmā ip route show dev tun0 uzskaita, ko klients instalējis tuneļa ierīcē. Windows sistēmā route print vai Get-NetRoute parāda to pašu tabulas formā.

Maršruts, kas pastāv, bet nepārsūta datplūsmu, ir cita problēma. Tas pārvieto izmeklēšanu uz pārsūtīšanas un ugunsmūra noteikumiem, nevis uz maršruta instalēšanu.

Laiks: pievienošana notika pirms ierīces pastāvēšanas

Klients analizē servera PUSH_REPLY pēc tam, kad vadības kanāls ir uzcēlies un kad tas ir konfigurējis saskarni. Tikai tad tas pieskaras maršrutēšanas tabulai, izmantojot jebkuru platformas sniegto mehānismu. Linux iet caur netlink; Windows izmanto API, kam vajadzīgs paaugstināts marķieris. Skripts vai klients, kas pievieno maršrutus tiklīdz nolasa konfigurāciju, var darboties pirms TUN/TAP ierīces pastāvēšanas, un kodols noraida pievienošanu.

Tās pašas sacensības izskaidro, kāpēc ar roku rakstīts maršruts darbojas, bet automātiskais ne: kad jūs to rakstāt, saskarne jau ir uzcēlusies.

route-delay pastāv tieši šim gadījumam, un route-up nosauc skriptu, kas darbojas pēc saskarnes un maršrutu konfigurēšanas. Maršrutus, kas atkarīgi no tuneļa adreses, lieciet šajā āķī, nevis agrīnā posmā.

Tiesības: kas drīkst mainīt tabulu

Windows maršrutēšanas tabulas maiņai vajadzīgs paaugstināts marķieris. Standarta lietotāja palaists GUI var iestatīt adaptera adresi caur pakalpojumu un tomēr nespēt pievienot maršrutu. Tad žurnāls rāda piekļuve liegta tipa kļūdu, nevis trūkstošu virzīšanu.

GUI palaišana kā administratoram vai pakalpojumā balstīta klienta lietošana maina šo rezultātu. Plānots uzdevums, kas palaiž klientu bez vajadzīgā marķiera, to nemaina.

Pirms kaut ko mainīt, pārbaudiet, ar kuru kontu klients patiešām darbojas. Versija un pakalpojuma režīms nosaka, kuri cēloņi vispār ir iespējami, tāpēc pierakstiet abus blakus maršruta izvadei.

Politika: virzītos maršrutus var apzināti izmest

route-nopull liek klientam ignorēt servera virzītos maršrutus, tostarp virzīto noklusējuma maršrutu, kamēr tuneļa adrese joprojām tiek pieņemta. Virzītās DNS un DHCP opcijas tiek izmestas ar to pašu direktīvu. Šāds klients nav bojāts; tas savā konfigurācijā sagaida skaidras maršruta rindas.

route-noexec ir cita vadība: tā pilnībā aptur klientu no maršruta izmaiņu izpildes. Topoloģija, ko klients nevar kartēt, var dot līdzīgu rezultātu, un maršruts tiek reģistrēts kā noraidīts, nevis pievienots. Lasiet žurnāla rindu, kas ziņo lēmumu, tā vietā lai minētu, kurš no trim gadījumiem attiecas. Pēc tam pārbaudiet faktisko profilu, jo importētājs vai pārvaldības rīks var pievienot opcijas, ko lietotājs nekad nav rediģējis.

Profils, kas teksta redaktorā izskatās tīrs, joprojām var saturēt pievienotu direktīvu izpildes laikā.

Salīdziniet virzīšanas sarakstu ar tabulu

Pēc savienošanās nolieciet servera virzīšanas sarakstu blakus klienta tabulai. Linux sistēmā tas ir ip route show dev tun0; Windows sistēmā route print vai Get-NetRoute. Ja maršruts trūkst, vispirms izlabojiet instalāciju. Ja tas ir un datplūsma neizdodas, pārejiet pie pārsūtīšanas un ugunsmūra politikas.

Pierakstiet klienta versiju, kontu, ar kuru tas darbojas, un to, vai tas ir balstīts pakalpojumā. Šie trīs fakti pasaka nākamajam cilvēkam, kuri cēloņi tika izslēgti.