Túnel completo de Access Server en EC2: por que unha caixa non abonda

Desactivar a comprobación de orixe e destino nunha instancia EC2 é a resposta máis repetida ás preguntas sobre a saída a internet de Access Server, e por si soa non fai nada polos seus clientes. A comprobación é unha restrición de reenvío de AWS: fai que a instancia acepte paquetes cuxa orixe ou destino non é o seu propio enderezo. Non lle di ao cliente de Access Server que envíe o tráfico de internet polo túnel, non crea unha ruta augas arriba e non engade NAT. O mito é que a caixa é a funcionalidade.

Que controla realmente a comprobación

Cada interface de rede de EC2 descarta o tráfico que non vai dirixido a ela, salvo que a instancia actúe como router, dispositivo NAT ou pasarela VPN e vostede desactive esa comprobación. Desactivala concede permiso para reenviar. O permiso non é configuración: a instancia segue necesitando unha ruta cara a unha pasarela de internet ou un dispositivo NAT, a táboa de rutas da VPC segue necesitando a entrada correspondente, os grupos de seguridade seguen tendo que permitir o fluxo e o servidor segue tendo que traducir ou encamiñar o tráfico de retorno.

Comprobe o valor actual con aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck antes de cambiar nada. Se o cambia na consola, cámbieo porque a instancia reenvía para outros, non porque un cliente non chegue a internet.

Access Server é dono da política de encamiñamento do cliente

En Access Server 3, abra Access Controls e atope a sección Internet Access and DNS. O selector Internet Gateway ofrece túnel completo ou túnel dividido; o completo indica ao cliente que encamiñe o seu tráfico por defecto dentro da VPN, o dividido deixa o tráfico de internet na ruta local do cliente. Garde e aplique mediante o fluxo de traballo do produto e despois reconecte un cliente de proba, porque a política entrégase no momento da conexión.

As versións anteriores usan menús distintos e algunhas compilacións Community de OpenVPN non teñen un control equivalente. Comprobe a versión principal instalada antes de buscar unha pantalla que non existe. Despois confirme que recibiu o cliente: un perfil de túnel completo debería instalar unha ruta por defecto polo túnel, e un perfil de túnel dividido non debería facelo.

Siga o paquete despois do túnel

Cando o cliente envía tráfico de internet ao túnel, o servidor debe reenvialo e normalmente traducilo. Access Server xestiona as súas propias regras de NAT e de encamiñamento, así que lea a configuración efectiva en lugar de engadir regras de Community OpenVPN aos ficheiros xerados; as regras non xestionadas sobrescríbense ou entran en conflito na seguinte actualización do produto. sudo iptables -t nat -L -n -v ou o equivalente de nftables mostra que se está a traducir realmente.

O lado de AWS é unha ruta aparte. Unha instancia nunha subrede pública chega directamente a unha pasarela de internet e conserva o seu enderezo público ou a súa IP elástica. Unha instancia nunha subrede privada necesita unha ruta cara a unha pasarela NAT ou unha instancia NAT, e o dispositivo NAT necesita a súa propia ruta cara á pasarela de internet. Engadir unha pasarela de internet á VPC non dá por si soa un enderezo público de retorno a ningunha fonte privada, e por iso a mesma configuración de Access Server funciona nunha subrede e falla en silencio noutra.

Comprobe a táboa de rutas asociada á subrede da instancia, non só a táboa principal da VPC. As asociacións de subrede prevalecen sobre a táboa principal, e unha asociación obsoleta é unha causa habitual de que unha configuración que funcionaba se deteña tras unha reconstrución.

Manteña a saída IP e o DNS por separado

Probe primeiro un literal de enderezo e despois un nome, desde a mesma aplicación cliente. Se curl -4 https://checkip.amazonaws.com devolve un enderezo público pero os nomes de host fallan, o túnel e a ruta NAT funcionan e o problema é o DNS: o resolutor enviado, o estado do resolutor do cliente ou un grupo de seguridade que bloquea o resolutor. Os axustes de DNS de Access Server están na mesma área Internet Access, pero viaxan por unha ruta de código distinta.

Compare o enderezo devolto coa saída que pretendía. Se é o enderezo público da instancia, o tráfico tradúceo a instancia; se é un enderezo de pasarela NAT, úsase a ruta da subrede privada. Calquera das dúas pode ser correcta. O que non pode concluír é que un navegador no servidor demostre o reenvío para o cliente.

Non deixe que unha caixa peche a investigación

IPv6 é unha decisión aparte. Unha política de túnel completo para IPv4 non di nada sobre se IPv6 se transporta, se bloquea ou se filtra, e un cliente de dobre pila pode seguir usando a súa ruta IPv6 local mentres IPv4 vai polo túnel. Probe a familia de enderezos que realmente lle importa e decida explicitamente se a outra debe desactivarse.

Por último, probe o estado desconectado. A selección de túnel completo describe a política de encamiñamento mentres está conectado, non o que ocorre cando o túnel cae. Se o requisito é que ningún tráfico escape fóra da VPN, iso é unha cuestión de kill-switch e devasa, e necesita a súa propia proba en lugar dunha dedución da táboa de rutas.