Adskilt udgang: VPN-pulje på usb0, gateway-trafik på eth0

Klienter forbinder og godkender, og derefter forlader deres trafik den forkerte uplink, fordi den eneste standardrute på maskinen tilhører gatewayen selv. At erstatte den standardrute ville ødelægge maskinens egne opdateringer og administrationsadgang, så udvælgelsen skal være snævrere end »al trafik«. Den brugbare form er en politikregel baseret på klientpuljens indre kildeadresse, der peger på en anden rutetabel, som ejer den alternative WAN. Derfra handler tjeklisten om fuldstændighed og fejlhåndtering, ikke om selve reglen.

Bekræft, at kildeadressen overlever til rutingsbeslutningen

En politikregel, der matcher et kildeområde, udløses kun, når pakken stadig bærer den kilde på opslagstidspunktet. Videresendt klienttrafik gør det, så længe intet opstrøms har genskrevet den før rutning. Trafik, som gatewayen selv genererer, gør det ikke, og det er netop derfor, gatewayens egen standardrute kan blive, hvor den er.

Det er her, lokale tests vildleder. En curl-kørsel på gatewayen er en lokalt genereret strøm med gatewayens adresse, så den tager hovedtabellen og beviser intet om klientstien. Test fra en tilsluttet klient, eller generér trafik med en kilde, der faktisk hører til puljen.

Start med at skrive de reelle værdier ned: puljens præfiks, det tunnelinterface der bærer den, den anden WAN's adresse og næste hop, og det tabelnummer du vil bruge. Ryd de gamle regler fra ethvert tidligere forsøg, før du tilføjer nye, fordi dublerede regler med forskellige prioriteter giver fejl, der ser tilfældige ud.

Byg en valgt tabel, der er komplet

En tabel er ikke en standardrute med en ven. Den har brug for nok ruter til, at hvert opslag løses inde i den, inklusive den forbundne rute for WAN-undernettet, så næste hop kan nås. For en pulje på 10.77.0.0/24 på tun1, en WAN-adresse på 203.0.113.20/24 med næste hop 203.0.113.1 og 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

Reglen ligger på en prioritet under enhver eksisterende fang-alt-regel, så matchende klienter rammer tabel 600 først, og alt andet falder igennem til hovedtabellen. ip-rule-referencen beskriver den ordnede opslagsmodel og vælgersyntaksen fuldt ud.

Tænk så over, hvad tabellen ikke indeholder. En destination, der kun har en rute i hovedtabellen, for eksempel et administrationsundernet, der kan nås via eth0, findes ikke i tabel 600 og falder ikke tilbage til hovedtabellen, når der først findes en standardrute der. Hvis de stier betyder noget, skal de tilføjes eksplicit til den valgte tabel, hvilket normalt er det rigtige svar for en VPN-udgangstabel.

Hold lytterens egen trafik ude af politikken

OpenVPN-lytteren har sin egen ydre forbindelse, båret over den uplink, klienten nåede den på. Den trafik skal beholde den returvej, den ankom med, og en bred regel, der dækker serverens offentlige adresse eller hele tunnelinterfacet, kan trække den ind i den alternative tabel. Begræns reglen til den indre pulje og intet andet.

Filtrering af returvej fortjener et blik af samme grund. Når svar til klienter forlader via usb0, mens anmodningen ankom over et andet link, kan en streng rp_filter-indstilling kaste pakker væk, som rutingpolitikken anser for gyldige. Kontrollér de effektive sysctl-værdier på begge interfaces, før du konkluderer, at reglen fejlede.

Rækkefølgen betyder også noget i forhold til alt andet på maskinen. Docker-broer, en anden VPN og alle eksisterende regler fra et udbyderimage tilføjer prioriteter, så læs hele regellisten i stedet for at antage, at prioritet 100 står alene.

Få videresendelse og oversættelse til at passe med ruten

Rutning vælger en uplink; den giver ikke tilladelse til at videresende. Kernen skal have IPv4-videresendelse aktiveret, og firewallen skal acceptere retningen fra klient til WAN og returtrafikken. En korrekt tabel med en FORWARD-kæde, der dropper strømmen, giver samme symptom som en manglende rute, og derfor kontrolleres begge i samme gennemgang.

Hvis den anden WAN ikke vil rute en privat pulje tilbage til dig, skal du oversætte kilden på den udgang. Til et interface med dynamisk adresse er en smal masquerade-regel begrænset til puljen og interfacet det sædvanlige valg:

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

Omfang betyder mere end målet her. En masquerade-regel, der matcher ethvert udgående interface, vil også genskrive trafik, der korrekt forlader via eth0, og det skjuler rutingsfejl i stedet for at rette dem. Oversættelse kører efter rutingsbeslutningen, så den kan aldrig reparere en pakke, der er sendt til den forkerte uplink.

Tunneloverhead kræver også opmærksomhed, når stierne er forskellige. Hvis klienterne forhandler en stor TCP-MSS, og den alternative WAN har en lavere MTU eller en tunnel indeni, går store segmenter i stå, mens små virker. At klemme MSS på videresendelsesstien gør det til en forudsigelig adfærd i stedet for et periodisk hang.

Beslut, hvad der sker, når usb0 forsvinder

En tom tabel er ikke en fejllukkende tilstand. Hvis den matchende rute forsvinder, fortsætter opslaget til den næste regel, når hovedtabellen og tager eth0-standardruten. Trafik, der skulle have forladt via den anden WAN, forlader stille via den første, hvilket for en politikstyret udrulning normalt er det udfald, du ønsker mindst.

Hvor det fald tilbage er uacceptabelt, skal du tilføje en eksplicit terminalrute i tabel 600, for eksempel en blackhole-standardrute, eller droppe puljen i firewallen, mens interfacet er nede. Hvert af valgene er en beslutning, du kan skrive ned; tavshed er ikke.

Vedholdenhed er det sidste punkt. Den, der ejer begge links, uanset om det er netværksadministratoren, et dispatcher-script eller forbindelsens livscyklus, skal genskabe ruterne og reglen ved hver genopkobling uden at tilføje dubletter. Verificér med en anmodning fra en rigtig klient og en separat anmodning fra gatewayen, bekræft den observerede udgang på begge, træk derefter den anden WAN ud og se, hvilket af de to udfald, du designede, der faktisk sker. IPv6 har brug for sin egen tabel, regel og oversættelse; IPv4-reglen ovenfor siger intet om det.