Saída separada: pool de VPN por usb0, tráfico da pasarela por eth0

Os clientes conéctanse e autentícanse, e despois o seu tráfico sae polo enlace ascendente incorrecto, porque a única ruta predeterminada do equipo pertence á propia pasarela. Substituír esa ruta predeterminada rompería as actualizacións e o acceso de administración da máquina, así que a selección ten que ser máis estreita que «todo o tráfico». A forma viable é unha regra de política baseada no enderezo de orixe interno do pool de clientes, que apunta a unha segunda táboa de encamiñamento que posúe o WAN alternativo. A partir de aí, a lista de comprobación trata de completitude e do comportamento ante fallos, non da regra en si.

Confirma que o enderezo de orixe sobrevive ata a decisión de encamiñamento

Unha regra de política que coincide cun rango de orixe só se activa cando o paquete aínda leva esa orixe no momento da consulta. O tráfico de clientes reenviado faino, sempre que nada augas arriba o reescribise antes do encamiñamento. O tráfico xerado pola pasarela non o fai, e por iso mesmo a súa propia ruta predeterminada pode quedar onde está.

Aquí é onde as probas locais enganan. Un curl executado na pasarela é un fluxo xerado localmente co enderezo da pasarela, así que toma a táboa principal e non demostra nada sobre a ruta do cliente. Proba desde un cliente conectado, ou xera tráfico cunha orixe que pertenza realmente ao pool.

Comeza anotando os valores reais: o prefixo do pool, a interface de túnel que o transporta, o enderezo e o seguinte salto do segundo WAN, e o número de táboa que pensas usar. Limpa as regras antigas de calquera intento anterior antes de engadir novas, porque as regras duplicadas con prioridades distintas producen fallos que parecen aleatorios.

Constrúe unha táboa seleccionada que estea completa

Unha táboa non é unha ruta predeterminada cun amigo. Necesita suficientes rutas para que cada consulta se resolva dentro dela, incluída a ruta conectada da subrede WAN para que o seguinte salto sexa alcanzable. Para un pool de 10.77.0.0/24 en tun1, un enderezo WAN de 203.0.113.20/24 con seguinte salto 203.0.113.1, e a táboa 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

A regra sitúase nunha prioridade por baixo de calquera regra comodín existente, así que os clientes coincidentes chegan primeiro á táboa 600 e todo o demais cae á táboa principal. A referencia de ip-rule describe por completo o modelo de consulta ordenada e a sintaxe do selector.

Despois pensa no que a táboa non contén. Un destino que só ten ruta na táboa principal, como unha subrede de administración accesible por eth0, non se atopará na táboa 600 e non volverá á principal unha vez que exista alí unha ruta predeterminada. Se eses camiños importan, engádeos explicitamente á táboa seleccionada, que adoita ser a resposta correcta para unha táboa de saída VPN.

Mantén o tráfico propio do escoitante fóra da política

O escoitante de OpenVPN ten a súa propia conexión externa, transportada polo enlace ascendente polo que o cliente o alcanzou. Ese tráfico debe conservar o camiño de volta co que chegou, e unha regra ampla que cubra o enderezo público do servidor ou toda a interface de túnel pode arrastralo á táboa alternativa. Limita a regra ao pool interno e a nada máis.

O filtrado de ruta inversa merece unha ollada polo mesmo motivo. Cando as respostas aos clientes saen por usb0 mentres a petición chegou por outro enlace, un axuste estrito de rp_filter pode descartar paquetes que a política de encamiñamento considera válidos. Comproba os valores efectivos de sysctl nas dúas interfaces antes de concluír que a regra fallou.

A orde tamén importa respecto de calquera outra cousa no equipo. As pontes de Docker, un segundo VPN e calquera regra previa dunha imaxe de provedor engaden prioridades, así que le a lista completa de regras en lugar de supor que a prioridade 100 está soa.

Fai que o reenvío e a tradución coincidan coa ruta

O encamiñamento escolle un enlace ascendente; non concede permiso para reenviar. O núcleo debe ter o reenvío IPv4 activado, e a devasa debe aceptar a dirección de cliente a WAN e o tráfico de volta. Unha táboa correcta cunha cadea FORWARD que descarte o fluxo produce o mesmo síntoma que unha ruta ausente, e por iso ambos se comproban na mesma pasada.

Se o segundo WAN non encamiñará un pool privado de volta cara a ti, traduce a orixe nesa saída. Para unha interface con enderezo dinámico, a elección habitual é unha regra masquerade estreita limitada ao pool e á interface:

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

Aquí o alcance importa máis que o obxectivo. Unha regra masquerade que coincida con calquera interface de saída tamén reescribirá o tráfico que sae correctamente por eth0, o que oculta os erros de encamiñamento en lugar de corrixilos. A tradución execútase despois da decisión de encamiñamento, así que nunca pode reparar un paquete enviado ao enlace ascendente incorrecto.

A sobrecarga do túnel tamén require atención cando os camiños difiren. Se os clientes negocian un MSS TCP grande e o WAN alternativo ten unha MTU máis baixa ou un túnel dentro, os segmentos grandes atáscase mentres os pequenos funcionan. Limitar o MSS no camiño de reenvío converte iso nun comportamento previsible en vez dun bloqueo intermitente.

Decide que ocorre cando usb0 desaparece

Unha táboa baleira non é un estado de peche ante fallos. Se a ruta coincidente desaparece, a consulta continúa cara á regra seguinte, chega á táboa principal e toma a ruta predeterminada de eth0. O tráfico que debía saír polo segundo WAN sae en silencio polo primeiro, o que nunha implantación con encamiñamento por política adoita ser o resultado que menos queres.

Onde ese retroceso é inaceptable, engade unha ruta terminal explícita na táboa 600, como unha ruta predeterminada blackhole, ou descarta o pool na devasa mentres a interface está caída. Calquera das dúas é unha decisión que podes escribir; o silencio non.

A persistencia é o último punto. Quen posúa ambos os enlaces, xa sexa o xestor de rede, un script despachador ou o ciclo de vida da conexión, debe recrear as rutas e a regra en cada reconexión sen engadir duplicados. Verifícao cunha petición dun cliente real e outra separada desde a pasarela, confirma a saída observada en ambas, despois retira o segundo WAN e observa cal dos dous resultados que deseñaches ocorre realmente. IPv6 necesita a súa propia táboa, regra e tradución; a regra IPv4 anterior non di nada sobre iso.