Eén OpenVPN-hub, drie LAN's: adresplan en iroute-bestanden

Drie particuliere LAN's kunnen elkaar op één hub ontmoeten zonder dat een locatie de interne opbouw van de andere hoeft te kennen, en het hele ontwerp rust op vier korte configuratiebeslissingen. Wat het laat werken is geen exotische protocolfunctie, maar een adresplan dat niemand hoeft te raden, plus routes per client die de hub vertellen welke filiaal welk prefix bezit. Is een van beide verkeerd, dan komt de tunnel toch omhoog, en juist dat maakt de storing verwarrend.

Doorloop de stappen in volgorde. Elke stap hangt af van het plan van de vorige stap, en geen ervan vereist een nieuwe certificaatautoriteit.

Begin met een plan dat niemand hoeft te raden

Schrijf vier disjuncte prefixen op voordat je een configuratiebestand aanraakt: het eigen LAN van de hub, het LAN van elke filiaal en de pool die aan rondzwervende clients wordt gegeven. Disjunctheid is wat al het andere eenvoudig houdt, want overlappende bereiken maken routering tot een puzzel van de langste overeenkomst die geen enkele configuratie per client repareert. Bevestig daarna welke machine de standaardgateway van elk LAN is, want een filiaalrouter die niet de gateway van zijn eigen LAN is, moet de externe routes ergens anders volledig installeren. Leg ten slotte de geauthenticeerde namen vast die elke filiaal identificeren, want die namen zijn de sleutels waarmee de bestanden per client worden opgezocht.

Een voorbeeldplan houdt de pool ruim weg van de drie LAN's. Het jouwe zal anders zijn, en de enige harde regel is dat geen twee bereiken overlappen.

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

Vertel de kernel van de hub waar de filialen zijn

De hub heeft per filiaal twee gegevens nodig: een kernelroute die het prefix het tunnelapparaat in stuurt, en een iroute-vermelding die het OpenVPN-proces vertelt welke client er eigenaar van is. Alleen de kernelroute bezorgt pakketten bij de tunnel en stopt daar, want de daemon moet nog beslissen welke peer ze moet ontvangen. Alleen de iroute-vermelding laat die pakketten in de kernel achter zonder route om te volgen. Beide regels horen in de configuratie die de daemon werkelijk laadt, en dat is het controleren waard voordat je iets anders debugt.

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

Houd client-to-client uit wanneer de kernel het handhavingspunt moet zijn. Die optie geeft verkeer tussen peers binnen de daemon door, wat handig is en ook betekent dat je forwarding-regels de stroom nooit zien. Alles hieronder gaat ervan uit dat de kernel elk pakket tussen filialen ziet.

Geef elke filiaal de routes die hij nodig heeft

Elke filiaal heeft routes nodig naar de andere filialen en naar het LAN van de hub, en geen naar zijn eigen aangesloten LAN. Duw de externe prefixen vanuit de hub in plaats van ze in elke router te plakken, zodat een vierde locatie later één nieuw bestand per client betekent in plaats van vier bewerkingen. Het bestand per client bevat ook de iroute-regel, die eigendom en aankondiging op dezelfde plek houdt. Maak de map en zijn bestanden leesbaar volgens het privilege-model van de server, anders mislukt het opzoeken zonder 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"

Een vierde locatie volgt hetzelfde patroon: een aparte geauthenticeerde naam, een eigen prefix, een kernelroute op de hub, een iroute-vermelding en aankondigingen alleen naar de locaties die het mogen bereiken.

Test in beide richtingen voordat je het klaar noemt

Schakel IPv4-forwarding in op alle drie de routers en bevestig daarna dat de firewall de bedoelde stromen in beide richtingen toestaat, want een eenrichtingstest slaagt met een gebroken retourpad vaker dan iemand verwacht. Tussen locaties is geen bronadresvertaling nodig, en het bewaren van de oorspronkelijke bron is precies wat elke filiaal in staat stelt zijn eigen beleid op een verzoek toe te passen.

Test vanaf een host op het ene filiaal-LAN naar een dienst op het andere, draai daarna de richting om en test dan vanaf een filiaal naar het LAN van de hub. Die drie resultaten zijn verschillend bewijs, en geen ervan impliceert de andere. Als een filiaalrouter niet de standaardgateway van zijn LAN is, installeer de externe prefixen dan op de echte gateway en neem de pool mee wanneer tunnelclients verbindingen naar dat LAN moeten starten.

Leg het plan, de bestanden per client en de firewallregels vast als één document, want de volgende locatie-uitbreiding wordt daaraan getoetst.

Het ontwerp blijft overeind omdat elke laag één taak heeft: het plan houdt prefixen uniek, de kernelroute verplaatst pakketten, iroute noemt de eigenaar en de firewall beslist wat is toegestaan. Wanneer er iets breekt, is die lijst ook de volgorde om het te controleren.