Dous clientes VPN, dúas direccións públicas: faga coincidir o SNAT

Dous clientes VPN poden saír por dúas direccións IPv4 públicas distintas, e a regra que o consegue é máis curta do que a maioría espera. O que a fai funcionar non é a sintaxe de iptables senón o estado do paquete cando chega á cadea de saída: a dirección de orixe que hai alí aínda ten que distinguir os clientes. Se un masquerade anterior xa uniu os dous nunha soa dirección, ningunha regra por cliente pode recuperar a distinción. Resolva primeiro esa cuestión e despois escriba a tradución.

Que identidade sobrevive ata a pasarela

A regra coincide coa dirección de orixe do paquete, non cun nome de usuario VPN nin co nome que mostra unha aplicación cliente. Todo o que traduce o paquete antes no camiño determina o que a súa regra aínda pode ver. Execute a táboa nat en orde e atope o punto no que a orixe segue sendo por cliente.

iptables -t nat -S POSTROUTING

Lea esa listaxe desde arriba. Unha regra de masquerade preto da parte superior reescribe a orixe de cada fluxo coincidente, e as entradas por cliente colocadas despois coinciden cunha dirección que xa non existe. Cando dous dispositivos LAN comparten un túnel e chegan como unha soa dirección interna, o deseño ten que cambiar antes que a devasa: manteña os seus rangos de orixe separados ou dea a cada un a súa propia dirección interna.

Vincule a asignación da dirección interna ao cliente autenticado. Entregar esa dirección a outro dispositivo entrega tamén a política de saída, e a tradución de orixe non é unha proba de identidade por si soa.

A tradución non pode inventar unha dirección

Cada dirección pública ten que asignarse ou encamiñarse a este punto de saída, e as respostas teñen que atopar o camiño de volta. Unha regra que envía tráfico desde unha dirección á que ninguén encamiña de volta descártase no extremo afastado ou respóndese a un host que nunca a pediu. Unha instancia de provedor de nube adoita ter a súa dirección pública traducida a unha dirección de interface privada antes de que o paquete saia, así que a orixe do SNAT ten que ser a dirección que o provedor aceptará, non o valor que mostra a consola. Lea o modelo de direccións do provedor e séguoo en lugar de copiar o valor público en cada paquete.

Na práctica, iso significa comprobar o prefixo encamiñado na consola do provedor antes de tocar a devasa, e usar a dirección de interface privada como orixe da tradución cando a correspondencia é un a un. As direccións dos exemplos seguintes proveñen dos rangos de documentación, así que o primeiro que hai que substituír é o propio texto da dirección.

Inserte antes do masquerade xenérico

Confirme a interface de saída e a cadea actual antes de engadir nada. A primeira decide que paquetes pode coincidir a regra, e a segunda mostra que hai xa diante dela.

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

O primeiro comando nomea a interface pola que sae realmente un paquete cara a internet. O segundo imprime a cadea con números de liña. A entrada de masquerade xenérica é a liña por riba da cal hai que quedarse.

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

As dúas regras anteriores coinciden cunha dirección interna cada unha, limitan a coincidencia á interface de saída e fixan a orixe explicitamente. Inserte en lugar de engadir: na posición 1 avalíanse antes da liña de masquerade. A orde entre as dúas non importa porque as súas orixes son distintas. Substitua ens3 polo que informase o comando de ruta, e manteña outros xestores de devasa lonxe dos mesmos ganchos, xa que dúas ferramentas que escriben unha táboa é a razón habitual de que unha regra correcta non teña efecto.

Demostre a orixe cun fluxo novo

O NAT con estado vincula unha tradución cando comeza un fluxo e reutilízaa para paquetes posteriores, así que unha sesión aberta antes do cambio conserva a súa orixe antiga despois do cambio. Só unha conexión iniciada de novo demostra a regra.

conntrack -L -s 10.88.4.20 -p tcp --dport 443

Lea a dirección de resposta desa entrada: o seu destino é a dirección que o extremo remoto ve como orixe. Compárea coa dirección pública que pretendía, e trate unha entrada que leve a dirección antiga como proba dun fluxo que comezou demasiado pronto, non dunha regra rota. Pida ao cliente que abra unha conexión nova e despois repita a consulta. Baleirar toda a táboa de seguimento para forzar a proba interrompe todas as demais sesións na pasarela.

A tradución segue sen escoller a ruta, sen admitir o fluxo polo filtro e sen publicar un servizo de entrada. Unha ruta equivocada e unha regra de permiso ausente seguen fallando despois dunha regra SNAT perfecta. Comprobe tamén IPv6 e calquera ruta de saída secundaria, e despois anote os pares interno-a-público na documentación da devasa, para que o próximo cambio parta da correspondencia e non do texto da regra.