En OpenVPN-hub, tre LAN: adresseplan og iroute-filer

Tre private LAN kan mødes på en hub uden at nogen lokalitet lærer de andres indre at kende, og hele designet hviler på fire korte konfigurationsbeslutninger. Det, der får det til at virke, er ikke en eksotisk protokolfunktion, men en adresseplan, som ingen behøver at gætte, plus ruter per klient, der fortæller hubben, hvilken gren der ejer hvilket præfiks. Tager du fejl af en af de to ting, kommer tunnelen stadig op, og det er netop det, der gør fejlen forvirrende.

Gå trinnene igennem i rækkefølge. Hvert trin afhænger af planen fra trinnet før, og ingen af dem kræver en ny certifikatmyndighed.

Start med en plan, som ingen behøver at gætte

Skriv fire usammenfaldende præfikser ned, før du rører en konfigurationsfil: hubbens eget LAN, hver grens LAN og den pulje, der uddeles til omrejsende klienter. Usammenfald er det, der holder alt andet enkelt, fordi overlappende områder gør routing til et puslespil med længste match, som ingen konfiguration per klient reparerer. Bekræft derefter, hvilken maskine der er standardgateway for hvert LAN, fordi en grenrouter, der ikke er gateway for sit eget LAN, skal have fjernruterne installeret helt andre steder. Fastlæg til sidst de autentificerede navne, der identificerer hver gren, fordi disse navne er de nøgler, filerne per klient slås op efter.

En illustrativ plan holder puljen langt væk fra de tre LAN. Din vil være anderledes, og den eneste hårde regel 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

Fortæl hubbens kerne, hvor grenene er

Hubben skal bruge to oplysninger for hver gren: en kerne-rute, der sender præfikset ind i tunnel-enheden, og en iroute post, der fortæller OpenVPN processen, hvilken klient der ejer den. Kerne-ruten alene leverer pakkerne til tunnelen og stopper der, fordi dæmonen stadig skal afgøre, hvilken peer der skal modtage dem. Den iroute post alene efterlader pakkerne i kernen uden en rute at følge. Begge linjer hører til i den konfiguration, dæmonen faktisk indlæser, og det er værd at verificere, før du fejlfinder noget som helst andet.

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

Slå klient-til-klient fra, når kernen skal være håndhævelsespunktet. Den valgmulighed videresender peer-trafik inde i dæmonen, hvilket er bekvemt og også betyder, at dine videresendelsesregler aldrig ser strømmen. Alt nedenfor forudsætter, at kernen ser hver pakke mellem grene.

Giv hver gren de ruter, den har brug for

Hver gren har brug for ruter til de andre grene og til hubbens LAN, og den har ikke brug for en til sit eget tilsluttede LAN. Skub fjernpræfikserne fra hubben i stedet for at indsætte dem i hver router, så en fjerde lokalitet senere betyder én ny fil per klient i stedet for fire rettelser. Filen per klient bærer også linjen iroute, som holder ejerskab og annoncering samme sted. Gør mappen og dens filer læsbare under serverens privilegiemodel, ellers fejler opslaget uden en meddelelse.

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

En fjerde lokalitet følger samme mønster: et særskilt autentificeret navn, et ejet præfiks, en kerne-rute i hubben, en iroute post og annonceringer kun til de lokaliteter, der har tilladelse til at nå den.

Test i begge retninger, før du kalder det færdigt

Aktivér IPv4-videresendelse på alle tre routere, og bekræft derefter, at firewallem tillader de tilsigtede strømme i begge retninger, fordi en envejstest består med en brudt returvej oftere, end nogen forventer. Der er ikke brug for kildeoversættelse mellem lokaliteter, og det er bevarelsen af den oprindelige kilde, der lader hver gren anvende sin egen politik på en anmodning.

Test fra en vært på én grens LAN til en tjeneste på en anden, vend derefter retningen, og test så fra en gren til hubbens LAN. De tre resultater er forskellige beviser, og ingen af dem indebærer de andre. Hvis en grenrouter ikke er standardgateway for sit LAN, skal du installere fjernpræfikserne på den rigtige gateway og også medtage puljen, når tunnelklienter skal starte forbindelser ind i det LAN.

Skriv planen, filerne per klient og firewallreglerne ned som ét dokument, fordi den næste tilføjelse af en lokalitet vil blive vurderet op imod dem.

Designet hænger sammen, fordi hvert lag har én opgave: planen holder præfikser unikke, kerne-ruten flytter pakker, iroute navngiver ejeren, og firewallem afgør, hvad der er tilladt. Når noget går i stykker, er den liste også den rækkefølge, den skal tjekkes i.