Groupe de sécurité cloud pour un VPN : ouvrir l'écoute, pas tout

Le serveur VPN tourne, le client expire, et le premier réflexe est d'ajouter une règle qui autorise tout au groupe de sécurité. Cela le fait parfois fonctionner, et c'est le pire résultat, car plus personne ne sait quelle frontière a réellement été fermée. Quatre filtres distincts se trouvent entre le client et le démon, et un seul d'entre eux est le groupe de sécurité.

Nommez le protocole avant la règle

Une règle, c'est un protocole, une plage de ports et une source. WireGuard écoute en UDP, généralement 51820. OpenVPN est généralement en UDP ou TCP 1194 selon la configuration. IPsec a besoin de son échange IKE sur UDP 500 et 4500, plus le protocole ESP lui-même, qui est un numéro de protocole et non un port. Deviner TCP parce que les autres règles sont en TCP, c'est ainsi qu'on obtient une règle qui semble correcte et qui ne correspond à rien.

Lisez l'écoute depuis le service en cours d'exécution, pas depuis un tutoriel. Un démon lié à une adresse n'acceptera pas le trafic arrivant sur une autre.

Limitez la source à la plage de clients que la conception autorise, plutôt qu'à tout Internet.

Les groupes de sécurité sont à état ; les ACL de sous-réseau ne le sont pas

Les groupes de sécurité sont à état et uniquement autorisants : un flux entrant autorisé reçoit ses réponses automatiquement, et il n'y a aucune règle de refus à considérer. Les ACL de sous-réseau sont sans état et évaluées dans les deux sens, donc une autorisation entrante sans la plage éphémère sortante correspondante échoue quand même. Cette différence explique beaucoup de règles qui semblent correctes dans la console.

Vérifiez aussi quelle stratégie est attachée au point de terminaison en cours d'exécution, car une instance peut avoir plusieurs groupes et une règle dans un groupe non attaché ne change rien.

La stratégie effective est l'union de ce qui est attaché, pas le fichier que vous avez modifié.

Le pare-feu de l'hôte est une frontière distincte

La stratégie cloud admet le trafic vers l'interface réseau, puis le système d'exploitation décide si le démon le voit. Un pare-feu d'hôte avec une stratégie de refus par défaut rejettera un paquet que le groupe de sécurité avait autorisé, et la console cloud n'affichera aucun refus parce qu'elle n'a jamais eu d'avis. Vérifiez les deux, dans l'ordre où le paquet les rencontre.

Si l'hôte utilise une interface de pare-feu de la distribution, vérifiez les règles sous-jacentes plutôt que le nom du profil, car un profil peut être actif alors que le port est fermé.

Une capture sur l'interface vous indique quelle frontière a rejeté le paquet.

Admettre l'écoute n'est pas router les clients

Une passerelle VPN qui transfère le trafic des clients a besoin de plus qu'un port ouvert. Il lui faut le transfert IP, une stratégie autorisant le flux de l'interface du tunnel vers le réseau de destination, et souvent le contrôle source-destination désactivé sur l'interface pour que la plateforme n'écarte pas le trafic qui ne lui est pas adressé. Rien de cela n'est créé par la règle d'écoute.

C'est là que se séparent une poignée de main fonctionnelle et un chemin de données cassé, et pourquoi l'état d'un tunnel peut sembler sain alors que rien ne se charge.

Corrigez le routage comme un changement distinct avec sa propre vérification, et notez qu'une passerelle qui transfère a aussi besoin d'une stratégie de sortie autorisant la destination.

Gardez un chemin de retour, puis resserrez la règle

Avant de modifier la stratégie de pare-feu distant, confirmez qu'il existe un chemin de gestion indépendant, comme un gestionnaire de session, une console série ou un réseau hors bande. Si le seul chemin de gestion passe par la règle que vous modifiez, vous n'avez pas de reprise. Appliquez ensuite la règle étroite, testez depuis un vrai client et corrélez la tentative avec des preuves côté serveur. Une réponse d'un autre service sur la même machine ne prouve pas que l'écoute a été atteinte.

Supprimez toute autorisation large expérimentale dès que l'étroite fonctionne, et notez pourquoi la règle existe. AWS documente le comportement à état des groupes de sécurité, et c'est ce document qu'il faut citer quand quelqu'un propose une plage large comme raccourci.

Documentez aussi l'attachement, sinon une interface de remplacement perdra la stratégie en silence.