OpenVPN iroute ir branduolio maršrutas: kurio trūksta?

10.77.20.0/24 skirtas paketas OpenVPN serveryje priima du atskirus sprendimus: operacinė sistema turi jį perduoti VPN sąsajai, o OpenVPN turi žinoti, kuris prisijungęs klientas valdo tą prefiksą. Trūkstant branduolio maršruto, jis numetamas prieš tunelį, o trūkstant partnerio maršruto – po jo. Abi gedimai iš tolimo LAN atrodo vienodai, o norint nustatyti, kuris iš jų yra pas jus, reikia po vieną komandą kiekvienoje pusėje.

Klasikiniame vartotojo erdvės duomenų kelyje branduolio maršrutas įveda paketą į tunelio procesą, o iroute pasako tam procesui, kuris partneris turi jį gauti. Nė vienas nepakeičia kito, o konfigūracija su tik vienu iš jų atrodys pagrįsta iki pirmojo ping.

Du sprendimai, o ne vienas maršrutas

Įsivaizduokite ryšį tarp aikštelių, kuriame 10.77.20.0/24 yra už vieno kliento. Serverio branduolio maršrutas, pavyzdžiui ip route add 10.77.20.0/24 dev tun0, siunčia atitinkančius paketus tunelio įrenginiui. Tada OpenVPN pasižiūri į savo vidinę lentelę, sudarytą iš iroute įrašų kliento konfigūracijos kataloge, kad nuspręstų, kuri partnerio jungtis juos gaus. Be branduolio maršruto paketas niekada nepasiekia proceso, o be partnerio maršruto jis pasiekia procesą ir niekur nukeliauja.

Tą padalijimą lengva pamiršti, nes viena maršruto eilutė kliento profilyje gali atrodyti atliekanti abu darbus. Neatlieka: maršruto stūmimas pasako klientams, ką siųsti per tunelį, o iroute pasako serveriui, kam priklauso adresų diapazonas už kliento. Jie gyvena skirtinguose failuose, juos skaito skirtingos pusės ir jie nepavyksta priešingomis kryptimis.

Kur priklauso iroute ir ką jis sako

Įrašas patenka į atskirą kliento failą, pavadintą pagal kliento common_name, kataloge client-config-dir, kaip iroute 10.77.20.0/24. Failo vardo sutapimas nėra kosmetinis: OpenVPN ieško autentifikuotos tapatybės ir skaito failą būtent tuo vardu, todėl failas pavadinimu site-a veikia tik klientui, kurio bendras vardas yra site-a. Pridėkite ccd-exclusive, jei klientai be tokio failo turi būti visiškai atmetami, o tai yra teisingas nustatymas, kai kiekvienas klientas yra aikštelės šliuzas. Laikykite po vieną failą kiekvienam šliuzui ir pavadinkite jį sertifikato subjekto, kurį iš tikrųjų išduodate, vardu.

Išbandykite įrašą iš serverio, prieš kaltindami tolimą LAN. Būsenos failas išvardija prisijungusius klientus su jų bendrais vardais, o serveris, veikiantis su --verb 4, registruoja iroute įdiegimą tuo metu, kai partneris prisijungia. Jei prisijungiant nieko nepasirodo, failas yra netinkamame kataloge arba nurodo neteisingą tapatybę.

Spąstai: failas yra, tapatybė neteisinga

Teisingai atrodantis iroute, prikabintas prie netinkamo partnerio, praranda daugiau laiko nei trūkstamas failas, nes diske viskas atrodo teisingai. Sertifikatų pervadinimas, pasikartojantys bendri vardai ir efektyvią tapatybę keičiantis username-as-common-name visa tai sukuria. Patikrinkite, kokią tapatybę serveris autentifikavo, o ne kokios tikėjotės: būsenos išvestis yra autoritetinga, o failo vardas tėra paieškos raktas.

Maršrutas gali pergyventi savo savininką. Statiniai maršrutai ir iroute įrašai aprašo prefiksą, o ne prieinamumo garantiją, todėl srautas gali toliau būti nukreipiamas į partnerį, kuris šiuo metu yra atjungtas.

Užbaikite kelią už partnerio

Partnerio valdymas yra kelio vidurys, o ne pabaiga. Klientas turi persiųsti paketus iš tunelio į savo LAN, o tai reiškia, kad tame hoste įjungtas IP persiuntimas ir ugniasienės taisyklė leidžia praėjimą. Tolimo LAN hostams reikia grįžimo kelio tunelio adresui: arba maršruto, nukreipto atgal į šliuzą, arba sąmoningai suprojektuoto NAT kliento pusėje. Patvirtinkite persiuntimo nustatymą kliente su sysctl net.ipv4.ip_forward, o ne manydami, kad galioja distribucijos numatytoji reikšmė.

Jei kiti VPN klientai turi pasiekti tą potinklį, išdėstymas vėl didėja: serveriui reikia client-to-client, o tie klientai turi nukreipti prefiksą per tunelį. Niekas iš to neišplaukia iš paties serverio maršrutų lentelės.

Patikrinkite vieną paskirties tašką iš tikro šaltinio, o ne iš paties serverio. Ping iš nesusijusio LAN hosto į hostą už kliento išbando grįžimo kelią, persiuntimo taisyklę ir partnerio valdymą vienu judesiu, o sėkmingas rankos paspaudimas įrodo tik tapatybę. Tada atjunkite valdantį partnerį ir užrašykite, ką daro maršrutas, nes tas atsakymas yra jūsų gedimo režimas.