Rebonjour tout le monde, et encore merci pour vos participations.
Malheureusement, ça ne marche toujours pas.... Je vais donc essayer de vous fournir des explications encore un peu plus complêtes....
J'ai 2 réseaux LAN, disposant du même sous réseau (172.16.0.0/24).
Sur mon réseau A, j'ai une plateforme d'accès OpenVPN, (interface tun0 10.8.0.1 + eth0 172.16.0.3), ainsi qu'un serveur web à l'adresse 172.16.0.2
Sur mon réseau B, les clients se connectent au serveur OpenVPN, et obtiennent une adresse en 10.8.0.0/24.
Je veux que mes clients du réseau B puissent accéder au serveur du réseau A. Vu que le routage est impossible (mêmes réseaux), je voulais faire du nat "hide", de manière à ce que les postes du réseau B se servent de l'adresse 10.8.0.1:80 pour acceder au serveur.
Voilà, le contexte est posé. Maintenant, ce qui me pose problème, c'est que je n'arrive à rien, quels que soient mes essais (je me souviens pas avoir jamais autant galéré avec iptables).
J'ai essayé le script fournis par petit_bibi, en ajoutant des logs sur PREROUTING et POSTROUTING. Lorsque j'essaye, rien ne se loggue pour PREROUTING, et pour POSTROUTING, j'ai IP.src = IP.dst
J'essaye aussi la règle suivante :
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 172.16.0.2:80
et toujours rien dans les logs.
Je précise, tous les modules sont bien chargés, ip_forward est bien activé.
Merci d'avance pour votre aide, là, je suis perdu....
Forum Linux.général Iptables et NAT - La suite....
30
sept.
2009
# Essaie ça :
Posté par raboliot . Évalué à 1.
Ce script est pas mal pour partir sur de bonnes bases. Ca permet d'avoir un squelette fonctionnel.
# erreur de concept
Posté par NeoX . Évalué à 1.
tu as un reseau VPN 10.8.0.0/24
tu veux que les gens qui se connectent aux travers du vpn, puisse se connecter au reseau 172.16.0.0/24
c'est donc simplement un probleme de route
il faut dire à openvpn qu'il fournit les routes vers 172.16.0.0/24
(afin que les clients envoient leurs paquets à 10.8.0.1)
il faut ensuite
1°)
avec iptables : autoriser le reseau 10.8.0.0/24 à acceder à 172.16.0.0/24
avec route, et si ta machine 172.16.0.3 n'est pas la passerelle par defaut, pour que les autres machines du reseau 172.16.0.0/24 sachent qu'il faut envoyer à 172.16.0.3 toutes les reponses à destination de 10.8.0.0/24
ou
2°) nater ce qui vient de 10.8.0.0/24 à destination de 172.16.0.0/24 en changeant l'adresse source pour faire croire que c'est 172.16.0.3 qui fait la demande
[^] # Re: erreur de concept
Posté par neuro . Évalué à 1.
Je veux donc simplement masquer une adresse réseau (la 172.16.0.2, du réseau A), derrière l'ip de ma gateway VPN (10.8.0.1), et pour ça, c'est bien du NAT qu'il me faut.
Bon, sinon, j'ai un peu avancé, en partant du script fourni ci-dessus, j'arrive à faire fonctionner le bouzin.... mais je ne comprend toujours pas où était mon erreur.... (et j'aime bien comprendre comment ça marche...)
[^] # Re: erreur de concept
Posté par nono14 (site web personnel) . Évalué à 1.
En faisant du NAT sur la gateway vpn, et une route spécifique vers le serveur A, ça peut marcher ( et c'est selon moi très crade et prise de tête maintenant et à venir, à maintenir)
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: erreur de concept
Posté par nodens . Évalué à 3.
DNAT= changement de destination = PREROUTING (il faut le faire avant de prendre la décision de routage).
SNAT= changement de source = POSTROUTING (ça se fait quand le paquet part, après le routage)
Ici, le problème est qu'il faut du DNAT et du SNAT.
En effet, ce qui se passe c'est :
A (172.16.0.0) -> (openvpn) interface tunnel (ppp) avec trafic à destination de la 10.8.0.0 -> DNAT (modification de la destination du paquet) vers 172.16.0.0
A ce stade, le paquet a une source en 172.16.0.0 et une destination de 172.16.0.0. Du coup, la destination n'a aucune raison de renvoyer le paquet au routeur qui se charge de la NAT. Il faut donc ajouter une règle de SNAT (du genre : iptables -t nat -A POSTROUTING- s <masque réseau A, disons 172.16.0.0/16> -d <masque réseau B, 172.16.0.0/16> -o <interface lan local> -j SNAT --to <ip locale>, ou plus simplement iptables -t nat -A POSTROUTING -s <masque réseau A> -d <masque réseau B> -o <interface locale B> -j MASQUERADE). C'est en plus de la règle de DNAT en prérouting sur le trafic à destination de 10.8.0.0 sur l'interface openvpn.
Il me semble que c'est ce que j'avais déjà répondu au premier post, mais bon, soit j'ai pas compris le problème, soit je m'explique pas clairement :-)
Après, quand on a le même réseau de chaque côté, c'est toujours galère dans les vpn...
Si on a besoin de faire des connexions point à point entre les machines du réseau A et du réseau B (et pas juste d'accéder à une machine du réseau B depuis le réseau A), le mieux est de faire un double NAT complet : http://www.netfilter.org/documentation/HOWTO//netfilter-doub(...)
Pour mieux comprendre l'enchainement des règles INPUT, FORWARD, OUTPUT, PREROUTING, et POSTROUTING : http://www.netfilter.org/documentation/HOWTO/netfilter-hacki(...) ou la "big picture" : http://linux-ip.net/nf/nfk-traversal.html
[^] # Re: erreur de concept
Posté par nodens . Évalué à 2.
Si ça ne marche pas, on peut voir ta version du script et un exemple de log ?
Tu as essayé d'utiliser tcpdump pour comprendre ce qui se passe ?
(log + tcpdump -i any, généralement on a plus d'info).
La raison qui pourrait faire que ça ne marche pas ça serait une bizarrerie dûe à openvpn (je ne l'ai jamais vu sur du ppp, pour moi c'était tun ou tap...).
[^] # Re: erreur de concept
Posté par neuro . Évalué à 2.
En effet, j'avais utilisé le script fourni par petit_bibi, qui dans un premier temps ne marchais pas. Suite à quelques modifs, il avais fini par fonctionner.... quelques temps avant de ne plus fonctionner ! (Ce qui m'as mis la puce à l'oreille....)
J'ai changé la carte réseau, et depuis, bizzarement, plus aucun soucis, même avec les règles que j'essayais d'utiliser au début.
Alors par contre, me demandez pas en quoi une carte réseau foireuse peut influencer le nat, d'autant qu'à priori, le reste du traffic a l'air de passer sans trop de soucis.
Pour résumer, donc, c'est bien le nat qu'il faut utiliser, et c'est bien du prerouting ET postrouting qu'il faut faire !
Merci à tous pour votre aide !!!
# Selection
Posté par peck (site web personnel) . Évalué à 1.
Ton problème c'est le routage, pose toi sur la passerelle A qui a un réseau en 172.16.0.0/24 et un réseau en 10.8.0.1 donc tous les paquets à destination de 172.16.0.0/24 restent sur le réseau A
Tous les paquets en provenance de B qui ont une ip en 172.16.0.0/24 ne pourront donc pas retourner sur B. Donc nat ou pas nat ca ne marche pas.
Ce qu'il te faut c'est 2 réseaux disjoints (par exemple 192.168.0.0/24 et 192.168.1.0/24). Pour faire ca, il faut soit ajouter les ip au clients puis les router, soit ne pas les ajouter et faire du nat des 2 cotés à la fois pour faire croire qu'elles existent, c'est-à-dire DNAT coté serveur et SNAT coté client.
[^] # Re: Selection
Posté par neuro . Évalué à 1.
Je lance mes règles iptables sur la passerelle A, qui a donc une interface 172.... et une en 10.8.0.1
openvpn fonctionne en PPP, donc se voient attribuer une adresse en 10.8.0.x, pas de problème de connection donc vers le serveur 10.8.0.1
Et donc, pour en revenir à ce cas précis, ça fonctionne (bien en faisant du nat et pas du routage), mais je comprend toujours pas pourquoi ça fonctionnais pas avant.
# Logs iptables
Posté par petit_bibi . Évalué à 3.
(Les règles de log doivent être prioritaires)
for c in 'INPUT' 'OUTPUT' 'FORWARD' ; do
iptables -I ${c} 1 -m limit --limit 2/s --limit-burst 10 -j LOG --log-prefix ${c}:
done
for c in 'PREROUTING' 'POSTROUTING' ; do
iptables -t nat -I ${c} 1 -m limit --limit 2/s --limit-burst 10 -j LOG --log-prefix ${c}:
done
Résultat dans /var/log/.. si syslog est réglé correctement:
INPUT:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:13:72:8b:3a:3f:08:00 SRC=192.168.0.100 DST=192.168.0.255 LEN=94 TOS=0x00 PREC=0x00 TTL=64 ID=34563 DF PROTO=UDP SPT=631 DPT=631 LEN=74
...
Ensuite, tenter d'établir une connection depuis le client et extraire de ces logs les chaines traversées ainsi que les source/destination devices/ip des paquets..
Sachant qu'il y a un process openvpn derrière, peut-être bien que INPUT OUTPUT sont de la partie, Je n'ai jamais utilisé openvpn..
Il faut regarder attentivement les sources IP, dest IP ainsi que IN/OUT devices, et nous les fournir éventuellement ? :-)
Sait-on jamais il y a peut-être aussi du loopback dans le tas, je ne sais pas comment ça se passe avec un process et du PPP...
Enfin, ces règles risquent de générer beaucoup de logs si tu as d'autres truc qui tournent sur cette machine. Mais c'est toujours préférable d'avoir toutes les logs pendant ce genre de recherches pour ne pas rater quelque chose ..
Aussi, si je me souviens seul les paquets de state 'NEW' passent par la chaine PREROUTING. (La signification de NEW dépend du protocole.) Donc c'est normal si il n'y a pas beaucoup de logs au sujet de PREROUTING.
[^] # Re: Logs iptables
Posté par nono14 (site web personnel) . Évalué à 1.
> Pas tout à fait si tu mets une politique DROP dans la chaine PREROUTING, il ne passe plus grand chose...
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.