Túnel completo de Access Server en EC2: por qué una casilla no basta

Desactivar la comprobación de origen y destino en una instancia EC2 es la respuesta más repetida a las preguntas sobre la salida a internet de Access Server, y por sí sola no hace nada por sus clientes. La comprobación es una restricción de reenvío de AWS: hace que la instancia acepte paquetes cuyo origen o destino no es su propia dirección. No le dice al cliente de Access Server que envíe el tráfico de internet por el túnel, no crea una ruta aguas arriba y no añade NAT. El mito es que la casilla es la función.

Qué controla realmente la comprobación

Cada interfaz de red de EC2 descarta el tráfico que no va dirigido a ella, salvo que la instancia actúe como router, dispositivo NAT o pasarela VPN y usted desactive esa comprobación. Desactivarla concede permiso para reenviar. El permiso no es configuración: la instancia sigue necesitando una ruta hacia una pasarela de internet o un dispositivo NAT, la tabla de rutas de la VPC sigue necesitando la entrada correspondiente, los grupos de seguridad siguen teniendo que permitir el flujo y el servidor sigue teniendo que traducir o encaminar el tráfico de retorno.

Compruebe el valor actual con aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck antes de cambiar nada. Si lo cambia en la consola, cámbielo porque la instancia reenvía para otros, no porque un cliente no llegue a internet.

Access Server es dueño de la política de encaminamiento del cliente

En Access Server 3, abra Access Controls y busque la sección Internet Access and DNS. El selector Internet Gateway ofrece túnel completo o túnel dividido; el completo indica al cliente que encamine su tráfico por defecto dentro de la VPN, el dividido deja el tráfico de internet en la ruta local del cliente. Guarde y aplique mediante el flujo de trabajo del producto, y después reconecte un cliente de prueba, porque la política se entrega en el momento de la conexión.

Las versiones anteriores usan menús distintos y algunas compilaciones Community de OpenVPN no tienen un control equivalente. Compruebe la versión principal instalada antes de buscar una pantalla que no existe. Después confirme qué recibió el cliente: un perfil de túnel completo debería instalar una ruta por defecto por el túnel, y un perfil de túnel dividido no debería hacerlo.

Siga el paquete después del túnel

Cuando el cliente envía tráfico de internet al túnel, el servidor debe reenviarlo y normalmente traducirlo. Access Server gestiona sus propias reglas de NAT y de encaminamiento, así que lea la configuración efectiva en lugar de añadir reglas de Community OpenVPN a los archivos generados; las reglas no gestionadas se sobrescriben o entran en conflicto en la siguiente actualización del producto. sudo iptables -t nat -L -n -v o el equivalente de nftables muestra qué se está traduciendo realmente.

El lado de AWS es una ruta aparte. Una instancia en una subred pública llega directamente a una pasarela de internet y conserva su dirección pública o su IP elástica. Una instancia en una subred privada necesita una ruta hacia una pasarela NAT o una instancia NAT, y el dispositivo NAT necesita su propia ruta hacia la pasarela de internet. Adjuntar una pasarela de internet a la VPC no da por sí sola una dirección pública de retorno a ninguna fuente privada, y por eso la misma configuración de Access Server funciona en una subred y falla en silencio en otra.

Revise la tabla de rutas asociada a la subred de la instancia, no solo la tabla principal de la VPC. Las asociaciones de subred prevalecen sobre la tabla principal, y una asociación obsoleta es una causa habitual de que una configuración que funcionaba se detenga tras una reconstrucción.

Mantenga la salida IP y el DNS por separado

Pruebe primero un literal de dirección y luego un nombre, desde la misma aplicación cliente. Si curl -4 https://checkip.amazonaws.com devuelve una dirección pública pero los nombres de host fallan, el túnel y la ruta NAT funcionan y el problema es el DNS: el resolutor enviado, el estado del resolutor del cliente o un grupo de seguridad que bloquea el resolutor. Los ajustes de DNS de Access Server están en la misma área Internet Access, pero viajan por una ruta de código distinta.

Compare la dirección devuelta con la salida que pretendía. Si es la dirección pública de la instancia, el tráfico lo traduce la instancia; si es una dirección de pasarela NAT, se usa la ruta de la subred privada. Cualquiera de las dos puede ser correcta. Lo que no puede concluir es que un navegador en el servidor demuestre el reenvío para el cliente.

No deje que una casilla cierre la investigación

IPv6 es una decisión aparte. Una política de túnel completo para IPv4 no dice nada sobre si IPv6 se transporta, se bloquea o se filtra, y un cliente de pila doble puede seguir usando su ruta IPv6 local mientras IPv4 va por el túnel. Pruebe la familia de direcciones que realmente le importa y decida explícitamente si la otra debe desactivarse.

Por último, pruebe el estado desconectado. La selección de túnel completo describe la política de encaminamiento mientras está conectado, no qué ocurre cuando el túnel cae. Si el requisito es que ningún tráfico se escape fuera de la VPN, eso es una cuestión de kill-switch y cortafuegos, y necesita su propia prueba en lugar de una deducción de la tabla de rutas.