Sortida separada: pool de VPN per usb0, trànsit de la passarel·la per eth0

Els clients es connecten i s’autentiquen, i després el seu trànsit surt per l’enllaç ascendent equivocat, perquè l’única ruta per defecte de la màquina pertany a la mateixa passarel·la. Substituir aquesta ruta per defecte trencaria les actualitzacions i l’accés de gestió de la màquina, així que la selecció ha de ser més estreta que «tot el trànsit». La forma que funciona és una regla de política basada en l’adreça d’origen interna del pool de clients, que apunta a una segona taula d’encaminament que posseeix el WAN alternatiu. A partir d’aquí, la llista de comprovació tracta de completesa i del comportament davant de fallades, no de la regla en si.

Confirma que l’adreça d’origen arriba fins a la decisió d’encaminament

Una regla de política que coincideix amb un rang d’origen només s’activa quan el paquet encara porta aquest origen en el moment de la consulta. El trànsit de clients reenviat ho fa, sempre que res aigües amunt no l’hagi reescrit abans de l’encaminament. El trànsit generat per la passarel·la no ho fa, i per això mateix la ruta per defecte pròpia de la passarel·la pot quedar-se on és.

Aquí és on les proves locals enganyen. Un curl executat a la passarel·la és un flux generat localment amb l’adreça de la passarel·la, així que agafa la taula principal i no demostra res sobre el camí del client. Prova-ho des d’un client connectat, o genera trànsit amb un origen que pertanyi realment al pool.

Comença escrivint els valors reals: el prefix del pool, la interfície de túnel que el porta, l’adreça i el salt següent del segon WAN, i el número de taula que vols utilitzar. Neteja les regles antigues de qualsevol intent anterior abans d’afegir-ne de noves, perquè les regles duplicades amb prioritats diferents produeixen fallades que semblen aleatòries.

Construeix una taula seleccionada que sigui completa

Una taula no és una ruta per defecte amb un amic. Necessita prou rutes perquè cada consulta es resolgui dins seu, inclosa la ruta connectada de la subxarxa WAN perquè el salt següent sigui abastable. Per a un pool de 10.77.0.0/24 a tun1, una adreça WAN de 203.0.113.20/24 amb salt següent 203.0.113.1, i la taula 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

La regla se situa en una prioritat per sota de qualsevol regla comodí existent, així que els clients coincidents arriben primer a la taula 600 i tota la resta cau a la taula principal. La referència d’ip-rule descriu completament el model de consulta ordenada i la sintaxi del selector.

Després pensa en què no conté la taula. Una destinació que només té ruta a la taula principal, com una subxarxa de gestió abastable per eth0, no es trobarà a la taula 600 i no tornarà a la principal quan hi hagi una ruta per defecte. Si aquests camins importen, afegeix-los explícitament a la taula seleccionada, que normalment és la resposta correcta per a una taula de sortida VPN.

Mantén el trànsit propi de l’oient fora de la política

L’oient d’OpenVPN té una connexió externa pròpia, portada per l’enllaç ascendent pel qual el client l’ha arribat. Aquest trànsit ha de conservar el camí de tornada amb què va arribar, i una regla àmplia que cobreixi l’adreça pública del servidor o tota la interfície de túnel el pot arrossegar cap a la taula alternativa. Limita la regla al pool intern i a res més.

El filtratge de camí invers mereix una mirada pel mateix motiu. Quan les respostes als clients surten per usb0 mentre la petició ha arribat per un altre enllaç, un paràmetre rp_filter estricte pot descartar paquets que la política d’encaminament considera vàlids. Comprova els valors efectius de sysctl a les dues interfícies abans de concloure que la regla ha fallat.

L’ordre també importa respecte de qualsevol altra cosa de la màquina. Els ponts de Docker, un segon VPN i qualsevol regla prèvia d’una imatge de proveïdor afegeixen prioritats, així que llegeix la llista completa de regles en lloc de suposar que la prioritat 100 està sola.

Fes que el reenviament i la traducció concordin amb la ruta

L’encaminament selecciona un enllaç ascendent; no atorga permís per reenviar. El nucli ha de tenir el reenviament IPv4 activat, i el tallafoc ha d’acceptar la direcció del client cap al WAN i el trànsit de tornada. Una taula correcta amb una cadena FORWARD que descarti el flux produeix el mateix símptoma que una ruta absent, i per això totes dues es comproven en la mateixa passada.

Si el segon WAN no encaminarà un pool privat de tornada cap a tu, tradueix l’origen en aquesta sortida. Per a una interfície amb adreça dinàmica, l’elecció habitual és una regla masquerade estreta limitada al pool i a la interfície:

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

Aquí l’abast importa més que l’objectiu. Una regla masquerade que coincideixi amb qualsevol interfície de sortida també reescriurà el trànsit que surt correctament per eth0, cosa que amaga els errors d’encaminament en lloc de corregir-los. La traducció s’executa després de la decisió d’encaminament, així que mai no pot reparar un paquet enviat a l’enllaç ascendent equivocat.

La sobrecàrrega del túnel també demana atenció quan els camins difereixen. Si els clients negocien un MSS TCP gran i el WAN alternatiu té una MTU més baixa o un túnel a dins, els segments grans s’encallen mentre els petits funcionen. Limitar l’MSS al camí de reenviament ho converteix en un comportament previsible en lloc d’un blocatge intermitent.

Decideix què passa quan usb0 desapareix

Una taula buida no és un estat de tancament davant de fallades. Si la ruta coincident desapareix, la consulta continua cap a la regla següent, arriba a la taula principal i pren la ruta per defecte eth0. El trànsit que havia de sortir pel segon WAN surt silenciosament pel primer, cosa que en un desplegament amb encaminament per política sol ser el resultat que menys vols.

On aquesta retrocessió és inacceptable, afegeix una ruta terminal explícita a la taula 600, com una ruta per defecte blackhole, o descarta el pool al tallafoc mentre la interfície està caiguda. Qualsevol de les dues és una decisió que pots escriure; el silenci no ho és.

La persistència és l’últim punt. Qui posseeixi tots dos enllaços, sigui el gestor de xarxa, un script despatxador o el cicle de vida de la connexió, ha de recrear les rutes i la regla a cada reconnexió sense afegir duplicats. Verifica-ho amb una petició d’un client real i una petició separada de la passarel·la, confirma la sortida observada en tots dos, i després treu el segon WAN i mira quin dels dos resultats que has dissenyat passa realment. IPv6 necessita la seva pròpia taula, regla i traducció; la regla IPv4 anterior no en diu res.