Le 20/07/2016 à 11:11, Antoine Durant a écrit :
Salut alarig,
Le TCP est suffisant comme tu le précise, mais même dans mon cas cela ne change
pas mon problème d'accès depuis le lan
De : Alarig Le Lay <ala...@swordarmor.fr>
À : frnog@frnog.org
Envoyé le : Mercredi 20 juillet 2016 11h06
Objet : Re: [FRnOG] [TECH] Comportement étrange avec ip nat inside
On Wed Jul 20 08:28:00 2016, Antoine Durant wrote:
Bonjour,
J’ai un phénomène que je trouve un peu particulier lorsque j’utilise une règle
ip nat inside.
J’ai ajouté les règles suivantes pour que mon serveur web soit accessible
depuis l’extérieur via IP wan :
ip nat inside source static tcp 172.16.1.33 80 X.Y.Z.1 80 extendable
ip nat inside source static udp 172.16.1.33 80 X.Y.Z.1 80 extendable
Salut,
Pourquoi est-ce que tu rediriges aussi les 80 UDP alors que HTTP marche
sur TCP ?
Bonjour,
Je ne connais pas bien le NAT sur Cisco, mais c'est un problème qui
m'amuse beaucoup en iptables (par exemple), aussi pour une fois, je me
lance.
Ce sont les paquets retour qui n'arrivent pas correctement à ton client
web. Ils arrivent, mais mal formés (avec un routeur/firewall Linux
iptables toujours, mais je subodore que c'est plus ou moins le même
problème sur cisco).
Posons :
- Adresse de ton client Web : C (Ip privée)
- Adresse de ton serveur Web : S (IP privée)
- Adresse publique sur laquelle tu fais un dst nat (nat inside ?) : W
- Adresse publique vers laquelle est natée ton client : W'
(éventellement égale à W)
1- Ton client envoie un paquet SYN vers l'IP publique du serveur web :
=> adresse source C, adresse destination W
2- Le paquet arrive sur l'interface interne du routeur : Pré-routing DNAT
=> adresse source C, adresse destination S + création d'une entrée
correspondante dans la table de NAT
3- Le paquet doit sortir du routeur : Post-routing SNAT, seulement il
"sort" par l'interface interne puisque sa destination (S) est maintenant
l'adresse IP privée de ton serveur WEB, le SNAT n'a donc pas lieu
puisque que le Snat ne se fait que sur les paquet qui sortent par ton
interface publique. Le paquet n'est donc pas modifié :
=> adresse source C, adresse destination S
4- La paquet arrive à ton serveur qui le traite et y répond en inversant
adresse source et adresse destination (SYN+ACK)
=> adresse source S, adresse destination C
Et c'est là que ça merdoie : ton serveur réponds directement à l'adresse
ip du client, sans passer par le routeur/firewall puisque C est sur le
même domaine de broadcast que S. Le client voyant arriver le paquet avec
comme adresse source de la réponse l'adresse IP privée de ton serveur,
ça ne match pas avec la connexion qu'il à initié et drop le paquet...
Tu pex vérifier si c'est bien ce qui se produit en posant un tcpdump sur
le serveur ou le client.
Ce problème se produit (à ma connaissance) uniquement quand tu mets en
place un DNAT et essaye d'atteindre via le routeur un serveur qui est
dans le même domaine de broadcast que ton client (ça "marche" aussi si
tu essayes de faire un wget depuis le serveur sur l'IP publique du
serveur :D )
Plusieurs solutions sont possibles :
- DNS privé ou fichier hosts qui évite de te faire passer par ton
firewall en résolvant avec l'adresse IP privée
- Tu mets ton serveur dans une DMZ et ton client dans un autre réseau
(mais ça ne règle pas vraiment le problème si des serveurs de la DMZ
doivent s'interroger mutuellement via leurs IP publiques)
- Tu forces le SNAT vers W' lorsque le paquet sort (même par l'interface
privée), ainsi, à l'étape 3 le paquet devient :
=> Adresse source W', adresse destination C + création d'une deuxième
entrée dans la table de NAT
Le serveur réponds donc vers l'IP publique du W', passe par le firewall
qui fait les opérations inverses grâce aux deux entrées de la table de
NAT et hop la connexion se fait.
Je trouve ça peu élégant, mais ça marche. Si quelqu'un à une autre
solution, je suis preneur :)
--
Matthieu
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
