Separat utgång: VPN-pool på usb0, gatewaytrafik på eth0

Klienter ansluter och autentiserar sig, och sedan lämnar deras trafik fel upplänk, eftersom den enda standardvägen på maskinen tillhör gatewayen själv. Att ersätta den standardvägen skulle bryta maskinens egna uppdateringar och administrationstillgång, så urvalet måste vara snävare än ”all trafik”. Den fungerande formen är en policyregel baserad på klientpoolens inre källadress, som pekar på en andra routingtabell som äger den alternativa WAN-förbindelsen. Därifrån handlar checklistan om fullständighet och beteende vid fel, inte om själva regeln.

Bekräfta att källadressen överlever ända till routingbeslutet

En policyregel som matchar ett källområde utlöses bara när paketet fortfarande bär den källan vid sökningstillfället. Vidarebefordrad klienttrafik gör det, så länge inget längre upp har skrivit om den före routingen. Trafik som gatewayen själv genererar gör det inte, och det är just därför gatewayens egen standardväg kan stanna där den är.

Det är här lokala tester vilseleder. En curl-körning på gatewayen är ett lokalt genererat flöde med gatewayens adress, så den tar huvudtabellen och bevisar ingenting om klientens väg. Testa från en ansluten klient, eller generera trafik med en källa som faktiskt tillhör poolen.

Börja med att skriva ned de verkliga värdena: poolens prefix, tunnelgränssnittet som bär den, adressen och nästa hopp för den andra WAN-förbindelsen, och tabellnumret du tänker använda. Rensa de gamla reglerna från varje tidigare försök innan du lägger till nya, eftersom dubblerade regler med olika prioritet ger fel som verkar slumpmässiga.

Bygg en vald tabell som är komplett

En tabell är inte en standardväg med en vän. Den behöver tillräckligt många rutter för att varje sökning ska lösas inuti den, inklusive den anslutna rutten för WAN-subnätet så att nästa hopp går att nå. För en pool på 10.77.0.0/24 på tun1, en WAN-adress 203.0.113.20/24 med nästa hopp 203.0.113.1, och tabell 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

Regeln ligger på en prioritet under varje befintlig fånga-allt-regel, så matchande klienter träffar tabell 600 först och allt annat faller igenom till huvudtabellen. ip-rule-referensen beskriver den ordnade sökmodellen och väljarsyntaxen fullt ut.

Tänk sedan på vad tabellen inte innehåller. Ett mål som bara har en rutt i huvudtabellen, till exempel ett administrationssubnät som nås via eth0, hittas inte i tabell 600 och faller inte tillbaka till huvudtabellen när det väl finns en standardväg där. Om de vägarna spelar roll, lägg dem uttryckligen till i den valda tabellen, vilket vanligtvis är rätt svar för en VPN-utgångstabell.

Håll lyssnarens egen trafik utanför policyn

OpenVPN-lyssnaren har sin egen yttre anslutning, buren över den upplänk som klienten nådde den på. Den trafiken måste behålla returvägen den kom med, och en bred regel som täcker serverns publika adress eller hela tunnelgränssnittet kan dra in den i den alternativa tabellen. Begränsa regeln till den inre poolen och inget annat.

Filtrering av returväg förtjänar en titt av samma skäl. När svar till klienter går ut via usb0 medan begäran kom in över en annan länk, kan en strikt rp_filter-inställning kasta paket som routingpolicyn anser giltiga. Kontrollera de effektiva sysctl-värdena på båda gränssnitten innan du drar slutsatsen att regeln misslyckades.

Ordningen spelar också roll i förhållande till allt annat på maskinen. Docker-bryggor, en andra VPN och alla befintliga regler från en leverantörsavbildning lägger till prioriteter, så läs hela regellistan i stället för att anta att prioritet 100 står ensam.

Få vidarebefordran och översättning att stämma med rutten

Routing väljer en upplänk; det ger inte tillstånd att vidarebefordra. Kärnan måste ha IPv4-vidarebefordran aktiverad, och brandväggen måste acceptera riktningen från klient till WAN och returtrafiken. En korrekt tabell med en FORWARD-kedja som släpper flödet ger samma symptom som en saknad rutt, och därför kontrolleras båda i samma genomgång.

Om den andra WAN-förbindelsen inte kommer att routa en privat pool tillbaka till dig, översätt källan på den utgången. För ett gränssnitt med dynamisk adress är en smal masquerade-regel begränsad till poolen och gränssnittet det vanliga valet:

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

Omfattningen är viktigare än målet här. En masquerade-regel som matchar vilket utgående gränssnitt som helst skriver också om trafik som korrekt går ut via eth0, och det döljer routingfel i stället för att rätta dem. Översättningen körs efter routingbeslutet, så den kan aldrig reparera ett paket som skickats till fel upplänk.

Tunneloverhead kräver också uppmärksamhet när vägarna skiljer sig. Om klienterna förhandlar en stor TCP-MSS och den alternativa WAN-förbindelsen har lägre MTU eller en tunnel inuti, stannar stora segment medan små fungerar. Att klämma MSS på vidarebefordringsvägen gör det till förutsägbart beteende i stället för en tillfällig hängning.

Bestäm vad som händer när usb0 försvinner

En tom tabell är inte ett feltillstånd som stänger. Om den matchande rutten försvinner fortsätter sökningen till nästa regel, når huvudtabellen och tar eth0-standarden. Trafik som skulle ha gått ut via den andra WAN-förbindelsen går tyst ut via den första, vilket för en policy-routad driftsättning vanligtvis är resultatet du vill ha minst.

Där den återgången är oacceptabel, lägg till en uttrycklig terminalrutt i tabell 600, till exempel en blackhole-standard, eller släpp poolen i brandväggen medan gränssnittet är nere. Båda valen är ett beslut du kan skriva ned; tystnad är det inte.

Varaktighet är den sista punkten. Den som äger båda länkarna, vare sig det är nätverkshanteraren, ett dispatcher-skript eller anslutningens livscykel, måste återskapa rutterna och regeln vid varje återanslutning utan att lägga till dubbletter. Verifiera med en begäran från en riktig klient och en separat begäran från gatewayen, bekräfta den observerade utgången på båda, dra sedan ut den andra WAN-förbindelsen och se vilket av de två resultat du designat som faktiskt inträffar. IPv6 behöver sin egen tabell, regel och översättning; IPv4-regeln ovan säger ingenting om det.