LAN detrás dunha sesión de AWS Client VPN: que se reenvía

O portátil conéctase ao punto de conexión de AWS Client VPN, chega á subrede privada e todo parece saudable. O escritorio da mesma LAN non chega a nada, aínda que o host Linux tamén ten unha interface de ponte e ambas máquinas están no mesmo cable. Nada está mal configurado no túnel; a peza que falta é o enrutamento, e a ponte é unha pista falsa.

Estender unha sesión de Client VPN a unha LAN é un papel de pasarela. Non é un segmento Ethernet estirado dentro dun servizo xestionado.

O host funciona e a LAN non

A interface de túnel da máquina Linux ten un enderezo dentro do CIDR do cliente de Client VPN, e o punto de conexión enviou rutas para os rangos da VPC. Unha petición feita nesa máquina é tráfico xerado localmente: escolle unha ruta, sae polo túnel e obtén unha resposta. Ese camiño nunca toca o código de reenvío, a interface LAN nin ningunha regra de devasa que goberne o tránsito.

O tráfico doutro dispositivo da LAN é un fluxo distinto. Chega á interface LAN, precisa unha ruta que apunte ao túnel, precisa o reenvío activado, precisa unha devasa que o permita e precisa que a resposta volva polo mesmo host. Catro requisitos, e a proba que funciona co portátil non demostra ningún. Desde o escritorio o fallo parece estraño: o túnel está activo, as credenciais son válidas e o destino simplemente nunca responde. O defecto é local ao camiño de reenvío da pasarela, non ao servizo.

Non todos os clientes poden ser unha pasarela

AWS afirma que a súa aplicación de escritorio Client VPN non admite reenvío IP, e que outros clientes poderían facelo. Esa restrición decide a arquitectura antes de escribir ningún comando. Se o único cliente dispoñible é a aplicación oficial de escritorio, unha pasarela Linux que reenvía para a LAN non é unha configuración que poida rematar, e ningunha cantidade de masquerading o cambiará.

O cliente substituto tamén debe coincidir co método de autenticación do punto de conexión e coa política que pretende aplicar. Os puntos de conexión baseados en certificados, en directorio e con SAML non aceptan as mesmas configuracións de cliente, e un cliente de terceiros que se autentica pero ignora as rutas enviadas non é unha mellora.

Trate a elección do cliente como parte da revisión do deseño. Determina se o patrón de reenvío de LAN está dispoñible e determina que identidade ve o punto de conexión para cada dispositivo detrás da pasarela. Rexistre o cliente e a configuración do punto de conexión contra a que se probou. Un cambio de cliente seis meses despois pode eliminar en silencio a capacidade que o deseño asumía.

Dirixa a LAN ao túnel e tradúcea

Cun cliente compatible no seu sitio, o resto é traballo ordinario de pasarela. Os dispositivos da LAN necesitan unha ruta para o rango da VPC que apunte ao host Linux, e o host necesita o reenvío activado. Se quere que a VPC vexa o tráfico como o cliente conectado e non como un enderezo LAN arbitrario, traduza a orixe á saída.

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

Limite a regra á interface de túnel e ao rango da VPC, como arriba, en lugar de facer masquerading de todo o que reenvía o host. A regra máis estreita é máis fácil de razoar e non cambia en silencio tráfico que debía conservar o seu enderezo de orixe orixinal.

Faga que a ruta da LAN chegue automaticamente se pode: unha opción DHCP, un anuncio de router ou unha ruta estática empuxada por aquilo que xestiona a LAN. Unha ruta que só existe nunha máquina de proba fará que o deseño pareza roto no momento en que alguén máis o probe.

A resposta tamén precisa un camiño

Unha vez que a petición chega á VPC, a resposta debe volver polos mesmos estados de tradución e atopar a ruta da LAN na pasarela. Esa parte adoita funcionar cando a regra de masquerading está no seu sitio, porque o mapeamento vive no host que o fixo. Rompe cando o lado da VPC ten unha ruta que envía a resposta a outro lugar, e por iso importan tanto a ruta do CIDR do cliente como a asociación de subrede no punto de conexión.

Mire os contadores, non só o ping. Unha regra de masquerading con cero paquetes dille que a petición nunca chegou á interface de túnel, o que apunta de volta á ruta da LAN ou á propia táboa de enrutamento do cliente. Unha regra con paquetes pero sen respostas apunta ao lado da VPC, ás regras de autorización ou a un grupo de seguridade que non acepta a orixe traducida. Lea ambas direccións antes de cambiar nada, porque un contador que crece só nun lado é un camiño dun só sentido, non un lento.

Lembre que o punto de conexión é un servizo xestionado. Non hai ficheiro de configuración do servidor que editar nin directiva client-config que engadir, así que as instrucións escritas para un servidor OpenVPN autoxestionado con rutas personalizadas de subrede de cliente non se trasladan. En AWS as pólas son a asociación de subrede, as regras de autorización e as táboas de enrutamento da VPC.

A identidade compartida é a parte que a política debe responder

Cada dispositivo detrás da pasarela usa a sesión VPN da pasarela. As regras de autorización do punto de conexión conceden acceso a un usuario ou a un grupo, e desde o punto de vista do servizo hai exactamente un usuario nesa sesión. O reenvío local non multiplica esa identidade en autenticación por dispositivo, nin estende as comprobacións de postura do dispositivo á impresora do recuncho.

Iso pode ser aceptable, ou pode ser a razón pola que se rexeita o deseño. Depende do que os recursos da VPC asuman sobre quen chama. Unha identidade compartida que encaixa co modelo de autorización está ben; unha que converte en silencio unha única sesión autenticada en acceso a toda a LAN é un achado que agarda ser escrito.

Se o requisito é realmente conectar todo un sitio a unha VPC, compare un deseño admitido de sitio a sitio antes de estender un cliente de acceso remoto. A semántica é distinta, e unha sesión de cliente con NAT é un mal substituto dunha ligazón de sitio cando a VPC necesita iniciar conexións cara á LAN.

Decida o cliente, a ruta, a tradución e a historia de identidade nesa orde. Cada un limita o seguinte, e a orde explica por que o host funciona mentres a LAN non.