Gescheiden uitgang: VPN-pool op usb0, gatewayverkeer op eth0

Clients verbinden en authenticeren, en daarna verlaat hun verkeer de verkeerde uplink, omdat de enige standaardroute op de machine van de gateway zelf is. Die standaardroute vervangen zou de eigen updates en de beheerstoegang van de machine breken, dus de selectie moet smaller zijn dan ‘al het verkeer’. De werkbare vorm is een beleidsregel op basis van het interne bronadres van de clientpool, die wijst naar een tweede routetabel die het alternatieve WAN bezit. Vanaf daar gaat de checklist over volledigheid en gedrag bij falen, niet over de regel zelf.

Bevestig dat het bronadres tot de routeringsbeslissing behouden blijft

Een beleidsregel die op een bronbereik past, treedt alleen in werking als het pakket die bron op het moment van opzoeken nog draagt. Doorgestuurd clientverkeer doet dat, zolang niets stroomopwaarts het vóór de routering heeft herschreven. Verkeer dat de gateway zelf genereert doet dat niet, en precies daarom kan de eigen standaardroute van de gateway blijven waar hij is.

Hier misleiden lokale tests. Een curl op de gateway is een lokaal gegenereerde stroom met het adres van de gateway, dus die neemt de hoofdtabel en bewijst niets over het pad van de client. Test vanaf een verbonden client, of genereer verkeer met een bron die echt bij de pool hoort.

Begin met het opschrijven van de echte waarden: de poolprefix, de tunnelinterface die hem draagt, het adres en de volgende hop van het tweede WAN, en het tabelnummer dat je wilt gebruiken. Ruim de oude regels van elke eerdere poging op voordat je nieuwe toevoegt, want dubbele regels op verschillende prioriteiten veroorzaken storingen die willekeurig lijken.

Bouw een geselecteerde tabel die compleet is

Een tabel is geen standaardroute met een vriend. Er zijn genoeg routes nodig zodat elke opzoeking binnen de tabel wordt opgelost, inclusief de verbonden route voor het WAN-subnet zodat de volgende hop bereikbaar is. Voor een pool van 10.77.0.0/24 op tun1, een WAN-adres van 203.0.113.20/24 met volgende hop 203.0.113.1, en tabel 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

De regel staat op een prioriteit onder elke bestaande alles-vangende regel, dus overeenkomende clients raken eerst tabel 600 en al het andere valt door naar de hoofdtabel. De ip-rule-referentie beschrijft het geordende opzoekmodel en de selectorsyntaxis volledig.

Denk dan na over wat de tabel niet bevat. Een bestemming die alleen in de hoofdtabel een route heeft, zoals een beheersubnet dat via eth0 bereikbaar is, wordt niet in tabel 600 gevonden en valt niet terug naar de hoofdtabel zodra daar een standaardroute bestaat. Als die paden belangrijk zijn, voeg ze dan expliciet toe aan de geselecteerde tabel, wat meestal het juiste antwoord is voor een VPN-uitgangstabel.

Houd het eigen verkeer van de listener buiten het beleid

De OpenVPN-listener heeft zijn eigen buitenverbinding, gedragen over de uplink waarmee de client hem heeft bereikt. Dat verkeer moet de terugweg houden waarmee het aankwam, en een brede regel die het publieke adres van de server of de hele tunnelinterface dekt, kan het de alternatieve tabel in slepen. Beperk de regel tot de interne pool en niets anders.

Filtering van de terugweg verdient om dezelfde reden een blik. Wanneer antwoorden aan clients via usb0 naar buiten gaan terwijl het verzoek via een andere verbinding binnenkwam, kan een strikte rp_filter-instelling pakketten laten vallen die het routeringsbeleid als geldig beschouwt. Controleer de effectieve sysctl-waarden op beide interfaces voordat je concludeert dat de regel heeft gefaald.

Volgorde is ook belangrijk ten opzichte van al het andere op de machine. Docker-bruggen, een tweede VPN en alle bestaande regels uit een provider-image voegen prioriteiten toe, dus lees de volledige regellijst in plaats van aan te nemen dat prioriteit 100 alleen staat.

Laat doorsturen en vertaling overeenkomen met de route

Routering kiest een uplink; het geeft geen toestemming om door te sturen. De kernel moet IPv4-doorsturen hebben ingeschakeld, en de firewall moet de richting van client naar WAN en het retourverkeer accepteren. Een correcte tabel met een FORWARD-keten die de stroom laat vallen, geeft hetzelfde symptoom als een ontbrekende route, daarom worden beide in dezelfde doorgang gecontroleerd.

Als het tweede WAN een private pool niet naar jou terugrouteert, vertaal dan de bron op die uitgang. Voor een interface met een dynamisch adres is een smalle masquerade-regel beperkt tot de pool en de interface de gebruikelijke keuze:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

Bereik is hier belangrijker dan het doel. Een masquerade-regel die op elke uitgaande interface past, herschrijft ook verkeer dat correct via eth0 naar buiten gaat, en dat verbergt routeringsfouten in plaats van ze te verhelpen. Vertaling draait na de routeringsbeslissing, dus kan nooit een pakket repareren dat naar de verkeerde uplink is gestuurd.

Tunneloverhead vraagt ook aandacht zodra de paden verschillen. Als clients een grote TCP-MSS onderhandelen en het alternatieve WAN heeft een lagere MTU of een tunnel erin, dan stokken grote segmenten terwijl kleine werken. MSS knijpen op het doorstuurpad maakt daar voorspelbaar gedrag van in plaats van een incidentele hang.

Beslis wat er gebeurt als usb0 verdwijnt

Een lege tabel is geen faalsluitende toestand. Als de passende route verdwijnt, gaat de opzoeking door naar de volgende regel, bereikt de hoofdtabel en neemt de eth0-standaard. Verkeer dat via het tweede WAN naar buiten had moeten gaan, gaat stilletjes via het eerste, wat bij een beleidsgerouteerde uitrol meestal de uitkomst is die je het minst wilt.

Waar die terugval onaanvaardbaar is, voeg dan een expliciete terminale route toe in tabel 600, zoals een blackhole-standaard, of gooi de pool in de firewall terwijl de interface down is. Elk van beide is een beslissing die je kunt opschrijven; stilte niet.

Volharding is het laatste punt. Wie beide links bezit, of dat nu de netwerkbeheerder, een dispatcher-script of de levenscyclus van de verbinding is, moet bij elke herverbinding de routes en de regel opnieuw aanmaken zonder duplicaten toe te voegen. Verifieer met een verzoek van een echte client en een apart verzoek van de gateway, bevestig de waargenomen uitgang bij beide, trek dan het tweede WAN los en kijk welke van de twee ontworpen uitkomsten werkelijk optreedt. IPv6 heeft zijn eigen tabel, regel en vertaling nodig; de IPv4-regel hierboven zegt daar niets over.