LAN darrere d’una sessió d’AWS Client VPN: què es reenvia

El portàtil es connecta al punt de connexió d’AWS Client VPN, arriba a la subxarxa privada i tot sembla saludable. L’ordinador d’escriptori de la mateixa LAN no arriba enlloc, tot i que l’amfitrió Linux també té una interfície de pont i totes dues màquines són al mateix cable. No hi ha res mal configurat al túnel; la peça que falta és l’encaminament, i el pont és una pista falsa.

Estendre una sessió de Client VPN a una LAN és un paper de passarel·la. No és un segment Ethernet estirat dins d’un servei gestionat.

L’amfitrió funciona i la LAN no

La interfície de túnel de la màquina Linux té una adreça dins del CIDR del client de Client VPN, i el punt de connexió ha enviat rutes per als rangs de la VPC. Una petició feta en aquesta màquina és trànsit generat localment: tria una ruta, surt pel túnel i obté una resposta. Aquest camí no toca mai el codi de reenviament, la interfície LAN ni cap regla de tallafoc que governi el trànsit.

El trànsit d’un altre dispositiu de la LAN és un flux diferent. Arriba a la interfície LAN, necessita una ruta que apunti al túnel, necessita el reenviament habilitat, necessita un tallafoc que el permeti i necessita que la resposta torni pel mateix amfitrió. Quatre requisits, i la prova que funciona amb el portàtil no en demostra cap. Des de l’escriptori la fallada sembla estranya: el túnel està actiu, les credencials són vàlides i la destinació simplement no respon mai. El defecte és local al camí de reenviament de la passarel·la, no al servei.

No tots els clients poden ser una passarel·la

AWS afirma que la seva aplicació d’escriptori Client VPN no admet reenviament IP, i que altres clients podrien fer-ho. Aquesta restricció decideix l’arquitectura abans que s’escrigui cap ordre. Si l’únic client disponible és l’aplicació oficial d’escriptori, una passarel·la Linux que reenvia per a la LAN no és una configuració que pugueu acabar, i cap quantitat de masquerading ho canviarà.

El client substitut també ha de coincidir amb el mètode d’autenticació del punt de connexió i amb la política que voleu aplicar. Els punts de connexió basats en certificats, en directori i amb SAML no accepten les mateixes configuracions de client, i un client de tercers que s’autentica però ignora les rutes enviades no és una millora.

Tracteu l’elecció del client com a part de la revisió del disseny. Determina si el patró de reenviament de LAN està disponible, i determina quina identitat veu el punt de connexió per a cada dispositiu darrere la passarel·la. Enregistreu el client i la configuració del punt de connexió contra la qual es va provar. Un canvi de client sis mesos després pot eliminar en silenci la capacitat que el disseny assumia.

Encamineu la LAN al túnel i traduïu-la

Amb un client admès al lloc, la resta és feina ordinària de passarel·la. Els dispositius de la LAN necessiten una ruta per al rang de la VPC que apunti a l’amfitrió Linux, i l’amfitrió necessita el reenviament habilitat. Si voleu que la VPC vegi el trànsit com el client connectat i no com una adreça LAN arbitrària, traduïu la font a la sortida.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Limiteu la regla a la interfície de túnel i al rang de la VPC, com a dalt, en lloc de fer masquerading de tot el que reenvia l’amfitrió. La regla més estreta és més fàcil de raonar i no canvia en silenci trànsit que havia de conservar la seva adreça d’origen original.

Feu que la ruta de la LAN arribi automàticament si podeu: una opció DHCP, un anunci de router o una ruta estàtica enviada per allò que gestiona la LAN. Una ruta que només existeix en una màquina de prova farà que el disseny sembli trencat en el moment que algú altre ho provi.

La resposta també necessita un camí

Un cop la petició arriba a la VPC, la resposta ha de tornar pels mateixos estats de traducció i trobar la ruta de la LAN a la passarel·la. Aquesta part normalment funciona quan la regla de masquerading hi és, perquè el mapatge viu a l’amfitrió que el va fer. Es trenca quan el costat de la VPC té una ruta que envia la resposta a un altre lloc, i per això tant la ruta del CIDR del client com l’associació de subxarxa al punt de connexió importen.

Mireu els comptadors, no només el ping. Una regla de masquerading amb zero paquets us diu que la petició no va arribar mai a la interfície de túnel, cosa que apunta a la ruta de la LAN o a la taula d’encaminament del propi client. Una regla amb paquets però sense respostes apunta al costat de la VPC, a les regles d’autorització o a un grup de seguretat que no accepta la font traduïda. Llegiu les dues direccions abans de canviar res, perquè un comptador que creix només en una banda és un camí d’un sol sentit, no un camí lent.

Recordeu que el punt de connexió és un servei gestionat. No hi ha cap fitxer de configuració de servidor per editar ni cap directiva client-config per afegir, així que les instruccions escrites per a un servidor OpenVPN autogestionat amb rutes personalitzades de subxarxa de client no es traslladen. A AWS les palanques són l’associació de subxarxa, les regles d’autorització i les taules d’encaminament de la VPC.

La identitat compartida és la part que la política ha de respondre

Cada dispositiu darrere la passarel·la utilitza la sessió VPN de la passarel·la. Les regles d’autorització del punt de connexió donen accés a un usuari o a un grup, i des del punt de vista del servei hi ha exactament un usuari en aquesta sessió. El reenviament local no multiplica aquesta identitat en autenticació per dispositiu, ni estén les comprovacions de postura del dispositiu a la impressora del racó.

Això pot ser acceptable, o pot ser la raó per la qual es rebutja el disseny. Depèn del que els recursos de la VPC assumeixen sobre qui truca. Una identitat compartida que encaixa amb el model d’autorització està bé; una que converteix en silenci una única sessió autenticada en accés a tota la LAN és una troballa que espera ser escrita.

Si el requisit és realment connectar un lloc sencer a una VPC, compareu un disseny recolzat lloc a lloc abans d’estendre un client d’accés remot. La semàntica és diferent, i una sessió de client amb NAT és un mal substitut d’un enllaç de lloc quan la VPC ha d’iniciar connexions cap a la LAN.

Decidiu el client, la ruta, la traducció i la història d’identitat en aquest ordre. Cadascun limita el següent, i l’ordre explica per què l’amfitrió funciona mentre la LAN no.