Conserva ou aplica SNAT ás IP dos clientes VPN na fronteira da nube

Conservar o enderezo do cliente VPN ata a aplicación fai que cada liña de rexistro e cada entrada da lista de permitidos signifiquen o mesmo. Reescribilo no bordo da nube fai a táboa de rutas máis simple e os rexistros menos útiles. Ningunha das dúas opcións é incorrecta por si soa, e o argumento que a decide raramente ten que ver co rendemento. Tres condicións o resolven: se a aplicación debe saber que persoa se conectou, se a fábrica da nube aceptará a orixe que pretende enviar e quen aceptará facerse cargo da ruta de retorno despois.

Tres condicións decídeno

Comeza polo requisito da aplicación, non polo diagrama de rede. Se a autorización ou a auditoría dependen do enderezo individual do cliente, conservalo é un requisito funcional e traducilo é unha regresión. Se a aplicación só necesita saber que o tráfico chegou pola ruta de acceso remoto, un enderezo traducido abonda e é moito máis barato de operar.

A segunda condición é mecánica. Unha rede virtual non confía automaticamente nun paquete que afirma un enderezo que non se asignou á interface emisora. A maioría das fábricas de nube impoñen iso, de formas e con nomes distintos, e un deseño que o ignora parecerá correcto nun diagrama e descartará en silencio en produción.

A terceira é organizativa. Conservar as orixes significa que a táboa de rutas da subrede da aplicación debe apuntar de volta á pasarela para o prefixo do cliente, e cada equipo que engada unha subrede despois debe manter esa ruta coherente. É un custo pequeno unha vez e recorrente en decenas de contas. Decide quen o paga antes de prometer o comportamento.

Unha ruta non é permiso para suplantar

Engadir unha ruta de retorno di á túa subrede onde deben ir as respostas. Non di á fábrica que a instancia que reenvía eses paquetes teña permiso para emitilos cunha orixe allea. En AWS o control relevante é a comprobación de orixe e destino, e é visible por instancia:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

Desactívaa só para a instancia cuxo traballo documentado é o reenvío, e para nada máis. Cada VM de aplicación que mantén a comprobación activada é unha máquina menos que pode usarse para emitir tráfico cunha orixe prestada. Se a túa plataforma non é AWS, busca o axuste equivalente de anti-suplantación ou de enderezos permitidos no canto de supor que o comportamento se traslada.

Unha captura de paquetes rápida resolve a cuestión máis rápido que ler a consola. Se as respostas saen e o cliente nunca as ve, é a fábrica a que descarta a orixe suplantada, non a aplicación a que falla.

Que compra a tradución e que custa

Reescribir a orixe na pasarela elimina o problema da ruta de retorno. A aplicación ve un enderezo que xa sabe como acadar, e o prefixo do cliente nunca ten que aparecer nunha táboa de rutas da nube. En Linux a regra é unha liña, e paga a pena escribir a versión máis estreita que poidas:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

Fíxate no que a aplicación rexistra agora: 10.40.3.10 para cada usuario, en cada conexión, para sempre. Calquera lista de enderezos permitidos construída sobre ese valor agora concede acceso a toda a poboación de acceso remoto, e calquera revisión de incidente ten que volver á pasarela para responder quen era.

A solución non é abandonar a tradución, é deixar de finxir que o enderezo é unha identidade. Leva a identidade do cliente nun campo autenticado, rexístrana na pasarela xunto coa tupla traducida e deixa que a aplicación se una por ela. Sen a clave de unión, a tradución converte un problema de rede nun forense permanente.

O relé é unha interface distinta

Un proxy inverso diante da aplicación evita por completo a cuestión da ruta encamiñada. O proxy abre a súa propia conexión de backend, así que o prefixo do cliente nunca necesita ser encamiñable dentro da rede virtual, e a aplicación pode recibir identidade nunha cabeceira que o proxy establece.

Esa cabeceira só é fiable cando o backend a acepta do proxy e de nada máis. En termos de nginx iso significa nomear explicitamente o par de confianza no canto de crer calquera cousa que chegue:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Calquera cliente que poida acadar o backend directamente pode falsificar a mesma cabeceira, así que o backend debe ser inalcanzable agás a través do proxy. Iso é un feito de cortafuegos, non unha opinión de configuración, e é a suposición que a xente salta cando copia o fragmento.

O relé tamén cambia o que compras. Obtés unha identidade a nivel de aplicación e un lugar natural para rexistrala; renuncias á xeneralidade, porque cada protocolo novo necesita o seu propio soporte de proxy. Para os servizos HTTP ese intercambio adoita ser bo, e para calquera cousa que non sexa HTTP normalmente non está dispoñible en absoluto.

Anota que ve cada fronteira

Elixas o que elixas, a revisión de deseño debería rematar cunha táboa que nomee o enderezo de orixe e a identidade demostrable en cada salto. Sen ela, o primeiro incidente produce tres equipos que describen cada un un cliente distinto.

Logo elixe. Conserva cando a autorización da aplicación dependa de verdade do enderezo do cliente e poidas asumir a ruta. Traduce cando non sexa así e poidas levar a identidade fóra de banda, e usa as indicacións de AWS para instancias de reenvío para os axustes de reenvío específicos da plataforma. Recorre a un relé cando o servizo fale HTTP e queiras que a identidade deixe de ser un enderezo.