Je voudrais faire du source nating via iptables.
En fait, le but est de modifier l'adresse ip source des paquets que mon serveur openvpn recoit pour la remplacer par une adresse du réseau cible.
En gros il y a :
192.168.8.0/24 : le réseau cible (contient des services accessibles seulement à ce réseau)
192.168.9.0/24 : le réseau wifi (limité au niveau des accès)
192.168.10.0/24 : le réseau alloué à openvpn.
Le setup de openvpn fonctionne bien avec une interface tun0. Le but est que lorsqu'un client vpn essaye d'accéder au réseau cible (le 8.0), son adresse ip source soit natée en, par exemple, 192.168.8.100 (dans le but d'accéder au service qui n'autorisent l'accès que depuis le réseau cible).
Pour faire cela, j'utilise la règle iptables suivante :
$IPTABLES -t nat -A POSTROUTING -s $VPN_NETWORK -j SNAT --to 192.168.8.100
Mais la règle ne semble pas être utilisée car je garde toujours mon ip du réseau VPN (et pas celle que je voudrais utiliser en remplacement, renseignée dans le SNAT).
Est-ce que quelqu'un a une idée ?
# faux probleme ?
Posté par NeoX . Évalué à 2.
perso c'est comme ca que je fais, et ca marche plutot bien
$IPTABLES -t nat -A POSTROUTING -o $carte_interne -s $reseau_vpn -j MASQUERADEainsi les machines locales pensent que c'est ta machine vpn qui pose la question
[^] # Re: faux probleme ?
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 2.
Maintenant, je ne sais pas comment netfilter se comporte si le serveur à joindre est la même machine que celle ou openvpn tourne.
En fait j'essaye (par exemple) de joindre un serveur apache sur la même machine que celle qui fait tourner le serveur VPN et ce en ayant comme adresse ip celle de $carte_interne par exemple.
Hors si l'on regarde :
http://fr.wikipedia.org/wiki/Image:Netfilter_schema.png
La chaine POSTROUTING sera exécutée soit si on forward le paquet (ce n'est pas le cas vu que le serveur apache tourne sur la machine ou se trouve le VPN). Soit la chaine POSTROUTING sera exécutée lors de l'émission d'un paquet par un logiciel (par exemple une réponse de apache) mais alors c'est trop tard.
Donc je ne sais pas si la MASQUERADE comme le SNAT sont les bonnes façons de procéder.
[^] # Re: faux probleme ?
Posté par NeoX . Évalué à 2.
$IPTABLES -A INPUT -i $interface_vpn -j ACCEPT
$IPTABLES -A FORWARD -i $interface_vpn -j ACCEPT
$IPTABLES -A OUTPUT -o $interface_vpn -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -o $interface_interne -j MASQUERADE
mais verifie aussi que ton client vpn recoive bien la route vers 192.168.9.0/24 quand il est connecté à ton VPN
[^] # Re: faux probleme ?
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 2.
En fait, le client VPN tourne sur un laptop connecté au réseau en WIFI (donc depuis le réseau 192.168.9.0 qui sert juste au transport). Ce laptop veut accéder au réseau 192.168.8.0. Pour les routes, j'utilise la fonctionnalité de knetwork-manager qui permet d'associer une route à un VPN.
Donc le VPN en tant que tel marche mais j'aimerai juste que lorsque le laptop accède au réseau 192.168.8.0, il y a un remplacement de son adresse ip source car certains de mes services n'acceptent les connexions que depuis les ip sources 192.168.8.0/24.
Le problème du POSTROUTING, si on regarde le schéma de Wikipedia, c'est que cette chaine n'est exécutée que dans deux cas :
1° La machine qui est en train de traiter le paquet n'est pas la destination finale : on doit forwarder. Juste après l'exécution de FORWARD on éxecute POSTROUTING.
2° La machine émet un paquet, on éxecute POSTROUTING juste avant de l'envoyer.
En gros on éxecute POSTROUTING que lors de l'envoie de paquet.
Dans mon cas il se trouve justement que la machine sur laquelle tourne mes services et le VPN est la même. Donc quand cette machine recoit un paquet d'un client VPN, il n'y a pas à le forwarder : il est envoyé au service gérant ce port (apache; cups; etc...).
Donc, si mon analyse est correcte, je ne pense pas que la chaine POSTROUTING puisse faire quoi que ce soit pour m'aider.
Si j'ai pas été assez clair, n'hésitez pas à me le dire, je reformulerai.
D'avance merci.
[^] # Re: faux probleme ?
Posté par NeoX . Évalué à 2.
et ton serveur web sur eth0
il y a bien transfert entre les 2 interfaces
donc il y a bien forward et postrouting
(ou alors j'ai vraiment rien compris)
[^] # Re: faux probleme ?
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 2.
1° Si c'était correct, ben je suppose que la règle iptables fonctionnerai.
2° Le point critique dans le schéma c'est la bulle routage à gauche. On voit dans cette bule que c'est seulement si la destination est externe qu'on va appliquer les règles de FORWARD et de POSTROUTING. Sinon on descend dans le schéma (c'est mon cas, la destination est locale car la machine est la même) et on éxecute INPUT (sur FILTER et MANGLE).
Je pense que cette vision est relativement logique et surtout il n'y a, à priori, pas de raisons de renvoyer le paquet d'un endroit à l'autre vu que le kernel sait très bien que la destination est la machine qu'il contrôle.
Si le paquet arrive sur tun0 et que la destination est eth0 (soit la même machine) ben il n'y a pas de raisons de renvoyer quoi que ce soit, il suffit d'exécuter les règles appropriées et d'envoyer le paquet directement à l'application qui écoute sur le port en question.
Maintenant ceci n'est que ma vision qui découle de la lecture du schéma, je ne tiens pas ceci d'un bouquin. Mais ça me semble assez sensé et logique donc si je commet une erreur, ce serait bien de m'expliquer ce qui cloche dans le raisonnement.
En fait si ce que je dit est correct, le résultat final est logique : vu qu'aucunes règles de POSTROUTNING (donc SNAT et MASQUERADE) ne serait exécuté, ben l'ip source reste celle du VPN, ce que je veut éviter.
[^] # Re: faux probleme ?
Posté par NeoX . Évalué à 2.
et tu viens toi meme de dire que d'apres le schema ce n'est pas la bonne
[^] # Re: faux probleme ?
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 2.
Le problème c'est que les règles de POSTROUTING constitue la seule manière que je connaisse de changer l'ip source.
Le but est là, je ne sais pas vraiment comment y arriver.
Une autre solution que j'ai envisagé c'était d'utiliser aussi le réseau 192.168.8.0/24 pour le VPN.
Dans ce cas, les ip sources sont correctes mais les problèmes sont :
1° Je ne sais pas si c'est mauvais d'avoir deux interfaces avec la même ip (il y aurait tun0 et eth0).
2° Beaucoup plus embêtant : si openvpn gère lui même l'attribution des ip je risque d'avoir des doublons avec le serveur DHCP qui fourni également des adresses sur ce réseau (et ça, ça pourrait être assez embêtant).
C'est surtout par rapport au point deux que je devrai investiguer, si quelqu'un a une idée...
# PREROUTING ?
Posté par Dabowl_75 . Évalué à 2.
pourquoi ne pas changer l'adresse IP source plus tôt ?
Dès que le paquet du client OpenVPN arrive sur l'interface tun0, alors une règle de PREROUTING va changer l'adresse IP source :
iptables -t nat -A PREROUTING -i tun0 -s 192.168.9.0/24 -d 192.168.8.0/24 -j SNAT --to 192.168.8.100
Etant donné que le paquet n'est pas destiné au firewall/VPN mais à un serveur du réseau 192.168.8.0, il ne devrait pas rentrer par la chaine INPUT mais passera directement par FORWARD ; c'est à dire entre tun0 et eth0 ; il faudra à ce moment là accepter les paquets à traverser les deux interfaces pour arriver jusqu'au serveur final.
Bon, j'ai pas encore pris mon café et je dis peut-être des bêtises car ça fait longtemps que j'ai pas joué avec netfilter :-)
[^] # Re: PREROUTING ?
Posté par NeoX . Évalué à 2.
et en effet, vu qu'il veut modifier le paquet avant qu'il ne soit traiter ailleurs,
PREROUTING me semble etre adequate.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.