Pare-feu cloud contre pare-feu de l’hôte pour un serveur VPN

Autorisez le port VPN dans la politique cloud et la poignée de main peut quand même mourir sur l’instance : l'hôte exécute son propre filtre et sa propre liaison de listener, et l’un ou l’autre peut écarter ce que le cloud a approuvé. L’inverse arrive aussi, quand une règle de l’hôte autorise le port et qu’une politique en amont le rejette d’abord. Deux propriétaires, deux jeux de règles, un seul chemin de paquets. Parcourez-le dans l’ordre au lieu de deviner à la couche la plus suspecte.

Commencez par la bordure et avancez vers l’intérieur

L’ordre est fixe : point de terminaison public, interface de ressource, politique cloud attachée, adresse de l’hôte, listener du processus, règles d’entrée locales. Chaque étape laisse passer le paquet ou termine l’enquête, et c’est pourquoi commencer par l’hôte fait perdre le plus de temps.

Le trafic client redirigé est une étape distincte, examinée après la décapsulation du tunnel. La couche cloud ne voit que le tunnel extérieur, donc elle peut approuver une connexion sans avoir rien à voir avec une requête de service interne. Un tunnel qui se connecte mais n’atteint pas un hôte interne pointe généralement vers le transfert, pas vers un port fermé.

Lisez la politique cloud avant de toucher à l’hôte

Confirmez la règle d’entrée du port VPN, son protocole et la portée source qui correspond à votre client de test. Vérifiez aussi la liste de contrôle d’accès du sous-réseau : un second filtre avec ses propres règles et valeurs par défaut. Les deux doivent autoriser le flux avant qu’un paquet atteigne l’instance. Une autorisation dans l’un et un refus dans l’autre est la forme habituelle de ce défaut.

Réduisez la portée jusqu’à ce qu’elle signifie quelque chose. Ouvrir le port VPN à tout Internet est facile à prouver et difficile à défendre, tandis qu’une règle épinglée à une adresse casse dès que votre client de test change de réseau. Notez l’identifiant de la règle et le propriétaire de la politique, pour que le prochain changement soit traçable jusqu’à une personne.

Confirmez le listener, puis la chaîne d’entrée

Sur l’instance, vérifiez que le processus VPN est lié à l’adresse et au port attendus, par exemple avec ss -lntp 'sport = :1194'. Un démon lié uniquement à 127.0.0.1 accepte les clients locaux et rien à travers le tunnel, ce qui ressemble de l’extérieur exactement à un port filtré.

Lisez ensuite les règles locales dans la syntaxe que vous utiliseriez pour les modifier, comme iptables -S INPUT ou nft list chain inet filter input. Une règle écrite dans un fichier mais jamais chargée, ou un rejet par défaut sans autorisation correspondante, écarte les paquets en silence. Pour une passerelle qui transfère, vérifiez aussi les réglages de transfert et de chemin inverse. Ils décident de ce qui arrive aux paquets routés à travers l’instance plutôt qu’adressés à elle.

Avec état dans une couche, sans état dans la suivante

Les groupes de sécurité se souviennent des flux qu’ils ont autorisés et laissent revenir les réponses. Les listes de contrôle d’accès des sous-réseaux et beaucoup de pare-feu d’hôte ne tiennent pas cet état, donc une règle qui ne couvre que la direction sortante laisse passer la requête et écarte la réponse. Ne transportez jamais une supposition sur le trafic de retour entre couches sans lire la règle de la seconde couche.

Les compteurs tranchent plus vite que la lecture de chaque règle du compte. Un compteur qui monte signifie que le paquet est arrivé et a été écarté là, tandis qu’un compteur figé à zéro signifie qu’il n’est jamais allé si loin ; iptables -vnL INPUT et nft list ruleset affichent ces valeurs quand les règles ont été chargées avec des compteurs.

Testez avec une session neuve, pas avec une session active

Laissez le réseau source et le profil de test tranquilles pendant que vous comparez les vues, et ouvrez une nouvelle connexion après chaque changement. Atteindre la console web sur 443 ne dit rien sur le fait que le démon VPN soit lié à 1194, alors testez le port dont vous avez besoin. Une session existante est le pire témoin ici. Elle continue de fonctionner alors que chaque nouvelle connexion est refusée.

Avant de modifier une politique distante, assurez-vous un chemin de retour qui ne dépende pas du chemin que vous changez. Ouvrez ensuite une seconde session d’administration à côté du test VPN : une session établie plus tôt peut survivre à la règle qui bloque les nouvelles. Notez les deux propriétaires des politiques pour qu’aucune reconstruction ne restaure la moitié du chemin ; si les deux couches sont d’accord et que le tunnel échoue encore, capturez sur l’interface de l’hôte et vérifiez l’adresse et le port que le client utilise vraiment.