Een OpenVPN-hub, drie LAN's: adresplan en iroute-lêers

Drie privaat LAN's kan by een hub bymekaarkom sonder dat enige werf die ander se binneste leer ken, en die hele ontwerp berus op vier kort konfigurasiebesluite. Wat dit laat werk, is nie 'n eksotiese protokolkenmerk nie, maar 'n adresplan wat niemand hoef te raai nie, plus per-kliënt-roetes wat vir die hub sê watter tak watter voorvoegsel besit. Kry enigiets daarvan verkeerd en die tonnel kom steeds op, en dit is juis wat die fout verwarrend maak.

Werk die stappe in volgorde deur. Elkeen hang af van die plan van die vorige stap, en nie een daarvan vereis 'n nuwe sertifikaatowerheid nie.

Begin met 'n plan wat niemand hoef te raai nie

Skryf vier onsamehangende voorvoegsels neer voordat jy aan 'n konfigurasielêer raak: die hub se eie LAN, elke tak se LAN, en die poel wat aan swerwende kliënte gegee word. Onsamehangendheid is wat alles anders eenvoudig hou, want oorvleuelende reekse verander roetering in 'n langste-passing-raaisel wat geen hoeveelheid per-kliënt-konfigurasie kan herstel nie. Bevestig dan watter masjien die verstekpoortwag vir elke LAN is, want 'n takroeteerder wat nie sy LAN se poortwag is nie, het die afgeleë roetes heel elders nodig. Bepaal laastens die geauthentiseerde name wat elke tak identifiseer, want daardie name is die sleutels waarmee die per-kliënt-lêers opgesoek word.

'n Illustratiewe plan hou die poel ver weg van die drie LAN's. Jou s'n sal verskil, en die enigste harde reël is dat geen twee reekse oorvleuel nie.

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

Vertel die hub se kern waar die takke is

Die hub het twee stukke inligting per tak nodig: 'n kernroete wat die voorvoegsel in die tonneltoestel instuur, en 'n iroute inskrywing wat vir die OpenVPN proses sê watter kliënt dit besit. Die kernroete alleen lewer pakkette aan die tonnel af en stop daar, want die daemon moet steeds besluit watter eweknie hulle moet ontvang. Die iroute inskrywing alleen laat daardie pakkette in die kern sonder 'n roete om te volg. Albei reëls hoort in die konfigurasie wat die daemon werklik laai, wat die moeite werd is om te verifieer voordat jy enigiets anders ontfout.

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

Laat kliënt-tot-kliënt af wanneer die kern die handhawingspunt moet wees. Daardie opsie herlei eweknieverkeer binne die daemon, wat gerieflik is en ook beteken dat jou deurstuurreëls nooit die vloei sien nie. Alles hieronder aanvaar dat die kern elke tak-tot-tak-pakket sien.

Gee elke tak die roetes wat dit nodig het

Elke tak het roetes nodig vir die ander takke en vir die hub se LAN, en dit het nie een vir sy eie gekoppelde LAN nodig nie. Stuur die afgeleë voorvoegsels van die hub af eerder as om hulle in elke roeteerder te plak, sodat 'n vierde werf later een nuwe per-kliënt-lêer beteken in plaas van vier wysigings. Die per-kliënt-lêer dra ook die iroute lyn, wat eienaarskap en aankondiging op dieselfde plek hou. Maak die gids en sy lêers leesbaar onder die bediener se voorregmodel, of die opsoek misluk sonder 'n boodskap.

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

'n Vierde werf volg dieselfde patroon: 'n afsonderlike geauthentiseerde naam, 'n voorvoegsel wat besit word, 'n hub-kernroete, 'n iroute inskrywing, en aankondigings slegs aan die werwe wat toegelaat word om dit te bereik.

Toets in albei rigtings voordat jy dit klaar noem

Aktiveer IPv4-deurstuur op al drie roeteerders en bevestig dan dat die firewall die beoogde vloeie in albei rigtings toelaat, want 'n eenrigtingtoets slaag met 'n stukkende terugpad meer dikwels as wat enigiemand verwag. Geen bronvertaling is tussen werwe nodig nie, en dit is die behoud van die oorspronklike bron wat elke tak toelaat om sy eie beleid op 'n versoek toe te pas.

Toets van 'n gasheer op een tak se LAN na 'n diens op 'n ander, draai dan die rigting om, en toets dan van 'n tak na die hub se LAN. Daardie drie uitslae is verskillende bewyse, en nie een daarvan impliseer die ander nie. As 'n takroeteerder nie sy LAN se verstekpoortwag is nie, installeer die afgeleë voorvoegsels op die werklike poortwag en sluit ook die poel in wanneer tonnelkliënte verbindings na daardie LAN moet begin.

Teken die plan, die per-kliënt-lêers en die firewall-reëls as een dokument aan, want die volgende werfbyvoeging sal daaraan gemeet word.

Die ontwerp hou saam omdat elke laag een taak het: die plan hou voorvoegsels uniek, die kernroete skuif pakkette, die iroute name die eienaar, en die firewall besluit wat toegelaat word. Wanneer iets breek, is daardie lys ook die volgorde waarin om dit na te gaan.