Mise en route : Network Address Translation (NAT)

Mise en route : Network Address Translation (NAT)

309718
Created On 09/26/18 13:44 PM - Last Modified 10/18/23 01:59 AM


Resolution


Après avoir configuré votre pare-feu en suivant les précédentes tranches de la série mise en route, vous souhaiterez peut-être commencer à configurer des serveurs. Sauf si vous avez le luxe de posséder un sous-réseau IP public suffisamment grand pour accueillir tous vos hôtes internes, les détails ci-dessous vous enseigner comment configurer la traduction d’adresses réseau (NAT) ou de Translation d’adresse de Port (PAT) pour faire des hôtes accessible de l’extérieur, ou pour utiliser une IP spécifique à l’internet.

 

Dans cet article, j’aborderai quelques scénarios qui peuvent s’avérer utiles lors de la détermination de la configuration NAT ou PAT pour mieux répondre à vos besoins et jeter dans un couple des mises en garde à l’esprit de.

 

 

Plusieurs-à-un, Hide NAT, Source NAT

 

Afin de couvrir les bases, masquer NAT est l’utilisation la plus courante de la traduction d’adresse là-bas. Il masque tous les sous-réseaux internes derrière une seule adresse IP externe public et ressemblera à ceci :

2016-09-28_15-16-04.png

Cette politique NAT sera traduit toutes les sessions émanant de la zone de confiance, de sortir de la zone untrust et va changer l’adresse de la source à l’adresse IP attribuée à l’interface physique externe. Il sera également randomiser le port source.

Retourner les paquets seront automatiquement inverse-traduit par le pare-feu maintient une table d’état suivi de toutes les sessions actives et leurs actions de NAT

 

NAT-à-plusieurs

 

Une variation sur la peau simple politique de NAT, consiste à ajouter les adresses de source plus si plusieurs sont disponibles. Si, par exemple, votre fournisseur d’accès fourni un sous-réseau public de 29 ou plus, vous avez des adresses IP supplémentaires pouvant être utilisé pour toutes sortes de choses. Si votre réseau interne est assez volumineux, ces adresses supplémentaires peuvent être nécessaires pour empêcher le surabonnement du pool NAT.

Pour cette configuration le Type d’adresse passe de « Interface » à « traduits adresse. » Les adresses IP disponibles sont ensuite ajoutés soit comme une plage d’adresses IP ou un sous-réseau IP :

2016-09-28_16-15-33.png

Le pare-feu sélectionnera une adresse IP du pool disponible basé sur un hachage de l’adresse IP source. Cette adresse source restera le même pour toutes les sessions de cette adresse IP source. Le port source est toujours aléatoire.

 

Si les ports source doivent rester les mêmes (certaines applications peuvent nécessiter un port source spécifique) le Type de traduction peut être défini à IP dynamique, ce qui préservera le port source du client par session. L’adresse traduite est affectée par "prochaine disponible ' qui signifie il y a quelques bémols :

  • Pas plus de 32,000 adresses IP consécutives sont pris en charge
  • Le pool d’adresses traduite doit être de la même taille ou plus de votre numéro interne des hôtes, chaque hôte interne est affecté à sa propre adresse traduite

 

Si les critères ci-dessus sont généralement remplies mais pourraient parfois être rompus, une sauvegarde peut être définie à restaurer sur Dynamic IP et le Port. Les deux l’adresse traduite et les options d’Interface sont disponibles, la valeur par défaut est none :

2016-09-28_16-46-49.png

 

Biunivoque NAT, NAT statique

 

Si vous avez besoin de faire un serveur disponible sur internet, comme un SMTP local ou serveur Web, une politique univoque de la NAT doit être créé qui transmettra les connexions entrantes vers un serveur spécifique. Il y a quelques manières d’y parvenir :

 

Bi-directional politique :

 

Dans une politique de bi-directionelle, une stratégie sortante régulièrement de la NAT statique est créée tout comme les politiques susmentionnées de NAT, et l’indicateur bidirectionnelle est défini, qui permet le sytem pour créer une stratégie de rapprochement implicite (invisible).

2016-09-29_13-37-30.png

 

La politique sera source de confiance et sera destinée pour untrust, avec une adresse source la valeur IP interne du serveur et la traduction de Source étant son adresse publique du NAT. Une politique implicite sera créée avec une zone source d’untrust et de la destination de tout, IP de destination de l’adresse publique de NAT et la traduction de destination à l’adresse IP du serveur.

C’est un moyen facile de créer plusieurs traductions biunivoque et fonctionne parfaitement, si plusieurs serveurs ont leur propre adresse IP publique unique, qui nous amène à :

 

Unidirectionnel politique :

 

Unidirectionnel NAT permet un peu plus de contrôle sur la politique que bi-directionelle, et il permet pour PAT ou Port Address Translation. PAT vous permet de partager une même adresse IP publique sur les différents services internes.

 

Dans les 3 prochaines règles, vous pouvez voir 3 différents exemples de NAT statique entrant :

  • La règle #1 est une règle traditionnelle un-à-un qui traduit tous les ports entrants vers le serveur interne, en maintenant le port de destination
  • La règle #2 traduit uniquement les connexions entrantes sur le port de destination 80 vers le serveur interne sur le port 8080
  • La règle #3 traduit les sessions entrantes pour la même adresse IP publique que la règle #2, mais pour le port de destination 25 vers un serveur interne différent tout en maintenant le port de destination 25

2016-09-29_14-08-55.png

Avertissements :   

  • Pourquoi sont les zones de destination sur untrust et ce qui est avec les interfaces de destination ?
  • « Toute » utilisable comme adresse de destination pour un entrant (untrust pour untrust) NAT

 

La politique de sécurité doit être définie pour la zone source est untrust, zone de destination (destination finale zone) est la confiance et la destination, les adresses sont des adresses publiques, pré-NAT.

2016-09-29_14-45-22.png

 

 

NAT de source et de Destination

 

Dans certains scénarios, il peut être demander d’exercer la source et destination NAT en même temps. Un exemple commun est une situation d’u-Turn, où les hôtes internes doivent se connecter à un serveur interne, qui est sur le même réseau que le client, sur son adresse IP publique.

Il ya déjà un excellent article et une vidéo tutoriel qui couvrent U-Turn plus en détail, mais la brève description est la présente:

 

Pour être en mesure d’atteindre les ressources internes sur une adresse IP publique, une nouvelle politique NAT doit être créé pour tenir compte d’affectation spéciale pour la traduction d’untrust.

 

Si traduction source n’est pas incluse dans la présente politique, le serveur reçoit les paquets avec l’adresse source originale, causant le serveur envoyer des paquets de réponse directement au client.

 

Cela crée une boucle asymétrique : pare-feu client-serveur-client et la session de pare-feu se terminera car elle viole les contrôles de santé mentale TCP.

 

La solution est d’ajouter traduction de source sur, par exemple, l’IP du pare-feu, afin que les paquets de réponse du serveur sont envoyés au pare-feu, permettant pour les sessions « stateful ».

 

2016-09-29_17-13-56.png 

 

BONUS : NAT sur un VWire

 

NAT peut également être implémentée sur un VWire si la vous êtes en mesure de modifier la table de routage sur le routeur (un routeur ISP ne peut-être pas permettre cela). Idéalement, vous avez un routeur sur des extrémités de la VWire à garder les choses simples, mais si vous êtes prêt pour un défi, vous pouvez également obtenir ce de travailler avec seulement un routeur en amont :

 

Entre les deux routeurs, vous devez créer un sous-réseau de petit point à point, par exemple, 10.0.0.0/30. Chaque routeur du attribuer une adresse IP et ajoutez des itinéraires pour les adresses IP traduits pointés vers l’IP du routeur distant sur le routeur situé sur le côté traduit. par exemple. Ajouter un itinéraire pour 198.51.100.1 sur le routeur untrust, pointé vers l’IP du routeur fiable. Le pare-feu se chargera du reste.

 

2016-09-29_15-44-03.png

 

 

Mises en garde

 

  • La résolution de zone est obtenue par des recherches d'itinéraire. Lorsqu’un paquet est reçu sur le pare-feu, une recherche de routage est effectuée afin de vérifier où le sous-réseau source et le sous-réseau de destination sont routés vers, et la zone appropriée est affectée à la session. Dans le cas du trafic entrant de l’internet, la zone source sera untrust, comme le 0.0.0.0/0 de la route par défaut pointe vers l’interface untrust, et l’adresse de destination IP adresse pré-NAT, est également untrust comme c’est l’adresse IP fixé l’interface non fiable (198.51.100.0/24 dans les exemples ci-dessus)

 

  • L'utilisation des interfaces de destination dans les stratégies nat peut aider à prévenir les conflits lors de l'utilisation de stratégies NAT similaires. par exemple. Si les deux interfaces externes existent, aux deux FAI différents, maintien des adresses IP publiques différentes, deux règles NAT sortants identiques peuvent être configurés.2016-09-29_14-54-22.png

 

  • Dans le cas où une adresse IP NAT est utilisée qui n'est pas physiquement configurée sur une interface (par exemple, interface 198.51.100.1, NAT pour le serveur 198.51.100.5), le pare-feu enverra des paquets ARP gratuits pour informer les voisins qu'il héberge un IP address et répondra aux demandes ARP de périphériques en amont. Gratuitous ARP peut également être déclenché manuellement :
    admin @ MyFW > test ARP gratuit interface ethernet1/1 IP 198.51.100.6

    1 Arps ont été envoyés
    ATTENTION: si une règle NAT est configurée pour appliquer la traduction à un sous-réseau qui n'est pas configuré sur une interface, le pare-feu enverra gratuitement ARP pour toutes les adresses IP du sous-réseau.

 

  • Puisque le pare-feu proxy résolution ARP prévoit d’adresses répertoriées dans l’adresse de Destination destination NAT (entrant), le sous-réseau adresse de Destination doit correspondre le sous-réseau de Destination traduction. Il n'est pas autorisé à utiliser'any'comme adresse de destination.  

 

  • Lors de la création de stratégies NAT pour les clients internes pour atteindre les serveurs dans la DMZ ou le réseau de confiance via leurs IPS publics, assurez-vous de placer ces au-dessus de la stratégie Hide-NAT indépendamment.

 

haut de page

 

 

Demandes excédentaires

 

Sursouscription se produit lorsque le pare-feu a traduit de plusieurs sessions simultanées (deux ou plus) partage la même paire adresse IP / port et offre une évolutivité lorsqu’il y a aussi quelques adresses IP publiques pour la quantité de séances en cours de création. Par exemple. normalement, le montant maximal de sessions simultanées serait 64K (65,000 ports source moins 1024 ports « server »). sursouscription, selon la plate-forme, permettant jusqu'à 512 K sessions simultanées par IP avec une sursouscription de 8 x.

 

Certains articles concernant :

Comment faire pour changer le taux de sursouscription de NAT

Comment vérifier la sursouscription sur une règle NAT

 

haut de page

 

 

 

Merci pour la lecture!

Reaper



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CllzCAC&lang=fr&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language