Túnel complet d’Access Server a EC2: per què una casella no n’hi ha prou

Desactivar la comprovació d’origen i destinació en una instància EC2 és la resposta més repetida a les preguntes sobre la sortida a internet d’Access Server, i per si sola no fa res pels vostres clients. La comprovació és una restricció de reenviament d’AWS: fa que la instància accepti paquets l’origen o la destinació dels quals no és la seva pròpia adreça. No diu al client d’Access Server que enviï el trànsit d’internet pel túnel, no crea cap ruta aigües amunt ni afegeix NAT. El mite és que la casella és la funcionalitat.

Què controla realment la comprovació

Cada interfície de xarxa d’EC2 descarta el trànsit que no va adreçat a ella, tret que la instància faci de router, de dispositiu NAT o de passarel·la VPN i desactiveu aquesta comprovació. Desactivar-la concedeix permís per reenviar. El permís no és configuració: la instància encara necessita una ruta cap a una passarel·la d’internet o un dispositiu NAT, la taula de rutes de la VPC encara necessita l’entrada corresponent, els grups de seguretat encara han de permetre el flux, i el servidor encara ha de traduir o encaminar el trànsit de retorn.

Comproveu el valor actual amb aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck abans de canviar res. Si el canvieu a la consola, canvieu-lo perquè la instància reenvia per a altres, no perquè un client no arribi a internet.

Access Server és qui mana en la política d’encaminament del client

A Access Server 3, obriu Access Controls i trobeu la secció Internet Access and DNS. El selector Internet Gateway ofereix túnel complet o túnel dividit; el túnel complet diu al client que encamini el trànsit per defecte dins de la VPN, el túnel dividit deixa el trànsit d’internet al camí local del client. Deseu i apliqueu pel flux de treball del producte i després reconnecteu un client de prova, perquè la política es lliura en el moment de la connexió.

Les versions antigues fan servir menús diferents i algunes compilacions Community d’OpenVPN no tenen cap control equivalent. Comproveu la versió principal instal·lada abans de buscar una pantalla que no existeix. Després confirmeu què ha rebut el client: un perfil de túnel complet ha d’instal·lar una ruta per defecte pel túnel, i un perfil de túnel dividit no ho ha de fer.

Resseguiu el paquet després del túnel

Quan el client envia trànsit d’internet al túnel, el servidor l’ha de reenviar i normalment traduir. Access Server gestiona les seves pròpies regles de NAT i d’encaminament, així que llegiu la configuració efectiva en lloc d’afegir regles de Community OpenVPN als fitxers generats; les regles no gestionades se sobreescriuen o entren en conflicte a la propera actualització del producte. sudo iptables -t nat -L -n -v o l’equivalent d’nftables mostra què s’està traduint realment.

El costat d’AWS és un camí a part. Una instància en una subxarxa pública arriba directament a una passarel·la d’internet i conserva la seva adreça pública o la seva IP elàstica. Una instància en una subxarxa privada necessita una ruta cap a una passarel·la NAT o una instància NAT, i el dispositiu NAT necessita la seva pròpia ruta cap a la passarel·la d’internet. Adjuntar una passarel·la d’internet a la VPC no dona per si sola cap adreça pública de retorn a una font privada, i per això la mateixa configuració d’Access Server funciona en una subxarxa i falla en silenci en una altra.

Comproveu la taula de rutes associada a la subxarxa de la instància, no només la taula principal de la VPC. Les associacions de subxarxa prevalen sobre la taula principal, i una associació obsoleta és una causa habitual que una configuració funcional s’aturi després d’una reconstrucció.

Manteniu la sortida IP i el DNS per separat

Proveu primer un literal d’adreça i després un nom, des de la mateixa aplicació client. Si curl -4 https://checkip.amazonaws.com retorna una adreça pública però els noms d’amfitrió fallen, el túnel i el camí NAT funcionen i el problema és el DNS: el resolutor empès, l’estat del resolutor del client o un grup de seguretat que bloqueja el resolutor. Els paràmetres DNS d’Access Server són a la mateixa àrea Internet Access, però viatgen per un camí de codi diferent.

Compareu l’adreça retornada amb la sortida que volíeu. Si és l’adreça pública de la instància, el trànsit el tradueix la instància; si és una adreça de passarel·la NAT, s’usa el camí de la subxarxa privada. Totes dues poden ser correctes. El que no podeu concloure és que un navegador al servidor demostri el reenviament del client.

No deixeu que una casella tanqui la investigació

IPv6 és una decisió a part. Una política de túnel complet per a IPv4 no diu res sobre si IPv6 es transporta, es bloqueja o es filtra, i un client de doble pila pot continuar usant el seu camí IPv6 local mentre IPv4 va pel túnel. Proveu la família d’adreces que realment us importa i decidiu explícitament si l’altra s’ha de desactivar.

Finalment, proveu l’estat desconnectat. La selecció de túnel complet descriu la política d’encaminament mentre esteu connectat, no què passa quan el túnel cau. Si el requisit és que cap trànsit escapi fora de la VPN, això és una qüestió de kill-switch i tallafocs, i necessita la seva pròpia prova en lloc d’una deducció de la taula de rutes.