Zones Shorewall pour les deux chemins de paquets d’OpenVPN
Séparez le transport OpenVPN chiffré du trafic client déchiffré, donnez au tunnel sa propre zone et n’autorisez que le service dont le client a besoin.
Deux flux de paquets traversent une passerelle Shorewall qui termine OpenVPN, et un seul des deux est chiffré. Le premier est le transport du client jusqu’à l’écouteur VPN de l’interface tournée vers internet. Le second est la requête déchiffrée qui quitte l’interface du tunnel vers un serveur de bureau ou un service de la passerelle. Cartographiez les deux avant de modifier la politique, car une règle qui satisfait le premier ne fait rien pour le second.
Dessinez les deux flux avant de modifier la politique
Écrivez les flux sous forme de lignes avec source, destination, protocole et port. Sur le chemin externe, la source est l’adresse publique du client et la destination le port d’écoute de la passerelle ; Shorewall traite cela comme du trafic internet vers le pare-feu. Sur le chemin interne, la source est la plage d’adresses du tunnel et la destination le service approuvé. Les deux lignes ont des propriétaires différents même lorsqu’un seul administrateur maintient les deux.
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
N’ajoutez une ligne que si la requête se termine sur la passerelle elle-même, par exemple l’accès au résolveur ou à l’administration. Un service sur l’hôte suit la politique d’entrée de l’hôte, pas le chemin transféré. Mélanger les deux, c’est ainsi qu’une règle de tunnel étroite finit par exposer une interface d’administration.
Attribuez la zone du tunnel et la portée de l’interface
La zone du nomade est déclarée dans /etc/shorewall/zones, l’interface du tunnel est rattachée dans /etc/shorewall/interfaces et la connexion externe est décrite dans /etc/shorewall/tunnels. Adaptez-vous à la syntaxe de la version installée, car l’ordre des colonnes et les noms d’options ont changé entre versions majeures. Le port d’exemple du guide n’est pas une raison d’autoriser un port différent de celui sur lequel le démon écoute réellement. TCP et UDP ne sont pas interchangeables simplement parce que les numéros coïncident.
Le guide regroupe les interfaces avec tun+. Sur un hôte qui a plus d’un tunnel, ce joker peut placer un second VPN d’un autre niveau de confiance dans la même zone. Revoyez la portée par rapport aux interfaces qui existent réellement et gardez le nommage sous le cycle de vie du gestionnaire de connexions au lieu de modifier les noms d’interface à la main.
Le guide historique contient des exemples de configuration OpenVPN bien plus anciens, et ses conseils cryptographiques ne doivent pas être copiés dans un déploiement actuel. Empruntez plutôt le modèle de zones et de flux. Prenez la base cryptographique dans la politique OpenVPN maintenue de la passerelle.
N’autorisez que le chemin que vous avez classé
Une acceptation large de la zone VPN vers le LAN est un schéma de départ, pas une politique achevée. Écrivez la source client autorisée, l’adresse réelle du service, le protocole et le port. Lisez ensuite les règles au-dessus et la valeur par défaut de la zone, car un ajout étroit n’annule pas une autorisation large qui correspond déjà. Le trafic vers l’hôte de la passerelle est une relation distincte du trafic transféré à travers elle.
Le trafic entre clients demande sa propre décision. Le client-to-client d’OpenVPN et le routeback de Shorewall influent tous deux sur la possibilité pour les clients de s’atteindre, et aucun ne doit être activé juste pour faire fonctionner une application du LAN. Décidez où l’isolement est appliqué avant de le tester.
Gardez le chemin de retour dans le même plan. Le service ou son routeur doit savoir comment renvoyer le trafic vers la plage du tunnel, ou la conception doit traduire la source délibérément et dans la portée prévue.
Validez, puis prouvez les deux chemins
Validez la configuration avant de redémarrer quoi que ce soit, et gardez une session administrative indépendante ouverte au cas où la nouvelle politique serait erronée.
shorewall checkAprès une vérification propre, appliquez la configuration et relisez ce que Shorewall a chargé. Ces lectures décrivent la politique en cours d’exécution et non ce qu’un fichier semble dire.
shorewall show zones
ip route get 192.168.10.20Testez une requête autorisée fraîche et une requête refusée volontairement depuis le même client. Une poignée de main OpenVPN réussie ne prouve que l’échange externe ; le service autorisé et la ressource refusée prouvent la politique interne que vous vouliez. Reconnectez ensuite le client et répétez, car le nom et l’adresse de l’interface du tunnel peuvent changer entre les sessions. Si le résultat diffère, corrigez la portée de la zone au lieu d’élargir la règle.