Vérifier la connectivité LAN sécurisée

Vérifiez que le SRX a assigné des adresses IP aux clients LAN.

Notez que les équipements ont les mêmes adresses MAC qu’auparavant (voir Connectivité par défaut SRX des filiales), mais ils sont désormais associés à différents sous-réseaux IP et unités IRB, en fonction de leur attribution VLAN respective. L’affichage confirme qu’au moins un équipement se trouve dans le vlan-trust, le guests, et les contractors VLAN. Cette sortie confirme que vos serveurs DHCP fonctionnent correctement au sein de chaque VLAN.

Vérifiez votre configuration VLAN.

La sortie confirme que vous avez correctement configuré les guests VLAN et contractors .

Vérifiez que les équipements du guests VLAN et de la zone peuvent accéder à Internet. Vous confirmez l’accès Internet avec un ping réussi pour www.juniper.net. Rappelez-vous que la conception de votre filiale indique que les invités ne sont autorisés qu’à envoyer du trafic HTTP/HTTPS et ping vers Internet.

Si votre guests équipement de zone prend en charge un client HTTP de ligne de commande, comme CURL, utilisez-le pour vérifier l’accès HTTP à Internet. Vous pouvez toujours utiliser un navigateur Web si l’équipement dispose d’une interface graphique pour tester la connectivité Web.

Nous ne nous donnerons pas la peine d'essayer de trouver une machine connectée à Internet pour confirmer que tous les autres services, c'est-à-dire SSH, Telnet, FTP, etc. ne fonctionneront pas. Une option ici consiste à supprimer temporairement la règle de stratégie qui autorise ICMP de la guests zone à la untrust zone. Une fois la modification prise en effet, le ping www.juniper.net doit être time-out.

Nous terminerons la validation du guests VLAN en confirmant que les équipements invités ne peuvent pas ping sur l'interface IRB dans les trust zones ou contractors .

Les pings vers les interfaces IRB dans les trust zones et contractors échouent, comme prévu. Bien que non affichés, les pings lancés par les invités vers les stations de terminaison dans les trust zones ou contractors échouent également. Encore une fois, vous avez besoin d’une politique explicite pour autoriser la circulation du trafic entre les zones. Pour les utilisateurs invités, la seule politique de sécurité en vigueur consiste à autoriser le trafic HTTP et ping vers la untrust zone.

Vérifiez que les employés de la trust zone peuvent accéder à Internet.

Vérifiez que les employés peuvent envoyer un ping aux sous-traitants.

La sortie montre que le ping n’a pas réussi. Reportez-vous à la section Déboguer les problèmes de connectivité pour plus d’informations sur la façon de déboguer ce problème.

Essayons de déboguer le problème de l'incapacité des employés à envoyer un ping aux sous-traitants. Nous utiliserons des options de traçage pour déboguer le flux de paquets lorsque les paquets passent de la trust zone à la contractors zone. Au minimum, la traceoptions configuration doit inclure un fichier cible et un indicateur. L’argument de la file commande spécifie le nom du fichier qui stocke la sortie de trace. Le ou les arguments de la flag commande définissent le type d’événements à retracer.

Une fois le traçage activé, générez des pings de la trust zone à la contractors zone. Lorsque les pings échouent, utilisez la show log <log_name> commande CLI et le find commutateur pour localiser rapidement les zones d’intérêt dans le fichier journal de trace.

Les entrées en surbrillance confirment que le trafic de test envoyé de la trust zone à la contractors zone est en cours d’abandon. Le message indique denied by policy default-policy-logical-system qu'il n'y a pas de stratégie pour autoriser ce trafic.

Vous devez disposer d’une stratégie pour autoriser la circulation du trafic entre les zones. Ajoutez la configuration ci-dessous pour configurer une stratégie de sécurité qui autorise les types de trafic souhaités entre la trust zone et la contractors zone. La configuration est au format configuration rapide, vous pouvez donc simplement la coller dans le SRX de la filiale à la [edit] hiérarchie :

Assurez-vous de valider vos modifications. Maintenant, le ping de la trust zone à la contractors zone devrait réussir. Maintenant que votre débogage est terminé, supprimez la configuration de traceoptions de flux de sécurité .

Vérifiez que les sous-traitants ne peuvent pas communiquer avec les clients dans les trust zones ou guests .

Seul le ping vers l’interface IRB (irb.30) doit réussir. Comme les adresses IP des clients peuvent changer avec les attributions DHCP mises à jour, nous choisissons de tester la connectivité inter-zone en ping sur l’interface IRB pour une zone donnée. Dans cet exemple, les adresses IP attribuées aux interfaces IRB sont statiques et ne changeront donc pas avec le temps.

Comme prévu, le ping d’un équipement de zone sous-traitant vers l’interface IRB de la contractors zone réussit. Maintenant, vous vérifiez le manque de connectivité aux trust zones et guests . Reportez-vous à la section Secure Local Branch Connectivity pour plus de détails sur les adresses attribuées aux interfaces IRB dans cet exemple.

La sortie montre que seul le ping vers 192.168.30.1 (assigné à irb.30) réussit. Cela confirme que les sous-traitants ne peuvent pas accéder aux trust zones et guests .

Vérifiez que les sous-traitants ne peuvent pas accéder à Internet.

Notez que la tentative de ping www.juniper.net renvoie un message d’échec de la recherche de nom d’hôte . Cette filiale n'a pas de serveur DNS local et s'appuie sur un service DNS public accessible uniquement par Internet. L’échec de la résolution du nom d’hôte est une bonne indication que les sous-traitants sont correctement bloqués d’accès à Internet. En dernière confirmation, envoyez un ping au serveur DNS public par son adresse IP. Là encore, le ping échoue comme prévu.

Ces résultats complètent la validation de la connectivité locale sécurisée des filiales. Bien fait! À l'étape suivante, nous vous montrerons comment établir une connectivité sécurisée sur Internet.