Conserva o aplica SNAT a les IP del client VPN a la frontera del núvol

Conservar l’adreça del client VPN fins a l’aplicació fa que cada línia de registre i cada entrada de la llista permesa signifiquin el mateix. Reescriure-la a la vora del núvol fa la taula d’encaminament més simple i els registres menys útils. Cap de les dues opcions no és incorrecta per si sola, i l’argument que la decideix poques vegades tracta de rendiment. Tres condicions ho resolen: si l’aplicació ha de saber quin humà s’ha connectat, si la fàbrica del núvol acceptarà l’origen que voleu enviar i qui acceptarà fer-se càrrec de la ruta de tornada després.

Tres condicions ho decideixen

Comença pel requisit de l’aplicació, no pel diagrama de xarxa. Si l’autorització o l’auditoria depenen de l’adreça individual del client, conservar-la és un requisit funcional i traduir-la és una regressió. Si l’aplicació només necessita saber que el trànsit ha arribat pel camí d’accés remot, una adreça traduïda és suficient i molt més barata d’operar.

La segona condició és mecànica. Una xarxa virtual no es refia automàticament d’un paquet que afirma una adreça que no s’ha assignat a la interfície emissora. La majoria de fàbriques de núvol ho imposen, de maneres i amb noms diferents, i un disseny que ho ignora semblarà correcte en un diagrama i caurà en silenci en producció.

La tercera és organitzativa. Conservar els orígens vol dir que la taula d’encaminament de la subxarxa de l’aplicació ha d’apuntar cap a la passarel·la per al prefix del client, i cada equip que afegeixi una subxarxa després ha de mantenir aquesta ruta coherent. És un cost petit una vegada i recurrent en desenes de comptes. Decidiu qui el paga abans de prometre el comportament.

Una ruta no és permís per suplantar

Afegir una ruta de tornada diu a la vostra subxarxa on han d’anar les respostes. No diu a la fàbrica que la instància que reenvia aquests paquets tingui permís per emetre’ls amb un origen estranger. A AWS, el control rellevant és la comprovació d’origen i destinació, i és visible per instància:

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

Desactiveu-la només per a la instància la feina documentada de la qual és el reenviament, i per a res més. Cada VM d’aplicació que manté la comprovació activada és una màquina menys que es pot fer servir per emetre trànsit amb un origen prestat. Si la vostra plataforma no és AWS, busqueu el paràmetre equivalent d’anti-suplantació o d’adreces permeses en lloc de suposar que el comportament es trasllada.

Una captura de paquets ràpida resol la qüestió més de pressa que llegir la consola. Si les respostes surten i el client no les veu mai, la fàbrica descarta l’origen suplantat i no és l’aplicació la que falla.

Què compra la traducció i què costa

Reescriure l’origen a la passarel·la elimina el problema del camí de tornada. L’aplicació veu una adreça que ja sap com assolir, i el prefix del client no ha d’aparèixer mai en una taula d’encaminament del núvol. A Linux la regla és una línia, i val la pena escriure la versió més estreta que pugueu:

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

Fixeu-vos en què registra ara l’aplicació: 10.40.3.10 per a cada usuari, a cada connexió, per sempre. Qualsevol llista permesa d’adreces construïda sobre aquest valor ara atorga accés a tota la població d’accés remot, i qualsevol revisió d’incident ha de tornar a la passarel·la per respondre qui era.

La solució no és abandonar la traducció, és deixar de fingir que l’adreça és una identitat. Porteu la identitat del client en un camp autenticat, registreu-la a la passarel·la amb la tupla traduïda i deixeu que l’aplicació hi faci la unió. Sense la clau d’unió, la traducció converteix un problema de xarxa en un de forense permanent.

El relé és una interfície diferent

Un proxy invers davant de l’aplicació evita del tot la qüestió del camí encaminat. El proxy obre la seva pròpia connexió de backend, així que el prefix del client no ha de ser mai encaminable dins de la xarxa virtual, i l’aplicació pot rebre la identitat en una capçalera que el proxy estableix.

Aquesta capçalera només és fiable quan el backend l’accepta del proxy i de res més. En termes d’nginx això vol dir nomenar explícitament el parell de confiança en lloc de creure’s qualsevol cosa que arribi:

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

Qualsevol client que pugui arribar directament al backend pot falsificar la mateixa capçalera, així que el backend ha de ser inabastable excepte a través del proxy. Això és un fet de tallafocs, no una opinió de configuració, i és la suposició que la gent s’estalvia quan copia el fragment.

El relé també canvia què compreu. Obteniu una identitat a nivell d’aplicació i un lloc natural per registrar-la; renuncieu a la generalitat, perquè cada protocol nou necessita el seu propi suport de proxy. Per als serveis HTTP aquest intercanvi sol ser bo, i per a qualsevol cosa que no sigui HTTP normalment no està disponible en absolut.

Anoteu què veu cada frontera

Triïs el que triïs, la revisió de disseny hauria d’acabar amb una taula que anomeni l’adreça d’origen i la identitat demostrable a cada salt. Sense ella, el primer incident produeix tres equips que descriuen cadascun un client diferent.

Després trieu. Conserveu quan l’autorització de l’aplicació depèn realment de l’adreça del client i podeu assumir la ruta. Traduïu quan no és així i podeu portar la identitat fora de banda, i feu servir les indicacions d’AWS per a instàncies de reenviament per als paràmetres de reenviament específics de la plataforma. Recorreu a un relé quan el servei parla HTTP i voleu que la identitat deixi de ser una adreça.