En OpenVPN-hubb, tre LAN: adressplan och iroute-filer

Tre privata LAN kan mötas på en enda hubb utan att någon plats behöver känna till de andras interna uppbyggnad, och hela designen vilar på fyra korta konfigurationsbeslut. Det som får det att fungera är inte en exotisk protokollfunktion, utan en adressplan som ingen behöver gissa, plus rutter per klient som talar om för hubben vilken filial som äger vilket prefix. Är någon av dem fel kommer tunneln ändå upp, och just det gör felet förvirrande.

Gå igenom stegen i ordning. Varje steg beror på planen från steget före, och inget av dem kräver en ny certifikatmyndighet.

Börja med en plan som ingen behöver gissa

Skriv ned fyra åtskilda prefix innan du rör en konfigurationsfil: hubbens eget LAN, varje filials LAN och poolen som delas ut till kringflackande klienter. Åtskillnaden är det som håller allt annat enkelt, eftersom överlappande intervall gör routingen till ett pussel med längsta träff som ingen konfiguration per klient reparerar. Bekräfta sedan vilken maskin som är standardgateway för varje LAN, eftersom en filialrouter som inte är gateway för sitt eget LAN måste installera de externa rutterna någon helt annanstans. Bestäm slutligen de autentiserade namnen som identifierar varje filial, eftersom de namnen är nycklarna som filerna per klient slås upp med.

En illustrativ plan håller poolen ordentligt borta från de tre LAN-näten. Din kommer att se annorlunda ut, och den enda hårda regeln är att inga två intervall överlappar.

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

Berätta för hubbens kärna var filialerna finns

Hubben behöver två uppgifter per filial: en kärnroute som skickar prefixet in i tunnelenheten och en iroute-post som talar om för OpenVPN-processen vilken klient som äger den. Enbart kärnrouten levererar paketen till tunneln och stannar där, eftersom daemonen fortfarande måste avgöra vilken peer som ska ta emot dem. Enbart iroute-posten lämnar paketen i kärnan utan någon rutt att följa. Båda raderna hör hemma i den konfiguration som daemonen faktiskt läser in, och det är värt att verifiera innan du felsöker något annat.

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

Håll client-to-client avstängt när kärnan ska vara punkten där reglerna tillämpas. Det alternativet vidarebefordrar trafik mellan peers inne i daemonen, vilket är bekvämt och också betyder att dina vidarebefordringsregler aldrig ser flödet. Allt nedan förutsätter att kärnan ser varje paket mellan filialer.

Ge varje filial de rutter den behöver

Varje filial behöver rutter till de andra filialerna och till hubbens LAN, och behöver ingen för sitt eget anslutna LAN. Skjut de externa prefixen från hubben i stället för att klistra in dem i varje router, så att en fjärde plats senare betyder en ny fil per klient i stället för fyra ändringar. Filen per klient bär också raden iroute, som håller ägande och annonsering på samma ställe. Gör katalogen och dess filer läsbara enligt serverns privilegiemodell, annars misslyckas uppslaget utan ett meddelande.

# /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 fjärde plats följer samma mönster: ett eget autentiserat namn, ett ägt prefix, en kärnroute på hubben, en iroute-post och annonseringar bara till de platser som får nå den.

Testa i båda riktningarna innan du kallar det klart

Slå på IPv4-vidarebefordran på alla tre routrarna och bekräfta sedan att brandväggen tillåter de avsedda flödena i båda riktningarna, eftersom ett enkelriktat test klarar sig med en bruten returväg oftare än någon förväntar sig. Mellan platserna behövs ingen översättning av källadressen, och det är just bevarandet av den ursprungliga källan som gör att varje filial kan tillämpa sin egen policy på en förfrågan.

Testa från en värd på ett filial-LAN till en tjänst på ett annat, vänd sedan riktningen och testa därefter från en filial till hubbens LAN. De tre resultaten är olika bevis, och inget av dem innebär de andra. Om en filialrouter inte är standardgateway för sitt LAN installerar du de externa prefixen på den riktiga gatewayen och tar med poolen också när tunnelklienter måste starta anslutningar in i det LAN-et.

Dokumentera planen, filerna per klient och brandväggsreglerna som ett dokument, eftersom nästa plats som läggs till kommer att bedömas mot dem.

Designen håller ihop eftersom varje lager har en uppgift: planen håller prefixen unika, kärnrouten flyttar paket, iroute namnger ägaren och brandväggen avgör vad som tillåts. När något går sönder är den listan också ordningen att kontrollera i.