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

Tre private LAN kan møtast på éin hub utan at nokon stad treng å kjenne den interne strukturen til dei andre, og heile designet kviler på fire korte konfigurasjonsavgjerder. Det som får det til å fungere er ikkje ein eksotisk protokollfunksjon, men ein adresseplan som ingen treng å gjette på, pluss ruter per klient som fortel huben kva filial som eig kva prefiks. Går éin av dei gale, kjem tunnelen likevel opp, og nettopp det gjer feilen forvirrande.

Gå gjennom trinna i rekkjefølgje. Kvart trinn er avhengig av planen frå trinnet før, og ingen av dei krev ein ny sertifikatstyresmakt.

Start med ein plan ingen treng å gjette på

Skriv ned fire åtskilde prefiks før du rører ei konfigurasjonsfil: huben sitt eige LAN, LANet til kvar filial og puljen som blir gitt til klientar som flyttar seg. Åtskilnaden er det som held alt anna enkelt, fordi overlappande område gjer ruting til eit puslespel med lengste treff som ingen konfigurasjon per klient reparerer. Stadfest deretter kva maskin som er standard gateway for kvart LAN, sidan ein filialruter som ikkje er gateway for sitt eige LAN treng å installere dei eksterne rutene heilt andre stader. Til slutt fastset du dei autentiserte namna som identifiserer kvar filial, fordi dei namna er nøklane filene per klient blir slått opp med.

Ein illustrerande plan held puljen godt unna dei tre LANa. Din vil vere annleis, og den einaste harde regelen er at ingen to område overlappar.

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

Fortel kjernen på huben kvar filialane er

Huben treng to opplysningar per filial: ei kjernerute som sender prefikset inn i tunneleininga, og ein iroute-oppføring som fortel OpenVPN-prosessen kva klient som eig det. Kjerneruta åleine leverer pakkane til tunnelen og stoppar der, fordi daemonen framleis må avgjere kva peer som skal ta imot dei. iroute-oppføringa åleine lèt pakkane bli att i kjernen utan noka rute å følgje. Begge linjene høyrer heime i konfigurasjonen daemonen faktisk lastar, og det er verdt å stadfeste før du feilsøkjer noko anna.

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

Hald client-to-client av når kjernen skal vere staden der reglane blir handheva. Det valet videresender trafikk mellom peers inne i daemonen, noko som er praktisk og også betyr at videresendingsreglane dine aldri ser flyten. Alt nedanfor føreset at kjernen ser kvar pakke mellom filialar.

Gje kvar filial rutene ho treng

Kvar filial treng ruter til dei andre filialane og til LANet til huben, og treng ikkje éi for sitt eige tilkopla LAN. Skyv dei eksterne prefiksa frå huben i staden for å lime dei inn i kvar ruter, slik at ein fjerde stad seinare tyder éi ny fil per klient i staden for fire endringar. Fila per klient ber òg iroute-linja, som held eigarskap og annonsering på same stad. Gjer katalogen og filene hans lesbare under privilegiemodellen til serveren, elles feilar oppslaget utan ei 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"

Ein fjerde stad følgjer same mønster: eit eige autentisert namn, eit eigd prefiks, ei kjernerute på huben, ein iroute-oppføring og annonseringar berre til stadene som har løyve til å nå han.

Test i begge retningar før du kallar det ferdig

Slå på IPv4-videresending på alle tre rutarane, og stadfest deretter at brannmuren tillèt dei tiltenkte flytane i begge retningar, fordi ein einvegs test består med ein broten returveg oftare enn nokon ventar. Mellom stadene trengst ingen omsetjing av kjeldeadressa, og det å ta vare på den opphavlege kjelda er nettopp det som lèt kvar filial bruke si eiga politikk på ein førespurnad.

Test frå ein vert på eitt filial-LAN til ei teneste på eit anna, snu deretter retninga, og test så frå ein filial til LANet til huben. Dei tre resultata er ulike bevis, og ingen av dei inneber dei andre. Viss ein filialruter ikkje er standard gateway for sitt LAN, installer dei eksterne prefiksa på den verkelege gatewayen og ta med puljen òg når tunnelklientar må starte tilkoplingar inn i det LANet.

Dokumenter planen, filene per klient og brannmurreglane som eitt dokument, fordi neste stadstillegg vil bli vurdert opp mot dei.

Designet held saman fordi kvart lag har éi oppgåve: planen held prefiksa unike, kjerneruta flyttar pakkar, iroute namngir eigaren, og brannmuren avgjer kva som er tillate. Når noko bryt, er den lista òg rekkjefølgja å sjekke i.