Jeden hub OpenVPN, tri siete LAN: plán adries a súbory iroute
Štyri disjunktné prefixy, jedna jadrová trasa na pobočku, jeden iroute na vlastníka. Pracovný postup pre hub s tromi lokalitami, ktorý pri nesprávnom názve zlyhá potichu.
Tri súkromné siete LAN sa môžu stretnúť na jednom hube bez toho, aby niektorá lokalita musela poznať vnútornú štruktúru ostatných, a celý návrh stojí na štyroch krátkych konfiguračných rozhodnutiach. Nepomáha mu exotická funkcia protokolu, ale plán adries, ktorý nikto nemusí hádať, plus trasy pre jednotlivých klientov, ktoré hubu povedia, ktorá pobočka vlastní ktorý prefix. Ak je jedno z toho nesprávne, tunel sa aj tak zdvihne, a práve to robí poruchu mätúcou.
Prejdite krokmi v poradí. Každý závisí od plánu z predchádzajúceho kroku a žiadny nevyžaduje novú certifikačnú autoritu.
Začnite plánom, ktorý nikto nemusí hádať
Zapíšte štyri disjunktné prefixy skôr, než sa dotknete konfiguračného súboru: LAN samotného hubu, LAN každej pobočky a fond prideľovaný putujúcim klientom. Disjunktnosť je to, čo udržiava všetko ostatné jednoduché, pretože prekrývajúce sa rozsahy menia smerovanie na hádanku najdlhšej zhody, ktorú nespraví žiadna konfigurácia pre jednotlivých klientov. Potom overte, ktorý stroj je predvolená brána každej siete LAN, keďže smerovač pobočky, ktorý nie je bránou vlastnej siete, musí vzdialené trasy nainštalovať úplne inde. Nakoniec stanovte autentifikované názvy, ktoré identifikujú každú pobočku, pretože tieto názvy sú kľúčmi, podľa ktorých sa vyhľadávajú súbory pre jednotlivých klientov.
Ilustratívny plán drží fond ďaleko od troch sietí LAN. Váš bude iný a jediné tvrdé pravidlo je, že žiadne dva rozsahy sa neprekrývajú.
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/24Povedzte jadru hubu, kde sú pobočky
Hub potrebuje pre každú pobočku dve informácie: jadrovú trasu, ktorá posiela prefix do tunelového zariadenia, a záznam iroute, ktorý procesu OpenVPN povie, ktorý klient ho vlastní. Samotná jadrová trasa doručí pakety do tunela a tam sa zastaví, pretože démon ešte musí rozhodnúť, ktorý peer ich má prijať. Samotný záznam iroute nechá tieto pakety v jadre bez trasy, po ktorej by sa dalo ísť. Oba riadky patria ku konfigurácii, ktorú démon skutočne načíta, a to sa oplatí overiť pred ladením čohokoľvek iného.
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.0Nechajte client-to-client vypnuté, keď má byť jadro miestom presadzovania pravidiel. Táto možnosť preposiela prevádzku medzi peermi vnútri démona, čo je pohodlné a zároveň znamená, že vaše pravidlá preposielania tok nikdy nevidia. Všetko nižšie predpokladá, že jadro vidí každý paket medzi pobočkami.
Dajte každej pobočke trasy, ktoré potrebuje
Každá pobočka potrebuje trasy k ostatným pobočkám a k sieti LAN hubu a nepotrebuje trasu k vlastnej pripojenej sieti LAN. Vzdialené prefixy tlačte z hubu namiesto vkladania do každého smerovača, takže štvrtá lokalita neskôr znamená jeden nový súbor pre klienta namiesto štyroch úprav. Súbor pre klienta obsahuje aj riadok iroute, ktorý drží vlastníctvo a oznamovanie na jednom mieste. Nastavte adresár a jeho súbory čitateľné podľa modelu oprávnení servera, inak vyhľadávanie zlyhá bez správy.
# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"Štvrtá lokalita nasleduje rovnaký vzor: samostatný autentifikovaný názov, vlastnený prefix, jadrová trasa na hube, záznam iroute a oznámenia len lokalitám, ktoré ju smú dosiahnuť.
Otestujte v oboch smeroch, kým to vyhlásite za hotové
Zapnite preposielanie IPv4 na všetkých troch smerovačoch, potom potvrďte, že firewall povoľuje zamýšľané toky v oboch smeroch, pretože jednosmerný test prejde s pokazenou návratovou cestou častejšie, než ktokoľvek čaká. Medzi lokalitami nie je potrebný preklad zdrojovej adresy a práve zachovanie pôvodného zdroja umožňuje každej pobočke uplatniť vlastnú politiku na požiadavku.
Otestujte z hostiteľa v sieti LAN jednej pobočky k službe v inej, potom otočte smer a potom otestujte z pobočky do siete LAN hubu. Tieto tri výsledky sú rôzne dôkazy a žiadny neimplikuje ostatné. Ak smerovač pobočky nie je predvolená brána jeho siete LAN, nainštalujte vzdialené prefixy na skutočnú bránu a zahrňte aj fond, keď tuneloví klienti musia začať spojenia do tejto siete.
Zaznamenajte plán, súbory pre klientov a pravidlá firewallu ako jeden dokument, pretože ďalšie pridanie lokality sa bude posudzovať podľa nich.
Návrh drží pohromade, pretože každá vrstva má jednu úlohu: plán udržiava prefixy jedinečné, jadrová trasa presúva pakety, iroute pomenúva vlastníka a firewall rozhoduje, čo je povolené. Keď sa niečo pokazí, ten zoznam je aj poradím kontroly.