Zone VPN d’OpenWrt, transfert et masquage : laquelle choisir ?

Trois changements se mélangent dès qu’un VPN rencontre OpenWrt : ouvrir un port, autoriser le transfert et activer le masquage. Ils répondent à des questions différentes, et en général un seul d’entre eux est le véritable besoin. Lire chaque contrôle selon le rôle du trafic qu’il gouverne transforme une supposition en décision, et indique aussi quel symptôme attendre quand le changement est erroné. Commencez par nommer le rôle qui a échoué, pas la case que vous retenez.

Nommez le rôle du trafic avant de toucher un contrôle

L’entrée de zone décide de ce qui peut atteindre le routeur lui-même. La sortie de zone couvre le trafic que le routeur produit, le transfert de zone est la valeur par défaut pour le trafic qui traverse une zone, et le masquage décide si l’adresse source est réécrite en sortie. Ce sont quatre questions différentes, et une politique de zone y répond toutes à la fois avec la même valeur, ce qui fait d’un changement sur toute la zone un instrument grossier. Une règle nommée peut répondre à l’une d’elles sans toucher aux autres.

La carte utile est par rôle du trafic, car c’est ce que vous pouvez observer quand quelque chose échoue. Chaque rôle ci-dessous a un contrôle qui le décide et un symptôme qui le désigne :

Un service à l’écoute sur le routeur a besoin d’une seule règle d’entrée étroite

Un serveur OpenVPN sur le routeur reçoit du trafic adressé au routeur, donc sa connexion extérieure dépend de la politique d’entrée de la zone qui le porte. Autorisez le transport et le port configurés et laissez tout le reste de cette zone en rejet. Une seule règle de port est un changement bien plus petit qu’une acceptation sur toute la zone, et c’est celle que vous pourrez encore expliquer un an plus tard.

Deux choses rendent cette règle sûre à conserver : elle nomme le port que le service utilise réellement, et elle se trouve à côté de la définition de la zone pour que la personne suivante voie pourquoi elle existe. Les lignes ci-dessous sont la forme, avec le port à la place de ce qui est configuré sur le serveur. Changez ce port aux deux endroits quand le service déménage, car une règle restée sur l’ancien est invisible jusqu’à un audit.

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

Validez avant de recharger, car une erreur de syntaxe dans un fichier de pare-feu peut laisser le routeur sans jeu de règles fonctionnel. Sur une version qui utilise fw4, la vérification est une commande séparée, et elle échoue bruyamment au lieu d’accepter silencieusement un bloc cassé. Ne rechargez qu’après la réussite de la vérification, et gardez le fichier précédent là où vous pouvez le remettre.

fw4 check
service firewall reload

La requête d’un client passe par le transfert, pas par l’entrée

Après l’authentification, la requête d’un client de tunnel vers un service du LAN produit un flux transféré, donc le contrôle qui la décide est la relation de transfert entre la zone du tunnel et la zone LAN. Affectez l’interface du tunnel à la zone voulue, puis déclarez la direction, les sources et le service. L’affectation de zone est ce qui donne un sens à la règle de transfert, et les deux ne se comprennent que lues ensemble. Une relation de transfert qui nomme la zone du tunnel comme source et la zone LAN comme destination se lit comme une décision délibérée, tandis que deux acceptations sur toute la zone se lisent comme un accident.

Atteindre le routeur lui-même emprunte encore le chemin d’entrée, c’est pourquoi un ping vers la passerelle ne dit rien du partage de fichiers derrière elle. Ces deux échecs vivent dans des blocs différents et se corrigent par des modifications différentes. Écrivez les deux chemins séparément avant de changer l’un ou l’autre.

Le masquage est une décision de routage, pas une autorisation

Le masquage réécrit l’adresse source du trafic sortant sélectionné. Il peut sauver une conception de sortie où le côté distant n’a pas de route de retour, et il cache aussi les adresses des clients individuels à tout service qui journalise ou autorise par adresse. Le désactiver est un choix de routage sur le chemin de retour, pas un interrupteur de sécurité qui ferme un trou entrant. Un tunnel qui fonctionne avec la traduction activée et échoue à l’instant où elle est désactivée a généralement une route de retour manquante, pas une règle de pare-feu manquante.

L’alternative routée nécessite une route de retour du côté distant au lieu de la traduction. Aucune des deux options ne fournit l’autorisation du pare-feu ni le compte applicatif, c’est pourquoi désactiver le masquage ne répare presque jamais un client de tunnel qui n’atteint rien. Traitez aussi les politiques IPv4 et IPv6 séparément, car un seul réglage de traduction ne décrit pas les deux familles.

Prouvez la décision avec une requête autorisée et une refusée

Envoyez une requête qui devrait être autorisée et une qui devrait être refusée, puis identifiez le contrôle qui a pris chaque décision. Une page qui se charge par hasard n’est pas une preuve ; la preuve est la règle qui a correspondu, dans la chaîne où elle a correspondu. Le refus compte autant que le succès, car il montre que la politique fait quelque chose au lieu que tout soit permis.

Deux commandes vous donnent cette preuve sur une version actuelle. Le compteur de la règle correspondante bouge quand la requête est acceptée, et le journal montre le rejet si vous avez activé la journalisation pour la règle :

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

Gardez un chemin d’administration encore utilisable avant de changer toute politique de pare-feu, et suivez le processus de validation et de retour du propriétaire de la configuration. Un changement qui vous enferme hors du routeur n’est pas un résultat de test, c’est un second incident. Notez la zone et le rôle du trafic à côté de chaque observation, pour que la paire de résultats explique la politique au lieu de décrire un chargement de page chanceux.