Tunnel complet d’Access Server sur EC2 : pourquoi une case à cocher ne suffit pas

Désactiver la vérification source/destination sur une instance EC2 est la réponse la plus répétée aux questions sur la sortie internet d’Access Server, et à elle seule elle ne fait rien pour vos clients. La vérification est une contrainte de transfert d’AWS : elle fait accepter à l’instance des paquets dont la source ou la destination n’est pas sa propre adresse. Elle ne dit pas au client Access Server d’envoyer le trafic internet dans le tunnel, elle ne crée pas de route amont et elle n’ajoute pas de NAT. Le mythe, c’est que la case est la fonctionnalité.

Ce que la vérification contrôle réellement

Chaque interface réseau EC2 rejette le trafic qui ne lui est pas adressé, sauf si l’instance agit comme routeur, appareil NAT ou passerelle VPN et que vous désactivez cette vérification. La désactiver accorde la permission de transférer. La permission n’est pas la configuration : l’instance a toujours besoin d’une route vers une passerelle internet ou un appareil NAT, la table de routage du VPC a toujours besoin de l’entrée correspondante, les groupes de sécurité doivent toujours autoriser le flux, et le serveur doit toujours traduire ou router le trafic de retour.

Vérifiez la valeur actuelle avec aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck avant de changer quoi que ce soit. Si vous la modifiez dans la console, faites-le parce que l’instance transfère pour d’autres, pas parce qu’un client n’atteint pas internet.

Access Server maîtrise la politique de routage du client

Dans Access Server 3, ouvrez Access Controls et trouvez la section Internet Access and DNS. Le sélecteur Internet Gateway propose le tunnel complet ou le tunnel divisé ; le tunnel complet demande au client de router son trafic par défaut dans le VPN, le tunnel divisé laisse le trafic internet sur le chemin local du client. Enregistrez et appliquez via le flux de travail du produit, puis reconnectez un client de test, car la politique est livrée au moment de la connexion.

Les versions plus anciennes utilisent d’autres menus et certaines compilations Community d’OpenVPN n’ont pas de contrôle équivalent. Vérifiez la version majeure installée avant de chercher un écran qui n’existe pas. Confirmez ensuite ce que le client a reçu : un profil tunnel complet doit installer une route par défaut via le tunnel, et un profil tunnel divisé ne doit pas le faire.

Suivez le paquet après le tunnel

Une fois que le client envoie le trafic internet dans le tunnel, le serveur doit le transférer et généralement le traduire. Access Server gère ses propres règles NAT et de routage, alors lisez la configuration effective au lieu d’ajouter des règles Community OpenVPN aux fichiers générés ; les règles non gérées sont écrasées ou entrent en conflit à la prochaine mise à jour du produit. sudo iptables -t nat -L -n -v ou l’équivalent nftables montre ce qui est réellement traduit.

Le côté AWS est un chemin distinct. Une instance dans un sous-réseau public atteint directement une passerelle internet et conserve son adresse publique ou son IP élastique. Une instance dans un sous-réseau privé a besoin d’une route vers une passerelle NAT ou une instance NAT, et l’appareil NAT a besoin de sa propre route vers la passerelle internet. Attacher une passerelle internet au VPC ne donne pas à lui seul une adresse de retour publique à une source privée, et c’est pourquoi la même configuration Access Server fonctionne dans un sous-réseau et échoue silencieusement dans un autre.

Vérifiez la table de routage associée au sous-réseau de l’instance, pas seulement la table principale du VPC. Les associations de sous-réseau priment sur la table principale, et une association obsolète est une cause fréquente d’arrêt d’une configuration qui fonctionnait après une reconstruction.

Gardez la sortie IP et le DNS séparés

Testez d’abord un littéral d’adresse, puis un nom, depuis la même application cliente. Si curl -4 https://checkip.amazonaws.com renvoie une adresse publique mais que les noms d’hôtes échouent, le tunnel et le chemin NAT fonctionnent et le problème est le DNS : le résolveur poussé, l’état du résolveur du client, ou un groupe de sécurité qui bloque le résolveur. Les réglages DNS d’Access Server se trouvent dans la même zone Internet Access, mais ils empruntent un chemin de code différent.

Comparez l’adresse renvoyée à la sortie que vous vouliez. Si c’est l’adresse publique de l’instance, le trafic est traduit par l’instance ; si c’est une adresse de passerelle NAT, le chemin du sous-réseau privé est utilisé. Les deux peuvent être corrects. Ce que vous ne pouvez pas conclure, c’est qu’un navigateur sur le serveur prouve le transfert pour le client.

Ne laissez pas une case clore l’enquête

IPv6 est une décision distincte. Une politique de tunnel complet pour IPv4 ne dit rien sur le fait qu’IPv6 soit transporté, bloqué ou fuité, et un client double pile peut continuer d’utiliser son chemin IPv6 local pendant qu’IPv4 passe par le tunnel. Testez la famille d’adresses qui vous importe réellement, et décidez explicitement si l’autre doit être désactivée.

Enfin, testez l’état déconnecté. La sélection du tunnel complet décrit la politique de routage lorsque vous êtes connecté, pas ce qui se passe quand le tunnel tombe. Si l’exigence est qu’aucun trafic ne s’échappe hors du VPN, c’est une question de kill-switch et de pare-feu, et elle exige son propre test plutôt qu’une déduction à partir de la table de routage.