Soucis de redirection de paquet avec NAT

[jackall]

Lut
effectivement comme dit PascalHambourg c’est tout simplement un problème de routage…
Tu as juste oublié de nous précisé que ta GW par défaut était dans le réseau 172.17.1.0/24.

Par contre à l’inverse moi je te propose tout simplement une solution dans le pur esprit KISS.
Fait un double NAT ce qui aura pour effet immédiat de faire fonctionner la solution sans marquage ou autre truc “exotique” généralement non maîtrisé par la plupart des gens.

Le principe est simple:
a l’arrivé sur le routeur Cisco bah tu nat le paquet avec l’IP source 192.168.0.2.

Tu fait ton Nat normalement sur le PC Linux.

Ça “devrait” marcher… sauf si j’ai raté une étape de tes besoins.

++

[PascalHambourg]

Le NAT source a un gros inconvénient : il masque l’adresse source réelle au serveur final. Cela empêche d’utiliser sur celui-ci des ACL ou quoi que ce soit qui se base sur l’adresse IP source. D’autre part les logs d’accès du serveur ne contiennent que l’adresse IP du routeur, il faut donc maintenir des logs sur le routeur et corréler les deux pour retrouver l’adresse source réelle d’une connexion.

[jackall]

Effectivement Pascal je suis tout a fait d’accord pour les inconvénients.
Mais dans le même temps rien d’incontournable avec un bon syslog et des règles d’accès sur le NAT (sur le FW donc).

Mais cela présente pour moi certains avantages :
C’est simple à comprendre
=> pas d’utilisation “exotique” d’iptables à utilisé et on peut donc se concentre sur ce qui est “utile”.
=> Si le principe de la passerelle par défaut et du PBR echappe à Darkvlad là pas besoin de s’embêter. (même si rien n’empeche d’essayer de comprendre hein).
=> c’est simple à mettre en place, à debugger (pour ce qui est de l’accès en tout cas)
=> ça peut agrémenter son projet d’autres aspects ( corrélation de log / reverse proxy/ PBR … )

Mais qu’on se comprenne bien, je suis tout a fait d’accord que nos deux solutions fonctionnent, voire même que la tienne répond mieux à la problématique telle qu’elle à été décrite!!

Le reste n’est que question de point de vue.
Le mien ( en tant qu’intégrateur en SSI et formateur à mes heures ) est de rester dans le conseil, la simplicité et l’efficacité et surtout dans le cas de Darkvlad ce qui est au niveau du client.
Dans ce contexte pour moi la meilleure solution technique n’est pas forcément la bonne solution (de mon point de vue en tout cas) .

Je ne connais pas son niveau d’étude/connaissance/compétence, mais au vu du problème et de la façon dont il l’a présenté et abordé je dirais qu’il me semble plus important de se concentrer sur la compréhension des causes du problème à savoir ici le fonctionnement du routage par défaut, que sur une fonction spécifique d’un soft.

Mais ce n’est que mon avis (que je ne faisais que proposer d’ailleurs )

M’enfin on est hors sujet là , avec notre débat de poilu

[Darkvlad]

Rebonjour, j’essaye d’appliquer la solution de PascalHambourg mais je n’arrive pas à lier les règles de NAT avec la table 99 … *cherche encore *

Et sinon, pour répondre à jackall, je voudrais bien appliquer cette solution depuis le début mais j’ai oublié de préciser quelque chose :

[quote]Le principe est simple:
a l’arrivé sur le routeur Cisco bah tu nat le paquet avec l’IP source 192.168.0.2.[/quote]

Justement, le routeur n’est pas de Cisco mais Netgear et il ne gère pas le NAT

EDIT : Non c’est bon, je croyais qu’il fallait faire un lien avec le NAT mais pas besoin … voici les commandes que j’ai incrusté :

ip rule add from 10.145.7.17 table 99
ip route add 192.168.0.0/24 dev eth2 table 99
ip route add 10.145.7.0/24 dev eth0 table 99
ip route add 172.17.1.0/24 dev eth1 table 99
ip route add 10.0.0.0/8 via 10.145.7.20 dev eth0 table 99
ip route add default via 192.168.0.1 dev eth2 table 99
iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth2 -j DNAT --to-destination 10.145.7.17

Et ça marche nikel ! Merci une fois de plus à vous tous!

Mais je vais pousser le truc un peu plus loin : actuellement, on peut accéder le site depuis l’adresse A.B.C.D mais je voudrais réaliser un port inconnu pour pouvoir accéder à la machine (et surtout, pour enlever le filtre http sur le routeur qui me gêne un peu)
Donc pour l’instant, je vais travailler sur l’adresse A.B.C.D:6600, je vous dirai des nouvelles de mon avancement.

EDIT 2 : Il fallait juste rajouter cette ligne pour faire la translation de port :

iptables -t nat -A PREROUTING -p tcp --dport 6600 -j DNAT --to-dest 10.145.7.17:80

Simple of that mais j’ai un dernier problème! Je vous rappelle que ce site permet d’accéder aux caméras de vidéosurveillances du site en question, sauf que quand j’ouvre la page et que j’entre les logs, ça me met un message d’erreur : Connect Server Failed.
Je suppose qu’il y a un problème de transfert de paquets entre les 2 machines … (ça me le fait aussi avec le port 80)

EDIT 3 : Non c’était tout bête, le logiciel écoute sur le port 8000 et je ne l’avais pas activé sur le pare-feu ! Du coup voici les commandes que j’ai utilisé :

ip rule add from 10.145.7.17 table 99
ip route add 192.168.0.0/24 dev eth2 table 99
ip route add 10.145.7.0/24 dev eth0 table 99
ip route add 172.17.1.0/24 dev eth1 table 99
ip route add 10.0.0.0/8 via 10.145.7.20 dev eth0 table 99
ip route add default via 192.168.0.1 dev eth2 table 99
iptables -t nat -A PREROUTING -p tcp --dport 6600 -i eth2 -j DNAT --to-destination 10.145.7.17:80
iptables -t nat -A PREROUTING -p tcp --dport 8000 -j DNAT --to-dest 10.145.7.17:8000

Activer le port 6600 et 8000 sur le Pare-Feu

J’essaye de faire un truc assez sécurisé et je voudrais savoir ce que vous en pensez !

[PascalHambourg]

Je n’en pense rien de particulier. Tu as fait ce qu’il fallait pour accéder au logiciel de vidéosurveillance depuis l’extérieur. Le fait de permettre l’accès depuis l’extérieur à une machine située au coeur du réseau interne présente bien sûr un risque. Attention donc à d’éventuelles failles de sécurité dans ce logiciel. Si on est parano on va plutôt isoler cette machine dans une DMZ (et ce sera plus simple pour le routage).