Du OpenVPN klientai viename Linux šliuze: padalykite politiką

Du OpenVPN demonai gali abu pranešti apie sėkmingą tunelį, o šliuzas kiekvieną klientą siunčia tuo pačiu. Niekas rankos paspaudime nesprendžia, kurį tunelį klientas naudoja; tai sprendžia branduolys, paketą po paketo, eidamas per politikos taisykles ir po to per lentelę, kurią kiekviena taisyklė įvardija. Pažiūrėjus taip, konfigūracija nustoja būti apie OpenVPN parinktis ir tampa maršrutizavimo matrica su dviem savininkais.

Sprendžia branduolys, o ne demonas

Persiunčiamas paketas patenka į LAN sąsają, o maršrutizavimo kodas vertina taisyklių sąrašą prioriteto tvarka. Pirmoji taisyklė, kurios selektorius sutampa, įvardija lentelę, o tos lentelės maršrutai parenka išvesties įrenginį. Jei lentelėje nėra atitinkančio maršruto, paieška tęsiasi prie kitos taisyklės, ir būtent ši detalė lemia, kad pusiau baigta konfigūracija žlunga tyliai, o ne garsiai.

Tunelio procesas tame ėjime neturi žodžio. Jis sukuria sąsają ir gali įdiegti maršrutus, bet ar konkretaus kliento paketas patenka į tą sąsają, visiškai priklauso nuo lentelės, į kurią jis buvo išsiųstas. Todėl du tuneliai su identiškais importuotais maršrutais konkuruoja, o paskutinis rašęs laimi visiems. Štai kodėl konfigūracija gali atrodyti subalansuota failuose ir vis tiek siųsti visus klientus per vieną demoną.

Duokite kiekvienam egzemplioriui savo išteklių rinkinį

Pradėkite nuo pavadinimų, nes pakartotinai naudojami pavadinimai yra kelias, kuriuo du egzemplioriai atsitiktinai pradeda dalytis būsena. Priskirkite atskirus tunelio įrenginius, atskirus konfigūracijos failus, atskirus prisijungimo duomenis ir atskirus tarnybos vienetus. Užrašykite kiekvieno egzemplioriaus išorinį galinį tašką ir tunelio adresą į tą pačią lentelę kaip politikos matricą, kad vėlesnis pakeitimas turėtų vieną vietą, kur pažiūrėti.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull laiko serverio stumiamus maršrutus už vietinės lentelės ribų, ir būtent to norite, kai politikos lentelės turi būti aiškios. Ar konkretus serveris taip pat stumia redirect-gateway parinktį, ir ar jūsų kliento versija palaiko filtro formą, verta tikrinti vadove, o ne daryti prielaidas.

Parašykite matricą: šaltinis, lentelė, įrenginys

Kiekvienai klientų grupei pridėkite taisyklę, kuri parenka lentelę pagal šaltinio adresą, tada įdėkite numatytą kelią į tą lentelę:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

Lentelei reikia paskirties maršrutų, kuriuos grupė turėtų turėti, ir bet kokių vietinių ar valdymo išimčių, kurios palaiko šliuzą naudojamą. Lentelė, kurioje yra tik numatytasis maršrutas, yra viso tunelio politika tai grupei, ir tai gali būti visiškai teisinga, bet tai turėtų būti sprendimas, o ne praleidimas.

Paties tunelio transportas nėra klientų grupėje

Kiekvieno demono šifruoti paketai atsiranda pačiame šliuze, adresuoti išoriniam partneriui. Taisyklė, kuri sutampa tik su kliento šaltinio prefiksu, palieka tuos paketus ramybėje, todėl šaltiniu apribotos taisyklės saugesnės už taisykles, kurios sutampa su viskuo. Taisyklė be selektoriaus gali pagauti paties tunelio transportą ir nusiųsti jį atgal per tunelį, o tada ryšys žlunga taip, kad atrodo kaip tiekėjo problema.

Laikykite vietinę valdymo sesiją ir apatinio sluoksnio kelią aiškiai už politikos lentelių. Užrašykite tas išimtis prie matricos; jos yra dizaino dalis, o ne apėjimas, kurį reikia iš naujo atrasti per incidentą.

Kelio pasirinkimas jo neleidžia

Leidimas persiųsti yra antras sprendimas, priimamas vėliau kelyje. Ugniasienės taisyklė, priimanti paketus, išeinančius per antrą tunelį, nepriverčia maršrutizavimo kodo jo pasirinkti, o teisinga lentelė nesuteikia leidimo persiųsti. Turi būti abu, o testas, įrodantis tik vieną, suklaidins jus dėl kito. Kai viena grupė veikia, o kita ne, patikrinkite šiuos du žingsnius atskirai, o ne perrašykite lenteles.

Šaltinio vertimas yra trečias sprendimas, ir jis turėtų būti apribotas šaltinio grupe ir tunelio įrenginiu, kuris jį tikrai neša. Pridėkite atskirą grandinę dviem egzemplioriams, o ne išvalykite postrouting grandinę, nes nesusijusios tarnybos gali ten turėti įrašų, o išvalymas juos tyliai pašalina.

Kas nutinka, kai vienas tunelis krinta

Nuspręskite gedimo elgseną iš anksto. Kai tunelio lentelė praranda savo maršrutą, paieška nukrenta prie kitos taisyklės, ir grupės srautas tęsiasi per kitą tunelį ar įprastą viršutinę jungtį be jokios klaidos. Jei tai nepriimtina, pridėkite baigiamąją taisyklę su mažesniu prioriteto numeriu, kuri tam šaltiniui grąžina nepasiekiamą rezultatą, kad nuostolis būtų matomas, o ne sugertas.

Siųskite naują užklausą iš kiekvienos šaltinio grupės ir užrašykite keturis faktus: pasirinktą lentelę, išvesties įrenginį, išverstą šaltinį ir ar atsakymas grįžo tuo pačiu keliu. Tada nuleiskite vieną tunelį ir pakartokite. Du TUN įrenginiai sąsajų sąraše įrodo, kad abu demonai startavo; jie nieko nesako apie tai, kurį naudojo konkretus klientas. Antrasis paleidimas, kai vieno tunelio nebėra, ir yra tas, kuris parodo, ar jūsų atsarginė taisyklė daro tai, ko ketinote.