# Ouverture d’un flux entre deux zones du pare-feu SRX300 - Link: https://dpioch.aristeecampus.org/procedure/ouverture-flux-inter-zones-srx300/ - Published: 2026-10-05T15:13:00+02:00 - Author: Admin Version 1.0 Date d’édition 05/10/2026 _Ouvrir un flux précis entre deux zones du pare-feu, hôte par hôte et service par service, avec un retour arrière automatique tant que le test n’est pas concluant._ ## 1. Objet Le pare-feu SRX300 du laboratoire bloque par défaut tout trafic entre zones (voir HL-PRC-001). Chaque service qui doit être joint depuis une autre zone demande donc une politique explicite. Cette procédure décrit l’ajout d’une telle politique, de la vérification des noms de zones jusqu’au test depuis l’hôte source, puis le diagnostic d’un flux qui reste bloqué. Le cas de référence du 5 octobre 2026 utilise la politique `hermes-n8n` pour autoriser un client de la zone `lab` à joindre l’API de n8n publiée par le proxy inverse dans la zone `srv`. La démarche reste la même pour un autre client autorisé, avec les paramètres adaptés. ## 2. Périmètre et prérequis ### Périmètre Couvert : ouverture d’un flux d’un hôte vers un hôte, sur un service, entre deux zones existantes ; validation ; diagnostic ; retour arrière. Hors périmètre : création d’une zone ou d’une sous-interface, traduction d’adresses, flux entrants depuis Internet. ### Prérequis * Accès SSH au pare-feu avec le compte d’administration nominatif, depuis la zone d’administration. * Le besoin exprimé précisément : hôte source, hôte destination, service, sens du flux. * Un accès à l’hôte source pour tester le flux : un test lancé depuis une autre machine ne prouve rien. ## 3. Rôles et responsabilités | Rôle | Responsabilité | | **Demandeur** | Exprime le besoin (source, destination, service) et teste le flux depuis l’hôte source. | | **Administrateur réseau** | Saisit la politique, la valide, la confirme ou la laisse revenir en arrière. | Note **Cas de référence.** Le demandeur précise le besoin et teste depuis le client concerné. L’administrateur réseau saisit et contrôle la configuration du pare-feu ; l’ouverture du flux ne donne au client aucun accès d’administration au pare-feu. ## 4. Procédure ### Paramètres | Paramètre | Description | Valeur du cas de référence | | **ZONE_SOURCE** | Zone de l’hôte source | lab | | **ZONE_DEST** | Zone de l’hôte destination | srv | | **NOM_SOURCE** | Entrée du carnet d’adresses de la source | HERMES — 10.10.80.10/32 | | **NOM_DEST** | Entrée du carnet d’adresses de la destination | srv-proxy — 10.10.20.12/32 (Nginx Proxy Manager) | | **APPLICATION** | Service autorisé | junos-https (TCP 443) | | **POLITIQUE** | Nom de la politique, d’après son usage | hermes-n8n | ### 1. Vérifier les noms de zones Les noms de zones sont sensibles à la casse. Dans ce laboratoire, ils sont tous en minuscules : `adm`, `srv`, `dmz`, `cli`, `voip`, `dep`, `wfi`, `lab`, `untrust`. Un nom repris d’un brouillon sans vérification fait échouer le contrôle de cohérence. ``` # mode configuration [edit] run show security zones terse run show security policies from-zone lab to-zone srv ``` La seconde commande liste, dans l’ordre, les politiques déjà en place pour ce couple de zones. Repérer une éventuelle politique de refus : une nouvelle politique s’ajoute en fin de liste et resterait sans effet sous un refus. ### 2. Nommer la source et la destination Une politique ne désigne jamais une adresse IP directement : elle désigne des entrées du carnet d’adresses. Une adresse d’hôte en /32 limite l’ouverture à une seule machine. ``` set security address-book global address HERMES 10.10.80.10/32 set security address-book global address srv-proxy 10.10.20.12/32 ``` Si l’entrée existe déjà, c’était le cas de `HERMES` créée pour la politique `hermes- deploy`, la ligne peut être omise. ### 3. Choisir l’application Les services courants existent sous forme d’applications prédéfinies : `junos-ssh`,` junos-https`, `junos-http`, `junos-ping`. Un port spécifique demande une application personnalisée, comme celle créée pour l’API Proxmox : ``` set applications application pve-api protocol tcp destination-port 8006 ``` ### 4. Écrire la politique ``` set security policies from-zone lab to-zone srv policy hermes-n8n match source-address HERMES set security policies from-zone lab to-zone srv policy hermes-n8n match destination-address srv-proxy set security policies from-zone lab to-zone srv policy hermes-n8n match application junos-https set security policies from-zone lab to-zone srv policy hermes-n8n then permit ``` Si une politique de refus existe pour ce couple de zones, placer la nouvelle politique avant elle : ``` insert security policies from-zone lab to-zone srv policy hermes-n8n before policy ``` ### 5. Contrôler, puis appliquer avec retour automatique ``` show | compare commit check commit confirmed 5 ``` `show | compare` affiche exactement ce qui va changer : seules les lignes des étapes 2 à 4 doivent apparaître. `commit confirmed 5` applique la configuration et programme son annulation dans cinq minutes : si le test échoue ou si un accès est perdu, la configuration précédente revient d’elle-même. Ne pas enchaîner les trois commandes sans lire leur sortie. ### 6. Tester depuis l’hôte source Le test de ce flux doit être lancé depuis le client source défini dans la politique. Un essai depuis une autre machine fournit un diagnostic complémentaire, mais ne valide pas cette ouverture. ``` # ouverture du port, sans outil supplémentaire timeout 6 bash -c ' -o /dev/null -w '%{http_code}' https://n8n.srv.dozylab.lan/healthz; echo ``` Résultat obtenu le 5 octobre : port ouvert, code HTTP 200. Le certificat est vérifié par l’autorité racine interne émise par AD CS : la vérification TLS n’est jamais désactivée pour faire passer un test. ### 7. Confirmer ``` commit ``` Sans cette confirmation dans le délai, la politique est retirée automatiquement. ### Diagnostiquer un flux bloqué Lire le symptôme avant de toucher au pare-feu. | Symptôme | Signification | Suite | | **Délai dépassé, sans réponse** | Paquet abandonné : politique absente, zone mal identifiée, ou pare-feu de l’hôte | Consulter les sessions du pare-feu, ci-dessous. | | **Connexion refusée** | L’hôte est atteint ; le port est fermé ou le service restreint | Vérifier le service sur l’hôte destination. | | **Permission denied (publickey)** | Le réseau fonctionne ; c’est l’authentification SSH qui échoue | Voir la procédure d’accès SSH par clé. Ne pas modifier le pare-feu. | ``` # juste après une tentative, depuis le pare-feu run show security flow session destination-prefix 10.10.20.12 destination-port 443 ``` L’absence de session ne suffit pas à localiser le blocage : vérifier que le trafic atteint ce pare-feu, les zones, la route et l’ordre des politiques. Une session sans réponse impose aussi de contrôler le service destination et le chemin retour; elle ne prouve pas à elle seule un blocage sur l’hôte. Le cas de référence a commencé ainsi : depuis la zone `lab`, l’API de n8n ne répondait ni en 443 ni en 5678, avec un délai dépassé et aucun refus, alors que le même service répondait 200 depuis la zone `srv`. Le blocage venait donc du pare-feu, pas de n8n. ### Retour arrière | Situation | Action | | **Test non concluant pendant le délai** | Ne pas confirmer : la configuration précédente revient au bout de cinq minutes. | | **Politique confirmée, à retirer** | delete security policies from-zone lab to-zone srv policy hermes-n8n, puis commit ; ou rollback 1, puis commit. Attention : rollback 1 restaure toute la configuration du commit précédent, pas seulement cette politique. Vérifier show | compare et l’absence de changements concurrents avant de confirmer. | | **Saisie erronée, non appliquée** | rollback 0, puis show | compare, qui ne doit rien renvoyer. | ### Pièges connus | Message de commit check | Cause | Résolution | | **Security zone must be defined** | Nom de zone erroné ou mauvaise casse (SRV au lieu de srv) | Vérifier avec show security zones terse, supprimer le couple erroné, ressaisir. | | **Adresse non définie dans le carnet** | Adresse IP saisie directement dans la politique, ou faute de frappe dans le nom | Créer l’entrée du carnet d’adresses et désigner son nom. | | **Membre d’address-set invalide** | Un address-set ne contient que des noms d’entrées, jamais d’adresses | Pour un hôte unique, utiliser une entrée simple. | ## 5. Intégration réseau Exemples de politiques inter-zones documentées au 5 octobre 2026 pour WatchTower et le client de référence, chacune limitée à un hôte source, un hôte destination et un service : | Politique | Sens | Source → destination | Service | | **wt-proxmox** | srv → adm | WatchTower → API Proxmox | pve-api (TCP 8006) | | **hermes-deploy** | lab → srv | Client de référence → WatchTower | junos-ssh | | **hermes-n8n** | lab → srv | Client de référence → proxy inverse (n8n) | junos-https | Le client de référence n’a pas de flux ouvert vers l’API Proxmox : cette procédure ne lui attribue aucun droit d’administration sur l’hyperviseur. ## 6. Durcissement et sécurité * Une politique par besoin, nommée d’après son usage. Jamais l’ouverture d’un sous- réseau entier quand un hôte suffit. * Un service précis : pas d’`application any` entre zones de serveurs et de laboratoire. * Contournement à retirer : avant la politique `hermes-n8n`, l’API de n8n n’était joignable qu’en rebondissant par SSH sur WatchTower, avec l’accord explicite du propriétaire. Ce rebond n’a plus lieu d’être. * Chaque ouverture est reportée dans la matrice de flux du pare-feu (HL-PRC-001). ## 7. Vérifications finales | Contrôle | Critère d’acceptation | Statut | | **Noms de zones** | Identiques à la sortie de show security zones terse | ☐ | | **Différence** | show | compare ne montre que la politique et ses entrées | ☐ | | **Cohérence** | commit check renvoie « configuration check succeeds » | ☐ | | **Flux** | Depuis l’hôte source : port ouvert et service qui répond, certificat vérifié | ☐ | | **Moindre privilège** | Source et destination en /32, une seule application | ☐ | | **Confirmation** | commit effectué dans le délai ; la politique apparaît dans show security policies from-zone lab to-zone srv | ☐ | ## 8. Références et historique des révisions * HL-PRC-001 — Mise en service d’un pare-feu Juniper SRX300 : zones, carnet d’adresses et matrice de flux d’origine. * [Accès SSH par clé à un hôte du laboratoire](https://dpioch.aristeecampus.org/procedure/acces-ssh-par-cle-hote-laboratoire/): diagnostic côté hôte quand le réseau répond. * Juniper Networks — documentation Junos OS : politiques de sécurité, carnet d’adresses, commit confirmed. | Version | Date | Modifications | | 1.0 | 05/10/2026 | Création à partir du cas d’ouverture de la politique hermes-n8n ; démarche d’administration réseau et test depuis le client source. |