Ieșire separată: pool VPN pe usb0, traficul gateway-ului pe eth0

Clienții se conectează și se autentifică, apoi traficul lor iese pe legătura superioară greșită, pentru că singura rută implicită de pe mașină aparține gateway-ului însuși. Înlocuirea acelei rute implicite ar strica actualizările proprii ale mașinii și accesul de administrare, așa că selecția trebuie să fie mai îngustă decât „tot traficul”. Forma care funcționează este o regulă de politică bazată pe adresa sursă internă a pool-ului de clienți, care indică un al doilea tabel de rutare ce deține WAN-ul alternativ. De acolo încolo lista de verificare privește completitudinea și comportamentul la eșec, nu regula în sine.

Confirmați că adresa sursă supraviețuiește până la decizia de rutare

O regulă de politică ce corespunde unui interval sursă se activează doar când pachetul mai poartă acea sursă în momentul căutării. Traficul clienților trimis mai departe o face, atât timp cât nimic din amonte nu l-a rescris înainte de rutare. Traficul generat de gateway nu o face, și exact de aceea ruta implicită proprie a gateway-ului poate rămâne unde este.

Aici testele locale înșală. Un curl rulat pe gateway este un flux generat local cu adresa gateway-ului, deci ia tabelul principal și nu dovedește nimic despre calea clientului. Testați de pe un client conectat sau generați trafic cu o sursă care aparține într-adevăr pool-ului.

Începeți prin a nota valorile reale: prefixul pool-ului, interfața de tunel care îl transportă, adresa și următorul salt ale celui de-al doilea WAN, și numărul de tabel pe care intenționați să îl folosiți. Curățați regulile vechi din orice încercare anterioară înainte de a adăuga altele noi, pentru că regulile duplicate la priorități diferite produc eșecuri care par aleatorii.

Construiți un tabel selectat care este complet

Un tabel nu este o rută implicită cu un prieten. Are nevoie de suficiente rute încât fiecare căutare să se rezolve în interiorul lui, inclusiv ruta conectată pentru subrețeaua WAN ca următorul salt să fie accesibil. Pentru un pool 10.77.0.0/24 pe tun1, o adresă WAN 203.0.113.20/24 cu următorul salt 203.0.113.1, și tabelul 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

Regula stă la o prioritate sub orice regulă prinde-tot existentă, așa că clienții potriviți ajung mai întâi în tabelul 600, iar restul cade în tabelul principal. Referința ip-rule descrie complet modelul de căutare ordonată și sintaxa selectorului.

Apoi gândiți-vă la ce nu conține tabelul. O destinație care are rută doar în tabelul principal, cum ar fi o subrețea de administrare accesibilă prin eth0, nu va fi găsită în tabelul 600 și nu va reveni la cel principal odată ce acolo există o rută implicită. Dacă acele căi contează, adăugați-le explicit în tabelul selectat, ceea ce este de obicei răspunsul corect pentru un tabel de ieșire VPN.

Țineți traficul ascultătorului însuși în afara politicii

Ascultătorul OpenVPN are propria conexiune externă, purtată pe legătura superioară prin care clientul l-a atins. Acel trafic trebuie să păstreze calea de întoarcere cu care a sosit, iar o regulă largă care acoperă adresa publică a serverului sau întreaga interfață de tunel îl poate trage în tabelul alternativ. Limitați regula la pool-ul intern și la nimic altceva.

Filtrarea căii inverse merită o privire din același motiv. Când răspunsurile către clienți ies prin usb0 în timp ce cererea a sosit pe altă legătură, o setare rp_filter strictă poate arunca pachete pe care politica de rutare le consideră valide. Verificați valorile sysctl efective pe ambele interfețe înainte de a concluziona că regula a eșuat.

Ordinea contează și față de orice altceva de pe mașină. Podurile Docker, un al doilea VPN și orice reguli preexistente dintr-o imagine de furnizor adaugă priorități, așa că citiți lista completă de reguli în loc să presupuneți că prioritatea 100 este singură.

Faceți ca trimiterea mai departe și traducerea să fie de acord cu ruta

Rutarea alege o legătură superioară; nu acordă permisiunea de a trimite mai departe. Nucleul trebuie să aibă activată trimiterea IPv4, iar firewall-ul trebuie să accepte direcția de la client la WAN și traficul de întoarcere. Un tabel corect cu un lanț FORWARD care aruncă fluxul produce același simptom ca o rută lipsă, de aceea ambele sunt verificate în aceeași trecere.

Dacă al doilea WAN nu va ruta un pool privat înapoi la dumneavoastră, traduceți sursa pe acea ieșire. Pentru o interfață cu adresă dinamică, alegerea obișnuită este o regulă masquerade îngustă, limitată la pool și la interfață:

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

Aici amploarea contează mai mult decât ținta. O regulă masquerade care corespunde oricărei interfețe de ieșire va rescrie și traficul care iese corect prin eth0, iar asta ascunde greșelile de rutare în loc să le repare. Traducerea rulează după decizia de rutare, deci nu poate repara niciodată un pachet trimis pe legătura superioară greșită.

Și suprasarcina tunelului cere atenție odată ce căile diferă. Dacă clienții negociază un MSS TCP mare și WAN-ul alternativ are un MTU mai mic sau un tunel în interior, segmentele mari se blochează în timp ce cele mici funcționează. Limitarea MSS pe calea de trimitere transformă asta într-un comportament previzibil în loc de o blocare intermitentă.

Decideți ce se întâmplă când usb0 dispare

Un tabel gol nu este o stare care se închide la eșec. Dacă ruta potrivită dispare, căutarea continuă la regula următoare, ajunge la tabelul principal și ia ruta implicită eth0. Traficul care trebuia să iasă prin al doilea WAN iese în liniște prin primul, ceea ce într-o implementare cu rutare pe politică este de obicei rezultatul pe care îl doriți cel mai puțin.

Unde acest recul este inacceptabil, adăugați o rută terminală explicită în tabelul 600, cum ar fi o rută implicită blackhole, sau aruncați pool-ul în firewall cât timp interfața este oprită. Oricare dintre ele este o decizie pe care o puteți scrie; tăcerea nu este.

Persistența este ultimul punct. Cine deține ambele legături, fie că este managerul de rețea, un script dispatcher sau ciclul de viață al conexiunii, trebuie să recreeze rutele și regula la fiecare reconectare fără a adăuga duplicate. Verificați cu o cerere de la un client real și o cerere separată de la gateway, confirmați ieșirea observată la ambele, apoi scoateți al doilea WAN și urmăriți care dintre cele două rezultate proiectate se întâmplă de fapt. IPv6 are nevoie de propriul tabel, regulă și traducere; regula IPv4 de mai sus nu spune nimic despre asta.