[Dr.WoW] [N ° 20] NAT bidirectionnel

3 0 0 0


Avec la description dans les sections précédentes, je pense que vous savez ce que sont le NAT source et le serveur NAT. Avec les deux fonctions NAT, un pare-feu traduit facilement et efficacement le trafic entrant et sortant. Eh bien, les deux fonctions NAT peuvent-elles fonctionner ensemble? La réponse est définitivement oui".
Si les adresses source et de destination des paquets doivent être traduites, le NAT source et le serveur NAT sont requis. Cette configuration s'appelle également "NAT bidirectionnel". Notez que le NAT bidirectionnel n'est pas une fonction indépendante. Au lieu de cela, il ne s'agit que d'une combinaison de NAT source et de serveur NAT. Cette combinaison s'applique au même flux (par exemple, un paquet d'un utilisateur Internet à un serveur intranet). Lors de la réception du paquet, le pare-feu traduit ses adresses de source et de destination. Si le NAT source et le serveur NAT sont configurés sur un pare-feu pour différents flux, la configuration n'est pas appelée NAT bidirectionnel.

Pour vous aider à comprendre le NAT source, supposons le réseau dans lequel les utilisateurs intranet accèdent à Internet et vérifions la configuration du NAT source dans ce réseau. En réalité, le NAT source peut être classifié en NAT interzone et NAT intrazone en fonction des directions de transmission de paquets sur le pare-feu.

  • NAT interzone
La NAT est effectuée sur le paquet transmis entre les zones de sécurité. Le NAT Interzone peut également être classé dans les types suivants en fonction des directions de transmission de paquets:

-NAT entrant

La NAT est effectuée sur les paquets transmis d'une zone de sécurité de bas niveau à une zone de sécurité de haut niveau. En règle générale, un tel NAT s’applique lorsque les utilisateurs Internet accèdent à un intranet et cette technique est donc rarement utilisée.

-NAT sortant

La NAT est effectuée sur les paquets transmis d'une zone de sécurité de haut niveau à une zone de sécurité de bas niveau. Un tel NAT s'applique lorsque les utilisateurs de l'intranet accèdent à Internet, ce qui est un scénario courant.

  • Intrazone NAT
NAT est effectuée lorsque des paquets sont transmis dans une zone de sécurité. En général, le NAT intrazone fonctionne avec le serveur NAT. Intrazone NAT est rarement configuré séparément.

Lorsque le NAT intrazone ou interzone fonctionne avec un serveur NAT, un NAT bidirectionnel est implémenté. Bien entendu, les conditions préalables de la description précédente sont le paramétrage correct des niveaux de sécurité pour les zones de sécurité et une planification de réseau appropriée: l'intranet appartient à la zone de confiance (avec un niveau de sécurité élevé); les serveurs intranet appartiennent à la zone démilitarisée (avec un niveau de sécurité moyen); et Internet appartient à la zone de confiance (avec un niveau de sécurité faible).

Le NAT bidirectionnel n’est pas particulier en termes de technologies et de principes de mise en œuvre, mais son scénario applicable a des caractéristiques. Quand un NAT bidirectionnel est-il requis? Quels sont les avantages après la configuration du NAT bidirectionnel? Est-ce correct si je ne configure pas de NAT bidirectionnel? Ces questions doivent être prises en compte pour la planification et le déploiement de réseaux en direct.

1 serveur NAT entrant + serveur NAT
La figure 1-1 illustre un scénario typique de serveur NAT dans lequel un utilisateur Internet accède à un serveur intranet. La partie suivante décrit comment configurer et appliquer un NAT bidirectionnel dans ce scénario et les avantages du NAT bidirectionnel.

Figure 1-1 Mise en réseau pour le serveur NAT Inbound + NAT

224507iiegptv1g0elayae.png
Le serveur NAT et le NAT source sont configurés comme suit. Les configurations de la politique de sécurité et de la route noire sont identiques à celles fournies dans les sections précédentes et sont donc omises dans cette partie. Regardons d'abord la configuration du serveur NAT.
[FW] nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80

Je pense que vous n’avez aucun doute sur la configuration du serveur NAT. Une fois la configuration terminée, la mappe de serveur suivante est générée sur le pare-feu:

[FW] display firewall server-map

server-map item(s)

 ------------------------------------------------------------------------------

 Nat Server, any -> 1.1.1.1:9980[10.1.1.2:80], Zone: ---

   Protocol: tcp(Appro: unknown), Left-Time: --:--:--, Addr-Pool: ---

   VPN: public -> public

 

 Nat Server Reverse, 10.1.1.2[1.1.1.1] -> any, Zone: ---

   Protocol: any(Appro: ---), Left-Time: --:--:--, Addr-Pool: ---

   VPN: public -> public

Ensuite, regardons la configuration NAT source.

[FW] nat address-group 1 10.1.1.100 10.1.1.100

[FW] nat-policy interzone untrust dmz inbound

[FW-nat-policy-interzone-dmz-untrust-inbound] policy 1

[FW-nat-policy-interzone-dmz-untrust-inbound-1] policy destination 10.1.1.2 0   //As NAT Server is performed prior to Source NAT, the destination address here is the post-NAT Server address, namely, the private address of the server.

[FW-nat-policy-interzone-dmz-untrust-inbound-1] action source-nat

[FW-nat-policy-interzone-dmz-untrust-inbound-1] address-group 1

[FW-nat-policy-interzone-dmz-untrust-inbound-1] quit

[FW-nat-policy-interzone-dmz-untrust-inbound] quit

La configuration NAT source est différente de celle décrite dans la section précédente. La différence est que le pool d'adresses NAT ici a des adresses privées, pas des adresses publiques. En outre, la direction de la stratégie NAT est entrante, indiquant que cette opération est effectuée lorsque des paquets passent d'une zone de sécurité de bas niveau à une zone de sécurité de haut niveau. Cette configuration NAT est NAT Inbound.

Une fois la configuration terminée, lorsque l'utilisateur Internet accède au serveur intranet, nous pouvons afficher la table de session sur le pare-feu. Le résultat de la commande indique que les adresses source et de destination du paquet ont été traduites.

[FW] display firewall session table

Current Total Sessions : 1

  http  VPN:public --> public 1.1.1.2:2049[10.1.1.100:2048]-->1.1.1.1:9980[10.1.1.2:80]

Voyons le processus NAT comme indiqué à la figure 1-2. Une fois que le paquet de l'utilisateur Internet au serveur intranet est arrivé au pare-feu, le serveur NAT traduit l'adresse de destination (adresse publique du serveur intranet) en une adresse privée et NAT Inbound traduit l'adresse source en une adresse privée du même réseau. segment comme adresse du serveur. De cette manière, les adresses source et de destination du paquet sont toutes deux traduites, mettant en œuvre un NAT bidirectionnel. Lorsque le paquet de réponse du serveur intranet arrive au pare-feu, la NAT bidirectionnelle est à nouveau effectuée. Pour être précis, les adresses source et de destination du paquet sont traduites en adresses publiques.

Figure 1-2 Procédures de traduction d'adresses pour NAT Inbound + NAT Server

224737i5l7hlla1fh3lf5p.png
Ici, vous avez peut-être une question: l’utilisateur Internet peut toujours accéder au serveur intranet même si NAT Inbound n’est pas configuré. Pourquoi le configurez-vous? La réponse réside dans la façon dont le serveur intranet traite le paquet de réponse.

Nous avons défini les adresses du pool d'adresses NAT dans le même segment de réseau que l'adresse du serveur intranet. Lorsque le serveur intranet répond aux demandes d'accès de l'utilisateur Internet, il constate que son adresse et l'adresse de destination se trouvent dans le même segment de réseau. Ensuite, le serveur ne recherche pas dans la table de routage. Au lieu de cela, il envoie un paquet de diffusion ARP pour interroger l'adresse MAC correspondant à l'adresse de destination. Dans ce cas, le pare-feu envoie l'adresse MAC de l'interface se connectant au serveur intranet au serveur intranet et demande au serveur intranet de répondre. Ensuite, le serveur intranet envoie le paquet de réponse au pare-feu et ce dernier traite le paquet.

Comme le serveur intranet ne recherche pas dans la table de routage, il est inutile de définir une passerelle. C'est l'avantage d'utiliser NAT Inbound. Quelqu'un dira peut-être "il est plus facile de configurer une passerelle sur le serveur que de configurer NAT Inbound sur le pare-feu". C'est vrai s'il n'y a qu'un seul serveur sur le réseau. S'il existe des dizaines, voire des centaines de serveurs sur le réseau, vous constaterez à quel point la configuration NAT Inbound est pratique. Certes, l’application de NAT bidirectionnel dans un tel scénario suppose que le serveur intranet et le pare-feu se trouvent sur le même segment de réseau. Sinon, le NAT bidirectionnel ne s'applique pas.

Si j'ajoute une zone de confiance à cette mise en réseau et que les utilisateurs intranet de la zone de confiance doivent accéder au serveur intranet de la zone démilitarisée, comment puis-je configurer un NAT bidirectionnel? La configuration du serveur NAT reste inchangée, tandis que la configuration du NAT source change un peu. Le niveau de sécurité de la zone de confiance étant supérieur à celui de la zone démilitarisée, NAT sortant est requis pour les paquets transmis de la zone de confiance à la zone démilitarisée. C'est-à-dire que la configuration NAT bidirectionnelle passe à NAT Server + NAT Outbound.

2 Intrazone NAT + Serveur NAT
La combinaison NAT + serveur NAT intrazone s'applique aux petits réseaux. La figure 1-3 illustre un petit réseau typique. L'administrateur enregistre le problème et planifie l'hôte et le serveur intranet dans la même zone de sécurité.

Figure 1-3 Diagramme de mise en réseau pour le serveur NAT + NAT intra-zone

224812zbg0i1ccjcjixrrc.png
Dans cette mise en réseau, si l'hôte intranet veut utiliser l'adresse publique 1.1.1.1 pour accéder au serveur intranet, le serveur NAT doit être configuré sur le pare-feu. Cependant, la simple configuration du serveur NAT ne suffit pas. Comme le montre la figure 1-4, après qu'un paquet de l'hôte intranet au serveur intranet arrive au pare-feu, le pare-feu traduit l'adresse de destination du paquet du 1.1.1.1 au 10.1.1.2. Lorsque le serveur intranet répond, il découvre que l'adresse de destination se trouve dans le même segment de réseau que sa propre adresse et le paquet de réponse est directement transféré via le commutateur vers l'hôte intranet, en contournant le pare-feu.

Figure 1-4 Schéma du transfert de paquets après la configuration du serveur NAT

224848ngptvqmmm1wq611d.png
Pour améliorer la sécurité intranet en forçant les paquets répondus par le serveur intranet à passer à travers le pare-feu, nous devons configurer le NAT intranet pour traduire l'adresse source du paquet envoyé de l'hôte intranet vers le serveur intranet. L'adresse source post-NAT peut être une adresse publique ou privée tant qu'elle ne se trouve pas dans le même segment de réseau que l'adresse du serveur intranet, ce qui garantit que les paquets de réponse provenant du serveur intranet peuvent être transférés au pare-feu.

Le serveur NAT et le NAT intrazone sont configurés comme suit. La configuration de la route Blackhole est la même que celle fournie dans les sections précédentes et est donc omise dans cette partie. Regardons d'abord la configuration du serveur NAT.

[FW] nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80

Une fois la configuration terminée, la mappe de serveur suivante est générée sur le pare-feu:

[FW] display firewall server-map

server-map item(s)

 ------------------------------------------------------------------------------

 Nat Server, any -> 1.1.1.1:9980[10.1.1.2:80], Zone: ---

   Protocol: tcp(Appro: unknown), Left-Time: --:--:--, Addr-Pool: ---

   VPN: public -> public

 

 Nat Server Reverse, 10.1.1.2[1.1.1.1] -> any, Zone: ---

   Protocol: any(Appro: ---), Left-Time: --:--:--, Addr-Pool: ---

   VPN: public -> public

Ensuite, regardons la configuration NAT intrazone. La configuration NAT intrazone est presque identique à la configuration NAT interzone. La seule différence est que le NAT est effectué dans une zone pour un NAT intrazone alors qu'entre des zones pour un NAT interzone.

[FW] nat address-group 1 1.1.1.100 1.1.1.100    // L'adresse peut être une adresse publique ou privée mais ne peut pas être dans le même segment de réseau que le serveur intranet.

[FW] nat-policy zone trust

[FW-nat-policy-zone-trust] policy 1

[FW-nat-policy-zone-trust-1] policy destination 10.1.1.2 0 // Comme le serveur NAT est effectué avant le NAT intrazone, l'adresse de destination est l'adresse post-NAT du serveur, à savoir l'adresse privée du serveur.

[FW-nat-policy-zone-trust-1] action source-nat

[FW-nat-policy-zone-trust-1] address-group 1

[FW-nat-policy-zone-trust-1] quit

[FW-nat-policy-zone-trust] quit

La configuration de la politique de sécurité n'est pas fournie car les pare-feu (à l'exception de la série USG6000) ne contrôlent pas les paquets transmis dans une zone de sécurité par défaut. Bien entendu, les administrateurs peuvent configurer les stratégies de sécurité intra-zone appropriées en fonction des besoins.

Une fois la configuration terminée, lorsque l'hôte intranet 1.1.1.1 accède au serveur intranet, vous pouvez afficher la table de session sur le pare-feu. Le résultat de la commande indique que les adresses source et de destination du paquet ont été traduites.

[FW] display firewall session table

Current Total Sessions : 1

  http  VPN:public --> public 10.1.1.3:2050[1.1.1.100:2048]-->1.1.1.1:9980[10.1.1.2:80]

La figure 1-5 illustre le processus de transfert de paquets.

Figure 1-5 Schéma du transfert de paquets après la configuration du serveur NAT et du serveur NAT intra-zone


5576447faca30.png

Sur la base de cette mise en réseau, si nous connectons l'hôte et le serveur intranet au pare-feu via des interfaces dans différents segments de réseau, seul le serveur NAT est requis et tous les paquets transmis entre l'hôte et le serveur intranet sont transmis via le pare-feu.

Au moyen de la description précédente, estimez-vous que le principe et la configuration du NAT bidirectionnel ne sont pas compliqués? Il est important de clarifier la direction NAT et la fonction des adresses post-NAT, et non l'attribut des adresses post-NAT (publiques ou privées). De plus, le NAT bidirectionnel n'est pas requis. Parfois, seuls le NAT ou le serveur NAT source peut produire le même effet. L'utilisation flexible du NAT bidirectionnel simplifie la configuration du réseau et facilite la gestion du réseau, ce qui a pour effet qu'un plus un est supérieur à deux.


 

Pour afficher la liste de tous les postes techniques de Dr. WoW, cliquez ici.

  • x
  • Standard:

Responder

envoyer
Connectez-vous pour répondre. Se connecter | Enregistrer

Remarque : Afin de protéger vos droits et intérêts légitimes, ceux de la communauté et des tiers, ne divulguez aucun contenu qui pourrait présenter des risques juridiques pour toutes les parties. Le contenu interdit comprend, sans toutefois s'y limiter, le contenu politiquement sensible, le contenu lié à la pornographie, aux jeux d'argent, à l'abus et au trafic de drogues, le contenu qui peut divulguer ou enfreindre la propriété intellectuelle d'autrui, y compris les secrets professionnels, les marques commerciales, les droits d'auteur et les brevets, ainsi que la vie privée personnelle. Ne partagez pas votre nom d'utilisateur ou votre mot de passe avec d'autres personnes. Toutes les opérations effectuées à partir de votre compte seront considérées comme vos propres actions, et toutes les conséquences en découlant vous seront imputées. Pour plus de détails, voir « Politique de confidentialité ».
Si le bouton de la pièce-jointe n'est pas disponible, mettez à jour Adobe Flash Player à la dernière version.

Connectez-vous pour participer à la communication et au partage

S'identifier
Réponse rapide Accéder au haut de page