Vienas OpenVPN mazgas, trys LAN tinklai: adresų planas ir iroute failai

Trys privatūs LAN tinklai gali susitikti viename mazge, nė vienai vietai nežinant kitų vidinės struktūros, ir visas dizainas remiasi keturiais trumpais konfigūracijos sprendimais. Jį veikti leidžia ne egzotiška protokolo funkcija, o adresų planas, kurio niekam nereikia spėlioti, ir klientui skirti maršrutai, kurie mazgui nurodo, kuri šaka valdo kurį prefiksą. Suklydus bent viename iš jų, tunelis vis tiek pakyla, ir būtent tai daro gedimą klaidinančiu.

Atlikite veiksmus iš eilės. Kiekvienas priklauso nuo ankstesnio veiksmo plano, ir nė vienam nereikia naujos sertifikatų institucijos.

Pradėkite nuo plano, kurio niekam nereikia spėlioti

Prieš liesdami konfigūracijos failą, užrašykite keturis nepersidengiančius prefiksus: paties mazgo LAN, kiekvienos šakos LAN ir baseiną, skiriamą klajojantiems klientams. Nepersidengimas yra tai, kas visa kita išlaiko paprasta, nes persidengiantys diapazonai maršruto parinkimą paverčia ilgiausio atitikimo galvosūkiu, kurio nepataisys jokia kliento lygio konfigūracija. Tada patikrinkite, kuris įrenginys yra kiekvieno LAN numatytasis šliuzas, nes šakos maršrutizatoriui, kuris nėra savo LAN šliuzas, nuotolinius maršrutus reikia įdiegti visai kitur. Galiausiai nustatykite autentifikuotus pavadinimus, identifikuojančius kiekvieną šaką, nes būtent tie pavadinimai yra raktai, pagal kuriuos ieškoma kliento failų.

Pavyzdinis planas baseiną laiko gerokai atokiau nuo trijų LAN tinklų. Jūsų bus kitoks, ir vienintelė griežta taisyklė yra ta, kad jokie du diapazonai nesipersidengtų.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Pasakykite mazgo branduoliui, kur yra šakos

Mazgui reikia dviejų informacijos dalių kiekvienai šakai: branduolio maršruto, kuris siunčia prefiksą į tunelio įrenginį, ir iroute įrašo, kuris OpenVPN procesui nurodo, kuris klientas jį valdo. Vien branduolio maršrutas pristato paketus į tunelį ir ten sustoja, nes demonas dar turi nuspręsti, kuris peer turi juos gauti. Vien iroute įrašas palieka tuos paketus branduolyje be jokio maršruto. Abi eilutės priklauso konfigūracijai, kurią demonas iš tikrųjų įkelia, ir tai verta patikrinti prieš derinant ką nors kita.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

Laikykite client-to-client išjungtą, kai branduolys turi būti taisyklių vykdymo vieta. Ši parinktis perduoda srautą tarp peer demono viduje, kas patogu ir kartu reiškia, kad jūsų perdavimo taisyklės srauto niekada nemato. Viskas toliau remiasi prielaida, kad branduolys mato kiekvieną paketą tarp šakų.

Duokite kiekvienai šakai reikiamus maršrutus

Kiekvienai šakai reikia maršrutų į kitas šakas ir į mazgo LAN, o į savo prijungtą LAN jai maršruto nereikia. Nuotolinius prefiksus stumkite iš mazgo, o ne įklijuokite į kiekvieną maršrutizatorių, taip ketvirta vieta vėliau reikš vieną naują kliento failą vietoj keturių pakeitimų. Kliento faile taip pat yra iroute eilutė, kuri nuosavybę ir skelbimą laiko vienoje vietoje. Padarykite katalogą ir jo failus skaitomus pagal serverio teisių modelį, kitaip paieška nepavyksta be pranešimo.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

Ketvirta vieta vadovaujasi tuo pačiu šablonu: atskiras autentifikuotas pavadinimas, valdomas prefiksas, mazgo branduolio maršrutas, iroute įrašas ir skelbimai tik toms vietoms, kurioms leidžiama ją pasiekti.

Išbandykite abiem kryptimis, prieš skelbdami, kad baigta

Įjunkite IPv4 peradresavimą visuose trijuose maršrutizatoriuose, tada patikrinkite, ar ugniasienė leidžia numatytus srautus abiem kryptimis, nes vienos krypties testas su sulaužytu grįžimo keliu praeina dažniau, nei kas nors tikisi. Tarp vietų nereikia šaltinio adreso vertimo, ir būtent originalaus šaltinio išsaugojimas leidžia kiekvienai šakai taikyti savo politiką užklausai.

Išbandykite iš vienos šakos LAN pagrindinio kompiuterio į kitos šakos paslaugą, tada apverskite kryptį, tada išbandykite iš šakos į mazgo LAN. Šie trys rezultatai yra skirtingi įrodymai, ir nė vienas jų neimplikuoja kitų. Jei šakos maršrutizatorius nėra savo LAN numatytasis šliuzas, įdiekite nuotolinius prefiksus tikrajame šliuze ir įtraukite baseiną, kai tunelio klientams reikia pradėti ryšius į tą LAN.

Užrašykite planą, kliento failus ir ugniasienės taisykles kaip vieną dokumentą, nes kita vietos plėtra bus vertinama pagal juos.

Dizainas laikosi kartu, nes kiekvienas sluoksnis turi vieną užduotį: planas išlaiko prefiksus unikalius, branduolio maršrutas perkelia paketus, iroute įvardija savininką, o ugniasienė nusprendžia, kas leidžiama. Kai kas nors sugenda, tas sąrašas yra ir tikrinimo tvarka.