Én OpenVPN-hub, tre LAN: adresseplan og iroute-filer

Tre private LAN kan møtes på én hub uten at noe sted trenger å kjenne de andres interne struktur, og hele designet hviler på fire korte konfigurasjonsbeslutninger. Det som får det til å fungere er ikke en eksotisk protokollfunksjon, men en adresseplan som ingen trenger å gjette på, pluss ruter per klient som forteller huben hvilken filial som eier hvilket prefiks. Går én av dem galt, kommer tunnelen likevel opp, og nettopp det gjør feilen forvirrende.

Gå gjennom trinnene i rekkefølge. Hvert trinn avhenger av planen fra trinnet før, og ingen av dem krever en ny sertifikatmyndighet.

Start med en plan ingen trenger å gjette på

Skriv ned fire adskilte prefikser før du rører en konfigurasjonsfil: hubens eget LAN, hver filials LAN og poolen som gis til omflakkende klienter. Adskillelsen er det som holder alt annet enkelt, fordi overlappende områder gjør ruting til et puslespill med lengste treff som ingen konfigurasjon per klient reparerer. Deretter bekrefter du hvilken maskin som er standard gateway for hvert LAN, siden en filialruter som ikke er gateway for sitt eget LAN trenger å installere de eksterne rutene helt andre steder. Til slutt fastsetter du de autentiserte navnene som identifiserer hver filial, fordi de navnene er nøklene filene per klient slås opp med.

En illustrerende plan holder poolen godt unna de tre LAN-ene. Din vil være annerledes, og den eneste harde regelen er at ingen to områder overlapper.

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

Fortell kjernen på huben hvor filialene er

Huben trenger to opplysninger per filial: en kjernerute som sender prefikset inn i tunneleinheten, og en iroute-oppføring som forteller OpenVPN-prosessen hvilken klient som eier det. Kjerneruten alene leverer pakkene til tunnelen og stopper der, fordi daemonen fortsatt må avgjøre hvilken peer som skal motta dem. iroute-oppføringen alene lar pakkene bli igjen i kjernen uten noen rute å følge. Begge linjene hører hjemme i konfigurasjonen daemonen faktisk laster, og det er verdt å verifisere før du feilsøker noe annet.

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

Hold client-to-client av når kjernen skal være stedet reglene håndheves. Det alternativet videresender trafikk mellom peers inne i daemonen, noe som er praktisk og også betyr at videresendingsreglene dine aldri ser flyten. Alt nedenfor forutsetter at kjernen ser hver pakke mellom filialer.

Gi hver filial rutene den trenger

Hver filial trenger ruter til de andre filialene og til hubens LAN, og trenger ikke en for sitt eget tilkoblede LAN. Skyv de eksterne prefiksene fra huben i stedet for å lime dem inn i hver ruter, slik at et fjerde sted senere betyr én ny fil per klient i stedet for fire endringer. Filen per klient bærer også iroute-linjen, som holder eierskap og annonsering på samme sted. Gjør katalogen og filene dens lesbare under serverens privilegiemodell, ellers feiler oppslaget uten en melding.

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

Et fjerde sted følger samme mønster: et eget autentisert navn, et eid prefiks, en kjernerute på huben, en iroute-oppføring og annonseringer bare til stedene som har lov til å nå det.

Test i begge retninger før du kaller det ferdig

Slå på IPv4-videresending på alle tre ruterne, og bekreft deretter at brannmuren tillater de tiltenkte flytene i begge retninger, fordi en enveistest består med en brutt returvei oftere enn noen forventer. Mellom stedene trengs ingen oversettelse av kildeadressen, og det å bevare den opprinnelige kilden er nettopp det som lar hver filial anvende sin egen policy på en forespørsel.

Test fra en vert på ett filial-LAN til en tjeneste på et annet, snu deretter retningen, og test så fra en filial til hubens LAN. De tre resultatene er forskjellige bevis, og ingen av dem innebærer de andre. Hvis en filialruter ikke er standard gateway for sitt LAN, installerer du de eksterne prefiksene på den virkelige gatewayen og tar med poolen også når tunnelklienter må starte tilkoblinger inn i det LAN-et.

Dokumenter planen, filene per klient og brannmurreglene som ett dokument, fordi neste steds tilføyelse vil bli vurdert opp mot dem.

Designet holder sammen fordi hvert lag har én oppgave: planen holder prefiksene unike, kjerneruten flytter pakker, iroute navngir eieren, og brannmuren avgjør hva som er tillatt. Når noe bryter, er den listen også rekkefølgen å sjekke i.