Twee netwerkgateways, één VPN: waarom OpenVPN de verkeerde uplink kiest

Twee uplinks, één tunnel, en het verkeer vertrekt via degene die u niet hebt gekozen. De privé-subnetten zijn bereikbaar, het log meldt een geslaagde verbinding, en de gemeten lijn is degene die het draagt. Niets in de OpenVPN-uitvoer noemt een gateway, omdat de client er nooit een heeft gekozen. Hij opende een socket naar een extern adres en liet de kernel beslissen hoe dat adres wordt bereikt.

Het tunneladres is niet het eindpunt

In elke sessie bestaan twee verschillende paden. Het buitenste pad draagt het versleutelde transport naar het openbare adres van de server. Het binnenste pad draagt alles wat de server de tunnel in duwt, en routeringsregels voor het ene hebben geen effect op het andere.

De remote-regel in het profiel noemt de buitenste bestemming, dus dat is het adres dat moet worden vastgezet. Het is ook de waarde die verandert wanneer een hostnaam anders wordt opgelost of het profiel meerdere remote-regels vermeldt.

Vind het adres dat de client werkelijk heeft gebeld

Lees de levende socket in plaats van het configuratiebestand. De sockettabel toont de peer waarmee het proces werkelijk verbonden is, en dat is de waarde waaraan een uitzondering moet voldoen. Een profiel kan worden bewerkt nadat de sessie is begonnen, en de socket is het enige bewijs van wat is gebeld:

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

De logregel noemt het peeradres en de poort op het moment van verbinden. Als die niet overeenkomt met het profiel, herschrijft iets vóór de client de bestemming voordat de verbinding begint.

Controleer ook de adresfamilie. Een dual-stackprofiel kan via IPv6 verbinden terwijl uw uitzondering alleen IPv4 dekt, en dan volgt het verkeer een andere regel dan die u hebt geschreven. Hetzelfde geldt voor een proxy die namens het eindpunt antwoordt. Beide gevallen leveren een tunnel die werkt terwijl uw route niets doet.

Zet het eindpunt vast en lees de beleidsvolgorde

Een hostroute is specifieker dan elke standaardroute. Daarom wint een /32 voor het peeradres binnen de tabel die hem bevat. De gebruikelijke vorm noemt de gateway en het apparaat expliciet:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

Die route helpt alleen als de opzoeking die tabel bereikt. Beleidsregels worden op volgorde beoordeeld en de eerste overeenkomst beslist, dus een regel die alles naar een tweede tabel stuurt, omzeilt uw hostroute in main. Lees de regels voordat u aanneemt dat de route gezaghebbend is:

ip rule show
ip route get 203.0.113.40

Vraag de tweede opdracht met hetzelfde bronadres of dezelfde markering die de client gebruikt wanneer het beleid daarvan afhangt. Hij rapporteert de route die de kernel zou kiezen, wat bewijs is over de opzoeking en geen bewijs dat de levende socket dat pad gebruikt.

Wanneer het eindpunt verschuift

Een hostnaam die naar meerdere adressen oplost, maakt een permanente /32 ongeldig zodra het antwoord verandert. Een profiel met meerdere remote-regels heeft hetzelfde probleem, omdat de client op elk daarvan kan landen. Ververs de route vanuit de eigen lifecycle-hooks van de client in plaats van hem handmatig toe te voegen. Een up-script dat de onderhandelde peer leest en de hostroute installeert, houdt de uitzondering in lijn met de werkelijkheid, en een bijpassend down-script verwijdert hem.

Leg de verversing vast op dezelfde plek als de rest van de routeringsconfiguratie van de host. Een route die alleen tot de volgende herstart bestaat, is een test, geen oplossing.

Houd het binnenste beleid gescheiden

Het buitenste pad verplaatsen geeft geen toegang tot een nieuw privé-subnet en verandert niet welke bestemmingen de server de tunnel in duwt. De route van de onderlaag kiest de draad; de geduwde routes kiezen wat de tunnel in gaat. Die twee beslissingen gescheiden houden maakt de splitsing voorspelbaar.

Als het doel alleen is het versleutelde transport van een gemeten lijn weg te houden, laat de standaardroute dan met rust en voeg de enkele hostuitzondering toe. De standaardroute van de hele machine vervangen om één VPN-verbinding te verplaatsen breekt elke andere toepassing op de host.

Bevestig het resultaat met twee onafhankelijke observaties: het lokale adres en apparaat van de socket, en de route waarop de privé-bestemming wordt opgelost. Wanneer beide bij uw bedoeling passen, is de splitsing echt. De OpenVPN 2.6-handleiding behandelt de remote- en lokale bindingsopties die bepalen welk adres de client belt.