Ien OpenVPN-hub, trije LAN's: adresplan en iroute-bestannen

Trije partikuliere LAN's kinne by ien hub byinoar komme sûnder dat ien site it ynterne fan de oaren leart, en it hiele ûntwerp rêstet op fjouwer koarte konfiguraasjebesluten. Wat it wurkje lit is net in eksoatyske protokolfunksje, mar in adresplan dat nimmen riede hoecht, plus rûtes per klant dy't de hub fertelle hokker tûke hokker prefiks besit. Fersin jo jo yn ien fan beide, dan komt de tunnel dochs omheech, en dat is krekt wat de flater ferbjusterjend makket.

Wurkje de stappen yn folchoarder ôf. Elkenien hinget ôf fan it plan fan de foarige stap, en gjinien freget om in nije sertifikaasje-ynstânsje.

Begjin mei in plan dat nimmen riede hoecht

Skriuw fjouwer losse prefiksen op foardat jo in konfiguraasjebestân oanreitsje: it eigen LAN fan de hub, it LAN fan elke tûke en de pool dy't oan rûnjende klanten jûn wurdt. Losheid is wat al it oare ienfâldich hâldt, want oerlaapjende berikken meitsje fan rûtering in puzel fan langste oerienkomst dy't gjin konfiguraasje per klant reparearret. Befêstigje dan hokker masine de standertgateway foar elk LAN is, want in tûkerouter dy't net de gateway fan syn eigen LAN is, hat de fiere rûtes earne hiel oars nedich. Fêstigje ta beslút de autentisearre nammen dy't elke tûke identifisearje, want dy nammen binne de kaaien dêr't de bestannen per klant mei socht wurde.

In yllustratyf plan hâldt de pool fier fan 'e trije LAN's. Dyn sil oars wêze, en de iennige hurde regel is dat gjin twa berikken oerlaapje.

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

Fertel de kernel fan 'e hub wêr't de tûken binne

De hub hat twa stikken ynformaasje per tûke nedich: in kernelrûte dy't it prefiks it tunnelapparaat yn stjoert, en in iroute ynfier dy't de OpenVPN proseduere fertelt hokker klant it besit. De kernelrûte allinne leveret pakketten oan de tunnel en hâldt dêr op, want de daemon moat noch besluite hokker peareigen oft se krije moat. De iroute ynfier allinne lit dy pakketten yn 'e kernel sûnder rûte om te folgjen. Beide rigels hearre yn 'e konfiguraasje dy't de daemon wier lade, wat it wurdich is om te ferifiearjen foardat jo eat oars debugge.

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

Skeakelje klant-nei-klant út as de kernel it hanthavenjepunt wêze moat. Dy opsje stjoert ferkear tusken pearen troch binnen de daemon, wat handich is en ek betsjut dat jo trochstjoerregels de stream nea sjogge. Alles hjirûnder giet derfan út dat de kernel elk pakket tusken tûken sjocht.

Jou elke tûke de rûtes dy't er nedich hat

Elke tûke hat rûtes nedich foar de oare tûken en foar it LAN fan 'e hub, en hy hat gjin iene nedich foar syn eigen ferbûne LAN. Triuw de fiere prefiksen fan 'e hub ôf ynstee fan se yn elke router te plakken, sadat in fjirde site letter ien nij bestân per klant betsjut ynstee fan fjouwer bewurkings. It bestân per klant draacht ek de rigel iroute, dy't eigendom en oankundiging op itselde plak hâldt. Meitsje de map en syn bestannen lêsber ûnder it privileezjemodel fan 'e server, oars mislearret de syktocht sûnder berjocht.

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

In fjirde site folget itselde patroan: in aparte autentisearre namme, in eigendom prefiks, in kernelrûte yn 'e hub, in iroute ynfier, en oankundigingen allinne oan 'e sites dy't tastien binne om it te berikken.

Test yn beide rjochtingen foardat jo it klear neame

Skeakelje IPv4-trochstjoering yn op alle trije routers, befêstigje dan dat de firewall de bedoelde streams yn beide rjochtingen tastiet, want in ienrjochtingstest slagget mei in brutsen weromwei faker as immen ferwachtet. Tusken sites is gjin boarne-oersetting nedich, en it bewarjen fan 'e oarspronklike boarne is wat elke tûke tasteanlit syn eigen belied op in fersyk ta te passen.

Test fan in host op it LAN fan ien tûke nei in tsjinst op in oare, draai dan de rjochting om, en test dan fan in tûke nei it LAN fan 'e hub. Dy trije resultaten binne ferskillende bewiisstikken, en gjinien fan harren ymplisearret de oaren. As in tûkerouter net de standertgateway fan syn LAN is, ynstallearje dan de fiere prefiksen op 'e echte gateway en nim de pool der ek by as tunnelklanten ferbiningen nei dat LAN begjinne moatte.

Skriuw it plan, de bestannen per klant en de firewallregels as ien dokumint op, want de folgjende site-tafoeging sil deroan metten wurde.

It ûntwerp hâldt byinoar om't elke laach ien taak hat: it plan hâldt prefiksen unyk, de kernelrûte ferpleatst pakketten, de iroute neamt de eigner, en de firewall beslút wat tastien is. As der eat brekt, is dy list ek de folchoarder dêr't it yn neigongen wurde moat.