Kur OpenVPN priklauso maršrutas: kliente ar serveryje?
Nuogas maršrutas serverio konfigūracijoje keičia serverį, o ne klientą. Pasirinkite kliento failą, visuotinį push arba push vienam klientui ir patikrinkite, kas atkeliavo.
Pridedate route 10.60.0.0 255.255.255.0 prie serverio konfigūracijos, paleidžiate iš naujo, vėl prijungiate nešiojamąjį kompiuterį, o potinklis vis dar nepasiekiamas iš to nešiojamojo kompiuterio. Eilutė buvo priimta, paslauga paleista švariai, o žurnale niekas neatrodo neteisingai. Tai, kas nutiko, yra maršruto įdiegimas tame kompiuteryje, kurį redagavote: tinklų sietuvas dabar mano galintis pasiekti tą prefiksą, o klientui nieko nebuvo pasakyta. Vieta yra visas klausimas, ir yra keturios vietos, kur ta pati eilutė gali gyventi.
Keturios vietos ir kas kurią gauna
Maršrutą galima pridėti paties kliento konfigūracija, pasiūlyti kiekvienam klientui per visuotinį push, pasiūlyti vienam klientui per klientui skirtą failą arba įrašyti į paties serverio maršruto kontekstą.
Šie keturi atvejai naudoja beveik identišką sintaksę ir duoda visiškai skirtingus rezultatus. Pirmieji trys veikia tai, ką klientas siunčia į tunelį; ketvirtasis veikia tai, kaip serveris pasiekia tinklą, kas naudinga, kai pačiam serveriui reikia kelio, ir žalinga, kai tai supainiojama su paskirstymu.
Nuspręskite, kurio iš keturių norite, prieš rašydami eilutę, tada patvirtinkite gavėją.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Kodėl nuogas serverio maršrutas nustebina žmones
Serverio konfigūracija yra pirmoji vieta, į kurią žiūri administratoriai, o maršruto direktyva ten skaitoma kaip teiginys apie VPN tinklą. Taip nėra. OpenVPN ją traktuoja kaip vietinį maršruto įdiegimą kompiuteryje, kuriame veikia demonas, o tai lygiai tokio paties tipo pakeitimas, kokį padarytumėte su ip route ir paskui pamirštumėte.
Paskirstymui reikia, kad maršrutas būtų išstumtas push, o push reikia, kad klientas jį patrauktų. Klientas, paleistas su išjungtomis patrauktomis parinktimis, visiškai nepaiso pasiūlymo. Prieš perrašydami serverio failą patikrinkite abu šio rankos paspaudimo galus, nes serverio žurnalas nesiskųs: iš jo pusės pasiūlymas buvo išsiųstas. Priimtas maršrutas taip pat įsigalioja tik kitame prisijungime, niekada sesijoje, kurioje jau esate.
Kai pamatysite abu kaip atskirus veiksmus, gedimas nustoja būti paslaptingas: serveris pasiekia prefiksą, klientas ne, ir abu teiginiai yra teisingi vienu metu.
Klientui skirti failai ir tapatybė, kurią jie atitinka
Klientui skirtas failas pavadinamas pagal tapatybę, kurią serveris autentifikavo, o pagal nutylėjimą tai yra sertifikato bendrasis vardas. Draugiškas ryšio pavadinimas darbalaukio kliente nėra ta reikšmė, o neatitikimas sukuria failą, kuris niekada nėra skaitomas.
Patikrinkite katalogą, kurį serveris iš tikrųjų naudoja, tada patvirtinkite, kad failo pavadinimas tiksliai atitinka autentifikuotą tapatybę, įskaitant didžiąsias ir mažąsias raides.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Tame faile maršrutas vis tiek turi būti išstumtas push, nes kliento kontekstas yra parinkčių rinkinys, taikomas to kliento sesijai, o ne vietinė maršruto lentelė. Nuogas maršrutas ten turi tą pačią problemą kaip nuogas maršrutas visuotiniame faile.
Paties kliento failas ir įrankis, kuris jį valdo
Maršrutas, įdėtas į kliento konfigūraciją, įdiegiamas, kai tas klientas prisijungia, ir pašalinamas, kai atsijungia, o tai yra teisingas statinės paskirties gyvavimo ciklas.
Jei profilį valdo tinklo tvarkyklė, ji gali vieną kartą importuoti tas parinktis ir tada laikyti savo kopiją. Vėliau redaguoti atsisiųstą failą nieko nekeičia, o tai dažna priežastis "maršrutas yra, bet netaikomas".
Tikrinkite aktyvų profilį, o ne failą, kurį atsisiuntėte, ir tikrinkite importuotus nustatymus, kuriuos rodo tvarkyklė. Tada prisijunkite ir paklauskite sistemos, kokį kelią naudoja konkretus adresas, o ne manykite, kad tunelis laimėjo todėl, kad maršrutas buvo tekstiniame faile.
Patikrinkite kliente, tada patikrinkite grįžimo kelią
Klauskite paties kliento maršruto lentelės apie paskirties vietą, o ne serverio. Vieno mazgo paieškos prefikso viduje pakanka parodyti sąsają ir kitą šuolį, kurie bus naudojami.
ip route get 10.60.0.10Jei paieška nukreipia į tunelį, paskirstymas veikė, o likusi problema yra kitur. Jei ji nukreipia į numatytąjį tinklų sietuvą, maršrutas nebuvo įdiegtas, buvo filtruotas kliento pusės parinkties arba priklauso profiliui, kurio klientas nenaudoja.
Tarkime, paskirstymas veikė, o vis tiek niekas neatsako: tada patikrinkite persiuntimą tinklų sietuvo, priešingos pusės grįžimo maršrutą ir bet kokią užkardą tarp jų. Maršrutas pasirenka kelią, jis nesuteikia prieigos.