Les redirections de port fourre-tout peuvent avaler votre écouteur WireGuard
Une règle de redirection large peut avaler les écouteurs WireGuard et SSH de la passerelle elle-même. Choisissez des règles étroites ou une adresse publique distincte, puis testez le chemin de contrôle.
Une passerelle publique fait déjà tourner WireGuard sur UDP 51820, SSH sur 22 et une application qui doit être joignable depuis l’internet. La règle tentante redirige chaque port vers le pair et déclare l’affaire réglée. Sur une passerelle WireGuard, cette règle peut capturer le transport propre du tunnel et vous enfermer dehors, hors de la machine qui le termine. Publier est une décision de routage avec une exception de plan de contrôle, pas une seule ligne DNAT.
Entrée publique, entrée par tunnel : choisissez
Publier un service crée un nouveau point d’entrée sur l’internet. Ce n’est pas la même chose que d’accorder une adhésion VPN à un pair, car le visiteur ne rejoint jamais le tunnel et la passerelle devient la face publique du backend. Cette distinction décide du public de la règle et de son certificat.
Les interfaces d’administration appartiennent rarement à cette position. Une page d’administration atteinte par des clients VPN autorisés garde sa surface d’attaque à l’intérieur du tunnel et évite d’exposer un formulaire de connexion à un balayage arbitraire. Les points de terminaison applicatifs publics ont toujours besoin de leur propre certificat TLS, d’une authentification et d’une limitation de débit ; le saut WireGuard chiffré ne protège pas la jambe du visiteur jusqu’à la passerelle.
Si le service doit vraiment être public, notez le nom d’hôte, le certificat qui le couvre et les plages de visiteurs qui doivent l’atteindre. Ces trois faits décident plus tard de la forme de la règle et de la politique de filtrage. Tout ce qui en sort est une dérive de périmètre sur un écouteur public.
Un port dedans, un backend dehors
Utilisez un seul port public et un seul service backend. Dans cet exemple, eth0 porte l’adresse publique 198.51.100.20, l’adresse de tunnel de la passerelle est 10.200.0.1 et le pair exécute l’application sur 10.200.0.7. Le TCP 9443 public est mappé vers le TCP 8443 du pair :
iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1La règle SNAT correspond au backend traduit et à la destination publique d’origine, si bien qu’une autre connexion au même service backend reste hors de ce mappage. Elle cache aussi l’adresse du visiteur au pair, et c’est le compromis qui fait d’un retour routé préservant la source un design à part. La référence des extensions iptables documente les deux cibles et leurs options de correspondance.
Le transfert doit toujours être activé, et la chaîne de filtrage a besoin d’une autorisation pour la destination et le port traduits, plus les réponses établies. La chaîne FORWARD voit la destination traduite après le DNAT, donc une règle écrite contre l’adresse publique ne correspond pas au paquet transféré. Écrivez l’autorisation contre le tuple du backend, pas contre le public.
Le pair doit accepter la connexion au service depuis l’adresse de tunnel de la passerelle et renvoyer la réponse par le tunnel. Son AllowedIPs doit autoriser la source qu’il reçoit réellement, qui, en traduction de source, est l’adresse de tunnel de la passerelle, et une entrée large 0.0.0.0/0 sur chaque pair n’est pas nécessaire pour ce design. Ce qui fait tomber le trafic de retour, c’est un pair dont la liste omet cette adresse, ou un design préservant la source qui transfère l’adresse du visiteur elle-même ; vérifiez donc la source que le pair voit vraiment, pas celle de votre règle.
Gardez les écouteurs de la passerelle hors de la règle
Remplacez la correspondance de port par une règle couvrant chaque destination TCP et UDP, et la socket WireGuard de la passerelle tombe dedans. La traduction de destination a lieu avant que la machine décide qu’un paquet est local, donc UDP 51820 peut finir chez le pair plutôt que chez le processus qui tient chaque connexion de pair. La règle se charge avec succès et le tunnel meurt, une panne difficile à lire depuis le côté pair.
SSH, les agents de supervision et tout autre service hébergé sur la passerelle ont la même exposition. Une règle qui transfère tout ne distingue pas le plan de contrôle de l’application publiée, et le premier redémarrage après le changement est le moment où le verrouillage devient évident. La règle fourre-tout n’avertit pas du service qu’elle reprend en silence. Vous le découvrez à la connexion suivante qui échoue.
Si le transfert large est vraiment nécessaire, réservez les ports de contrôle avant la règle fourre-tout ou utilisez une adresse publique distincte pour la publication. La seconde option est plus propre car l’adresse de contrôle garde sa propre politique, mais le fournisseur doit livrer cette adresse ; ajouter un enregistrement DNS n’en alloue pas une.
Le transfert large TCP et UDP n’est pas non plus tous les protocoles. ICMP, IPv6, la rétroaction MTU de chemin et le transport VPN extérieur ont besoin de leur propre politique, et une règle qui couvre TCP et UDP laisse ces cas à la chaîne par défaut.
Choisissez le modèle avant d’écrire des règles
Quatre formes couvrent la plupart des publications de passerelle, et le choix dépend du nombre de services que vous exécutez et du risque de plan de contrôle que vous tolérez. Le tableau ci-dessous les ordonne de la plus étroite à la plus large.
| Model | What it protects | Cost | Use when |
|---|---|---|---|
| Narrow port forward | Every other listener, including the VPN | One rule per service | Few services, stable ports |
| Catch-all with reserved ports | Ports named in the exception list | Rule order becomes critical | Many services and disciplined review |
| Separate public address | Control address fully isolated | Provider must supply the address | High-value publication |
| VPN-only access | No public entry at all | Visitors need the tunnel | Admin interfaces and internal tools |
Commencez par le modèle étroit même si vous attendez plus de services plus tard. C’est le plus facile à auditer, et convertir un ensemble de règles étroites en une règle fourre-tout revue est plus simple que de découvrir quel écouteur une règle large a capturé. Quel que soit le modèle choisi, gardez les règles chez le propriétaire du pare-feu. Appliquer des lignes iptables à côté d’une configuration UFW ou nftables qui gère aussi les mêmes chaînes produit une politique qui change selon l’ordre de démarrage.
Prouvez la publication et le chemin de contrôle
Testez depuis un client externe autorisé avec le nom d’hôte approuvé et un certificat valide pour lui. Confirmez quel backend a répondu, puis vérifiez que les ports publics sans rapport restent refusés. Une vérification de certificat désactivée n’est pas un test HTTPS réussi, et une connexion qui atteint le mauvais backend est pire qu’une connexion échouée.
Ensuite, vérifiez la passerelle elle-même : connectez un pair WireGuard, ouvrez une session SSH et confirmez que la supervision rapporte encore. Le service publié peut fonctionner alors que le plan de contrôle est cassé, donc les deux contrôles appartiennent à la même fenêtre de changement. Redémarrez une fois pour prouver que les règles sont réappliquées dans l’ordre attendu, puis retirez la publication et confirmez que le retrait correspond bien à l’ajout. Un grand ensemble d’ajouts au démarrage avec un retrait incomplet, voilà comment un test temporaire devient une ouverture permanente.