ufw allow 443 n'a rien fait pour un service derrière le VPN

Le ping réussit depuis un client VPN, le service TCP expire et ufw allow 443/tcp ne change absolument rien. Quand l'application tourne sur un hôte derrière la passerelle plutôt que sur la passerelle elle-même, cette autorisation a été écrite pour le mauvais chemin de trafic. Le paquet n'est pas adressé au pare-feu et n'est remis à aucun processus local, donc les règles d'entrée ne le voient jamais. La correction est une règle de route visant le flux transféré, et la preuve s'en trouve déjà dans le journal.

Décidez si la destination est locale ou transférée

Lisez le paquet tel que le noyau le voit. Le trafic remis à un service sur la passerelle est une entrée locale. Le trafic que la passerelle achemine vers un autre hôte est transféré, et UFW tient des jeux de règles distincts pour les deux chemins. La distinction est tranchée par l'adresse de destination et la recherche de route, non par l'interface par laquelle le paquet est arrivé.

Une ligne de journal montrant la même interface dans les champs IN et OUT peut encore décrire un paquet routé, car un tunnel qui fait entrer et sortir les clients d'un seul appareil ressemble exactement à cela. L'adresse de destination tranche la question plus vite que les noms d'interface. Voir deux fois le même nom ne prouve pas une remise locale, et inventer une interface de tunnel que le déploiement n'a jamais créée n'aide pas non plus.

Lisez le bloc avant d'ajouter la moindre règle

Reproduisez une tentative de connexion autorisée et relevez sa source, sa destination, son protocole et son port de destination tels que la passerelle les a enregistrés. Comparez ces quatre valeurs avec l'entrée de journal et avec l'emplacement réel du service. Un ping réussi plus tôt prouve seulement que son propre échange était autorisé, et un pare-feu peut traiter un TCP SYN vers une application de façon très différente.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

La première commande renvoie le verdict avec ses champs, et la seconde montre ce qui est déjà chargé et dans quel ordre. Lisez les deux avant de modifier quoi que ce soit, car un refus antérieur au-dessus de votre règle explique le même symptôme sans aucune règle manquante.

Écrivez la règle de route la plus étroite qui convienne

Dans cet exemple, les clients arrivent sur tun0 depuis 172.20.8.0/24, le service écoute sur 10.30.0.15 au port 8443, et la passerelle sort par ens5. Ces valeurs ont été choisies pour ne ressembler en rien à un défaut de VPC cloud de 10.0.0.0/16 ni à un réseau domestique de 192.168.0.0/16, et 8443 garde l'exemple loin de l'écouteur 443 de la passerelle elle-même.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

L'exécution à blanc imprime le jeu de règles qui en résulterait, ce qui est le moyen le moins coûteux de voir si votre règle se place avant ou après un refus existant. Vérifiez les noms d'interface et les adresses internes par rapport au déploiement et non à l'exemple, et rappelez-vous que lorsque la NAT de destination s'exécute en premier, le filtre voit la destination traduite.

Gardez le chemin de retour avec état

UFW suit les connexions autorisées, donc les réponses à un flux transféré autorisé sont admises sans règle inverse explicite. Ajouter une règle non restreinte dans la direction opposée pour que les choses fonctionnent élargit la politique bien au-delà du seul service et n'est pas nécessaire pour un échange demande-réponse normal. Gardez le chemin de retour implicite et le jeu de règles lisible.

N'appliquez la règle qu'une fois l'exécution à blanc conforme à votre intention, puis confirmez que la liste ordonnée la montre à la position attendue. Conservez l'écouteur VPN et les règles de gestion comme des sujets distincts, car les modifier est une décision différente de celle d'admettre une application. Notez le changement là où la topologie est écrite, afin que l'ingénieur suivant n'ait pas à le redécouvrir dans une capture de paquets.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Vérifiez ce qu'UFW ne peut pas imposer à votre place

Une règle correcte a encore besoin du transfert du noyau et d'une route qui atteint le service. Confirmez les deux avant d'accuser le pare-feu une seconde fois.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Regardez ensuite au-delà de l'hôte. Sur une instance cloud, la politique UFW de l'invité ne remplace pas les groupes de sécurité, les ACL de sous-réseau ni la configuration de transfert du fournisseur, donc un blocage local est une preuve concernant une couche et non la preuve que toutes les autres couches autorisent le service.

Terminez en testant une nouvelle connexion avec le pare-feu activé, depuis une source autorisée et depuis une autre sans rapport. Désactiver UFW supprime le symptôme et détruit la preuve dans la même commande, c'est pourquoi ce devrait être la dernière expérience et non la première.