Twee OpenVPN-tunnels op één Linux-host: van wie is de route?

Twee profielen zijn verbonden, en een ervan draagt stilletjes verkeer dat voor de ander bedoeld is. Een Linux-host kan beide OpenVPN-clients tegelijk zonder moeite draaien. Wat hij niet kan, is voor u beslissen welk proces welk prefix mag claimen. Die beslissing moet vallen voordat de tweede tunnel omhoog komt, niet nadat een resource stopt met antwoorden.

Begin bij het werk dat de tweede link moet doen

Een kantoor dat via één profiel bereikbaar is en een lab dat via een ander bereikbaar is, hebben beide tunnels omhoog nodig en geen van beide die alles claimt. Eén koppige toepassing die via het tweede profiel naar buiten moet, heeft een beleidsregel nodig in plaats van een tweede standaardroute. Een standby-verbinding heeft maar één tunnel tegelijk nodig, dus de reserve zou niet met de machine moeten starten.

Dat zijn drie verschillende configuraties, en ze raken verward omdat alle drie hetzelfde beginnen: een tweede profiel en een geslaagde verbinding. Schrijf eerst de bedoelde opstelling op en configureer daar vervolgens naartoe. Eén zin over de bedoeling bespaart een uur pakketopname.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

Het eerste commando somt de draaiende instanties op, inclusief exemplaren die handmatig buiten de beheerder zijn gestart. Het tweede drukt de huidige standaardclaim af, en dat is de toestand die u later moet uitleggen.

Overlappende pools breken voordat routing dat doet

Twee servers delen met plezier adressen uit dezelfde 10.8.0.0/24. De client heeft dan twee interfaces binnen één prefix zonder iets dat zegt welke bestemming bij welke hoort, en het resulterende gedrag lijkt op een routeringsfout maar is in werkelijkheid een nummeringsfout. Een pool hernummeren kost één configuratiewijziging; elke latere routeringsomweg kost een weekend. Controleer de pool voordat u er een route voor toevoegt.

Kijk ook naar het lokale LAN. Een thuis-LAN met nummer 192.168.1.0/24 dat één tunnel ook blootlegt, levert dezelfde dubbelzinnigheid op, en het symptoom is een hostnaam die wordt opgelost terwijl de verbinding nooit tot stand komt. Dat lijkt op een naamresolutiefout totdat u de routes afdrukt.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Vergelijk beide uitvoer met de twee serverconfiguraties voordat u de client aanraakt. Als de prefixen overlappen, stop en hernummer, want geen enkele herstart zal ze scheiden.

Geef elk profiel zijn eigen unit en elk prefix een eigenaar

Elk profiel krijgt zijn eigen instantienaam en zijn eigen configuratiebestand, dus de instantie office laadt office.conf terwijl die met de naam lab lab.conf laadt. Bevestig die toewijzing via de servicemanager in plaats van een mapoverzicht te vertrouwen, want een drop-in kan veranderen welk bestand wordt geladen. Een verkeerde toewijzing betekent dat u het profiel afstelt dat niet draait.

Bepaal vervolgens wie de routes installeert. Wanneer de servers onverenigbare sets pushen, weiger dan de push en som de prefixen zelf op, of laat één profiel de standaard houden en stuur de andere met beleidsregels. Twee processen die beide een standaard installeren, eindigen met een stille winnaar en zonder schriftelijk verslag van de beslissing.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

De eerste toont de unit met elke overschrijving die de argumenten verandert. De tweede toont of het profiel gepushte routes überhaupt accepteert, en dat is de schakelaar die alles daarna bepaalt.

Markeringen houden antwoorden op de interface waar ze vandaan kwamen

Wanneer elke tunnel verschillende bronnen bedient, kan een antwoord via de verkeerde link vertrekken en sterft de verbinding na het eerste pakket. Het patroon dat standhoudt, is aankomende pakketten markeren op basis van de invoerinterface, die markering op het antwoord herstellen en elke markering een tabel met een eigen standaardgateway geven.

Losse reverse-path-filtering moet voor de betroffen interfaces meestal worden versoepeld, omdat een antwoord rechtmatig aankomt via een link die de hoofdtabel nooit zou kiezen. Houd de markeringen smal zodat ze nooit het eigen versleutelde verkeer van de tunnels vangen, wat de tunnel door zichzelf zou sturen.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Lees de bestaande regels voordat u er nog een toevoegt. Dubbele prioriteiten en vergeten tabellen zijn de gebruikelijke reden waarom een markeringbeleid helemaal geen effect lijkt te hebben.

Bewijs isolatie door één link te stoppen

Noteer met beide tunnels omhoog het adres van elke interface, de route naar één host achter elke tunnel en het pad dat een ongerelateerde bestemming neemt. Vraag de kernel om de opzoeking in plaats van één tabel te lezen, want één tabel toont nooit de uiteindelijke beslissing.

Stop dan één instantie en kijk hoe de interface en routes verdwijnen terwijl de andere doorgaat. Een breuk in de overlevende betekent dat de twee nog steeds een apparaatnaam, een route of een firewallregel delen die niemand heeft gescheiden.

Breng het gestopte profiel terug en herhaal dezelfde controles. Wanneer een tunnel alleen de eerste start na een herstart overleeft, kijkt u naar een levenscyclusdefect en niet naar een routeringsontwerp.