Bonjour,
Je débute en iptables et j'effectue quelques tests de redirection DNAT mais je galère un peu.
J'ai actuellement 2 machines virtuelles (virtualbox) connectées à mon réseau local.
La première sert de firewall (VM_FM, 192.168.0.17) et la 2eme de serveur web (VM_WEB, 192.168.0.16).
Je souhaite effectuer une simple redirection du port 80 de la VM_FW à la VM_WEB.
Voilà le petit scrict que j'ai utilisé sur la machine VM_FW (firewall) pour effectuer cette redirection :
---------8<--------------
#!/bin/bash
# on purge toutes les chaines des tables
iptables -t filter -F
iptables -t filter -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
# pas de filtrage
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
# configuration de la translation d'adresse
iptables -t nat -A PREROUTING -d 192.168.0.17 -p tcp --dport 80 -j DNAT --to 192.168.0.16:80
iptables -A FORWARD -o eth1 -p tcp -d 192.168.0.16 -j ACCEPT
# activation du forwarding
echo 1 >/proc/sys/net/ipv4/ip_forward
---------8<--------------
Mais la redirection ne fonctionne pas. Quand j'effectue un telnet sur l'ip de VM_FW (192.168.0.17), je n'ai aucune réponse :
-------8<-------------
telnet 192.168.0.17 80
Trying 192.168.0.17…
-------8<-------------
Pourtant le telnet fonctionne si on tape directement sur l'ip de la VM_WEB (192.168.0.16) :
---------8<--------------
telnet 192.168.0.16 80
Trying 192.168.0.16…
Connected to 192.168.0.16.
Escape character is ']'.
---------8<--------------
Voici l'état de ma table nat au moment du telnet (on voit bien qu'il y un paquet matché par la règle, pourtant celle-ci ne fonctionne pas) :
---------8<--------------
Chain PREROUTING (policy ACCEPT 61 packets, 12979 bytes)
pkts bytes target prot opt in out source destination
2 120 DNAT tcp — * * 192.168.0.2 192.168.0.17 tcp dpt:80 to:192.168.0.16:80
Chain POSTROUTING (policy ACCEPT 3 packets, 191 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 1 packets, 71 bytes)
pkts bytes target prot opt in out source destination
---------8<--------------
J'ai l'impression que les paquets sont bien transmis à la VM_WEB mais je n'ai pas de réponse ensuite…
Quelqu'un aurait-il une idée?
J'ai également fait un tcpdump sur la VM_WEB mais j'ai du mal à l'interpréter :
--------8<----------------
tcpdump -i eth0 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:14:11.743576 IP 192.168.0.2.56192 > 192.168.0.17.www: Flags [S], seq 3504256782, win 14600, options [mss 1460,sackOK,TS val 6521489 ecr 0,nop,wscale 4], length 0
22:14:11.743808 IP 192.168.0.2.56192 > 192.168.0.16.www: Flags [S], seq 3504256782, win 14600, options [mss 1460,sackOK,TS val 6521489 ecr 0,nop,wscale 4], length 0
22:14:11.743854 IP 192.168.0.16.www > 192.168.0.2.56192: Flags [S.], seq 1336771027, ack 3504256783, win 5792, options [mss 1460,sackOK,TS val 23734566 ecr 6521489,nop,wscale 5], length 0
22:14:11.746926 IP 192.168.0.2.56192 > 192.168.0.16.www: Flags [R], seq 3504256783, win 0, length 0
22:14:14.745556 IP 192.168.0.2.56192 > 192.168.0.17.www: Flags [S], seq 3504256782, win 14600, options [mss 1460,sackOK,TS val 6522240 ecr 0,nop,wscale 4], length 0
22:14:14.745799 IP 192.168.0.2.56192 > 192.168.0.16.www: Flags [S], seq 3504256782, win 14600, options [mss 1460,sackOK,TS val 6522240 ecr 0,nop,wscale 4], length 0
22:14:14.745844 IP 192.168.0.16.www > 192.168.0.2.56192: Flags [S.], seq 1383677118, ack 3504256783, win 5792, options [mss 1460,sackOK,TS val 23735316 ecr 6522240,nop,wscale 5], length 0
22:14:14.751956 IP 192.168.0.2.56192 > 192.168.0.16.www: Flags [R], seq 3504256783, win 0, length 0
22:14:20.759780 IP 192.168.0.2.56192 > 192.168.0.17.www: Flags [S], seq 3504256782, win 14600, options [mss 1460,sackOK,TS val 6523744 ecr 0,nop,wscale 4], length 0
22:14:20.760051 IP 192.168.0.2.56192 > 192.168.0.16.www: Flags [S], seq 3504256782, win 14600, options [mss 1460,sackOK,TS val 6523744 ecr 0,nop,wscale 4], length 0
22:14:20.760095 IP 192.168.0.16.www > 192.168.0.2.56192: Flags [S.], seq 1477649824, ack 3504256783, win 5792, options [mss 1460,sackOK,TS val 23736820 ecr 6523744,nop,wscale 5], length 0
22:14:20.767840 IP 192.168.0.2.56192 > 192.168.0.16.www: Flags [R], seq 3504256783, win 0, length 0
--------8<----------------
Merci d'avance pour votre aide.
Cordialement.
# retour
Posté par nono14 (site web personnel) . Évalué à 3.
les paquets reviennent comment … ? ils ne sont pas natté ?
comment ta machine de test qui se connecte sur X.16 accepte un retour de connetion de la 17 ?
Système - Réseau - Sécurité Open Source
[^] # Re: retour
Posté par nanouk972 . Évalué à -1.
Bonjour,
Oui, la machine de test accepte tous les paquets.
Par contre les paquets en retour ne sont pas natté. Je pensais qu'il y avait une association qui était faite dans la table nat pour retrouver l'expéditeur afin de pouvoir lui répondre.
Faut-il aussi que je fasse aussi une redirection du port 80 sur la VM_WEB pour renvoyer les paquets vers la VM_FW ?
Merci d'avance.
Yannick.
[^] # Re: retour
Posté par nono14 (site web personnel) . Évalué à 3.
A condition, que les paquets repassent par le pare feu…
Système - Réseau - Sécurité Open Source
[^] # Re: retour
Posté par Batchyx . Évalué à 3.
D'après sa trace, non ils ne sont pas renattés, et d'ailleurs, quand le client se prend un paquet de .16, il lui renvoie un RST direct, parce qu'il ne le connait pas (le client à demandé 192.168.0.17).
Pour que ça le soit, il faudrait que .16 n'aie ses routes 192.168.0.0/? via 192.168.0.17, ou alors que .16 fasse du snat sur les connections qui viennent de l'adresse mac de .17.
Fin bon, le plus simple, c'est quand même de mettre un proxy sur .17
[^] # Re: retour
Posté par NeoX . Évalué à 3.
une solution en plus du forward qui est actuellement mis en place,
c'est de masquerader les ips sortantes.
ainsi la machine 16 croit que ca vient de la passerelle
et la machine 17 quoi que la passerelle lui repond.
evidement dans tout ca, il faut que les 2 machines soient sur des reseaux differents mais que la passerelle soit sur les deux (au milieu)
ce qui pour l'instant au vue des 192.168.0.2, 192.168.0.16 et 192.168.0.17 cités n'est pas le cas (tout le monde sur le meme reseau 192.168.0.0/24)
il te faudrait par exemple
PC1 : 192.168.0.16/24
VM-GW : 192.168.0.17/24 et disons… 192.168.10.17/24
WM-Web : 192.168.10.18/24
avec les VM il faut mettre la passerelle avec 2 cartes reseaux, une sur ton vrai LAN
la deuxieme sur un LAN interne aux VMs
[^] # Re: retour
Posté par nanouk972 . Évalué à 1.
Effectivement,
c'est là que se situait mon erreur. Toute les machine étaient dans le même subnet.
J'ai donc fait un subnet entre la VM_FW et la VM_WEB afin d'y remedier.
Merci pour ta disponibilité en tout cas.
Vous êtes au top les gars !!
[^] # Re: retour
Posté par nanouk972 . Évalué à 1.
Merci beaucoup !!!
C'était une simple histoire de route.
Comme tu me l'a fais remarqué, vu que la VM_WEB et la machine de test étaient toutes les 2 dans mon réseau local (192.168.0.0/24), la VM_WEB renvoyait directement la réponse à la machine depuis laquelle j'effectuais le telnet (192.168.0.2) sans passer par la VM_FW (192.168.0.17).
J'ai donc créé un subnet entre la VM_FM (192.168.10.1) et la VM_WEB (192.168.10.2) et sortie la VM_WEB du réseau locale afin qu'elle passe par la VM_FW pour sortir.
J'ai modifié ma règle de iptables de cette façon :
---------8<------------
iptables -t nat -A PREROUTING -d 192.168.0.17 -p tcp --dport 80 -j DNAT --to 192.168.10.2:80
---------8<------------
Et là ça fonctionne.
Merci "Batchyx" pour tes réponses rapides qui m'ont bien éclairées.
(C'est mon 1er post sur ce forum, faut-il que je modifie le titre en mettant un mot clée [résolu] ou quelque chose du genre?)
[^] # Re: retour
Posté par NeoX . Évalué à 2.
y a pas de regle absolue, avant on pouvait pas modifier une entrée si on revenait plus de 5 minutes apres.
il semblerait qu'on puisse maintenant le faire et c'est bien aussi de savoir que c'est resolu, car le jour on quelqu'un cherche sur le meme sujet, il sait que dans ton post se trouve une solution.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.