OpenVPN vis dar stumia senus maršrutus? Patikrinkite, ką jis įkėlė

Pridedate maršrutą, iš naujo paleidžiate paslaugą, prisijungiate iš naujo, o kliento lentelė atrodo visiškai kaip anksčiau. Gali būti teisingi du skirtingi dalykai: serveris neįkėlė jūsų pakeitimo arba klientas neįdiegė to, ką gavo. Bendra jie turi tik simptomą, todėl pirmas žingsnis yra išsiaiškinti, kuris iš dviejų atvejų pas jus.

Toliau pateiktas palyginimas eina nuo proceso į išorę, nes procesas yra vienintelė institucija, žinanti, kuris failas galioja.

Failas, kurį redagavote, ir failas, kurį skaito procesas

Pradėkite nuo unit ir jo sukurto komandų eilutės. systemd hoste systemctl cat openvpn@server atspausdina ExecStart eilutę, o instancijos unit paprastai išveda savo konfigūracijos kelią iš instancijos pavadinimo, todėl demonas, paleistas kaip openvpn@office, skaito kitą failą nei paleistas kaip openvpn@server. Palyginkite tai su veikiančio proceso argv. Konfigūracijos valdymo įrankis prideda dar vieną būdą prarasti pakeitimą: jis gali įrašyti teisingą failą į vietą, kurios unit niekada nemini, ir tada sėkmingas diegimas atrodo kaip niekas.

Laiko žymos tai greitai išsprendžia: jei failas yra naujesnis už proceso paleidimo laiką, procesas negalėjo jo perskaityti. Maršrutizatoriaus programinė aparatinė įranga prideda trečią atvejį, nes daug modelių laiko nustatymus flash atmintyje ir paleidimo metu iš naujo surenka konfigūraciją, o tai daro failo redagavimą diske visiškai netinkamu sluoksniu.

Ką siunčia serveris ir ką įdiegia klientas

Stumiamas maršrutas turi praeiti du filtrus. Serveryje jis turi būti įkelta konfigūracija, o ne komentuotame bloke arba klientui skirtame faile, kurio pavadinimas nesutampa. Kliente pull turi būti įjungtas, ir joks pull-filter neturi išmesti šios parinkties. Prisijunkite su verbosity 4 ir perskaitykite stumiamas parinktis, apie kurias praneša klientas: jei maršrutas yra tame sąraše, serveris atliko savo darbą, o klientas pasirenka jo neįdiegti.

Klientui skirti failai yra dažnas painiavos šaltinis. Failas, pavadintas pagal sertifikato common name, siunčia parinktis tik tam klientui, o vieno simbolio neatitikimas tyliai sustabdo siuntimą, be klaidos abiejose pusėse. Serveris įrašo common name, kurį matė prisijungdamas, todėl palyginkite tą reikšmę su failo pavadinimu, o ne su tuo, ką manote esant kliento vardu.

Stumiamas priešdėlis ir grįžtamasis maršrutas yra skirtingos problemos

Klientas, kuris sąmoningai nepaiso redirect-gateway, kad išlaikytų savo vietinį interneto kelią, sukuria antrą, nesusijusią spragą. Serverio zondai pasiekia tunelio adresą, bet atsakymai niekada neateina, nes atsakymas, adresuotas serverio tunelio IP, maršrutizuojamas per įprastą kliento numatytąją tarnybinę stotį. Čia kaltas ne stumiamas potinklio maršrutas; trūksta maršruto, kuris serverio tunelio tinklo srautą siųstų atgal per tunelio įrenginį.

To maršruto pridėjimas kliente sutvarko atsakymus į serverio inicijuotus zondus. Jis nepakeičia stumiamo potinklio maršruto, ir atvirkščiai taip pat, nes abu apibūdina priešingas judėjimo kryptis.

Palyginkite lenteles abiejuose galuose

Po bet kokio pakeitimo prisijunkite iš naujo ir perskaitykite kliento lentelę dėl stumiamo priešdėlio ir tunelio įrenginio. Tada išbandykite abiem kryptimis: nuo kliento iki pagrindinio kompiuterio stumiamame potinklyje ir iš to kompiuterio atgal į klientą. Maršrutas, kuris egzistuoja, bet neperduoda srauto, reiškia vieną iš trijų: tolimoji pusė nepersiunčia, ugniasienė meta srautą, arba atsakymas neturi kelio atgal.

Laikykite tris identifikatorius kartu: konfigūracijos kelią, unit ar instancijos pavadinimą ir kliento tapatybę, su kuria testavote.

Šie trys paverčia kitą atvejį penkių minučių patikra, o ne dar vienu tyrimu, ir būtent jų reikia kolegai, kai tunelis tampa kažkieno kito problema.

Maršruto problema, kuri išlieka po paleidimo iš naujo, dažnai visai nėra maršrutizavimo problema; gedimas yra aukščiau lentelės, kurią nuolat skaitote.