Page 2 sur 3
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : mar. 26 juil. 2016 15:42
par biour
Morena !! depuis SG1/atlantis/firefly miam que de chemin parcouru !!
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : mer. 27 juil. 2016 23:24
par yoplait21
Première echo réussie et nickel yeahhhhh
demain je me repenche sur ces règles qui me font sgreugneugneu ...
en plus c'est pas comme si les backups distants étaient pas répliqués en local du coup
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 01:04
par yoplait21
mouarf ...
la je ne comprend vraiment pas ...
avec tcpdump je vois bien mon entrée sur l'interface IN mais rien sur la OUT...
j'ai même tenté une méthode inadmissible sur un Linux ... réinstaller ... des fois que j'aurais collé un bon vieux firewall ou autre, même résultat.
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 01:27
par poulpito
Cad. Donne les commandes que tu as lancées et à quel endroit
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 09:05
par Zedoune
Question bête mais t'as bien activé le ip_forward ?
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 09:10
par poulpito
oui c'est pas faux ca
dans le doute toujours le remettre en début de fichier de règles ^^
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 09:35
par c0bw3b
J'crois que Z fait référence au param kernel à activer via sysctl
http://www.ducea.com/2006/08/01/how-to- ... -in-linux/
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 09:41
par Zedoune
Exactement ! Sans ce truc là, le kernel ne peut pas transférer un paquet d'une interface à une autre donc pour du NAT c'est obligatoire
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 10:01
par yoplait21
le forward ipv4 est bien activé, sinon je ne pourrais pas surfer coté lan en passant par le serveur openvpn
Je tacherais de recompiler les opérations effectuées ce soir
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 10:59
par yoplait21
bon, j'ai "simplifié" le fichier de règles ...
Sur une Debian "de base" avec ifenslave et openvpn d'installé, juste configuré les interfaces et lancé le serveur vpn, modifié le sysctl.conf pour le forward.
Les trois premières lignes du script permettent au bond de fonctionner et à la machine d'agir en tant que passerelle.
Code : Tout sélectionner
#!/bin/bash
IPTABLES=/sbin/iptables
$IPTABLES -A FORWARD -o eth0 -i bond0 -s 192.168.254.0/24 -m conntrack --ctstate NEW -j ACCEPT
$IPTABLES -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A POSTROUTING -t nat -o eth0 -j MASQUERADE
$IPTABLES -A FORWARD -p tcp --dport 4420 -i eth0 -o bond0 -d 172.16.16.2 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -p tcp --sport 4420 -i bond0 -o eth0 -s 172.16.16.2 -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A PREROUTING -t nat -i eth0 -p tcp -m tcp --dport 4420 -j DNAT --to-destination 172.16.16.2:22
et voici les infos iptables une fois lancé ce script, on voit bien que la destination est accessible à partir de cette machine mais pas depuis internet...
Code : Tout sélectionner
root@vpn-wan:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 192.168.254.0/24 anywhere ctstate NEW
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT tcp -- anywhere 172.16.16.2 tcp dpt:4420 state NEW,RELATED,ESTABLISHED
ACCEPT tcp -- 172.16.16.2 anywhere tcp spt:4420 state RELATED,ESTABLISHED
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
root@vpn-wan:~# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere anywhere tcp dpt:4420 to:172.16.16.2:22
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- anywhere anywhere
root@vpn-wan:~# ssh 172.16.16.2
The authenticity of host '172.16.16.2 (172.16.16.2)' can't be established.
ECDSA key fingerprint is da:bd:16:fe:3f:70:82:62:11:83:8d:f7:d5:c4:b2:90.
Are you sure you want to continue connecting (yes/no)? ^C
root@vpn-wan:~#
depuis une machine sur le net :
Code : Tout sélectionner
root@mails:~# ssh xx.xx.58.108 -p 4420
ssh: connect to host xx.xx.58.108 port 4420: Connection refused
mais on voit bien sur le serveur avec tcpdump la requete sur le port 4420 coté l'interface eth0 (ip publique) mais rien ne ressort sur le port 22 coté bond
Code : Tout sélectionner
root@vpn-wan:~# tcpdump port 22 -n -i bond0 | grep 172.16.16.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
------------------------
root@vpn-wan:~# tcpdump port 4420
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:58:53.107337 IP xxx.xxx.xxx.xxx.4420 > initiateur.requete.58454: Flags [R.], seq 0, ack 409692991, win 0, length 0
Désolé de rebalancer ces infos, mais ça me permet aussi de les mettre à plat
j'ai vraiment l'impression de me tapper la tronche contre un mur
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 11:50
par dsebire
je vois pas trop a quoi sert celle la:
10.$IPTABLES -A FORWARD -p tcp --sport 4420 -i bond0 -o eth0 -s 172.16.16.2 -m state --state ESTABLISHED,RELATED -j ACCEPT
et tu t'es planté dans tes regles forward, le port c'est pas 4420, c'est 22
essaie de remplacer la ligne 9 par ça:
IPTABLES -A FORWARD -p tcp --dport 22 -i eth0 -d 172.16.16.2 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
(j'ai aussi viré le -o bound0, pas sur que ce soit utile vu que tes règles PREROUTING le fait pour toi)
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 12:01
par yoplait21
Ok, je viens de tester et j'ai le même résultat.
Juste histoire de comprendre la logique, la règle FORWARD serait donc du coup une règle qui dit :
"Si j'ai quelque chose en provenance de eth0 qui veut aller sur 172.16.16.2 sur le port 22 j'accepte"
mais la règle PREROUTING elle dit:
"Prend les paquets qui arrivent due le port 4420 de l'interface eth0 et redirige les vers 176.16.16.2 sur le port 22"
grosso modo l'une ne peut pas vivre sans l'autre dans le cas présent ?
c'est ça ou je suis dans les choux ?
Code : Tout sélectionner
$IPTABLES -A FORWARD -o eth0 -i bond0 -s 192.168.254.0/24 -m conntrack --ctstate NEW -j ACCEPT
$IPTABLES -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A POSTROUTING -t nat -o eth0 -j MASQUERADE
$IPTABLES -A FORWARD -p tcp --dport 22 -i eth0 -d 172.16.16.2 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A PREROUTING -t nat -i eth0 -p tcp -m tcp --dport 4420 -j DNAT --to-destination 172.16.16.2:22
Code : Tout sélectionner
root@vpn-wan:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 192.168.254.0/24 anywhere ctstate NEW
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT tcp -- anywhere 172.16.16.2 tcp dpt:ssh state NEW,RELATED,ESTABLISHED
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
root@vpn-wan:~# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere anywhere tcp dpt:4420 to:172.16.16.2:22
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- anywhere anywhere
EDIT = d'un autre coté par défaut il forward tout sur tout en théorie donc la règle FORWARD serait de trop ?
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 12:46
par dsebire
oui, c ça.
par contre, je vois pas trop pourquoi ça marche pas la....
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 13:10
par kalistyan
Il faut voir avec dsebire, il maîtrise bien iptables.
oui, c ça.
par contre, je vois pas trop pourquoi ça marche pas la....
Ah bas flûte ! [:t1nyb0y]
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 13:23
par yoplait21
snirfff .. grand moment de solitude du coup ^^
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 13:57
par dsebire
j'ai pas bcp le temps la, je regarde plus tard
le premier truc qui m'a choqué, c'est le forward qui envoyait vers mauvais port
essaie un tcpdump sur l'interface de sortie (bound0) pour voir si les paquets sont envoyés, au cas ou ça soit la trame retour qui passe mal
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 14:06
par gizmo78
ton debian c'est une virtuelle?
SI oui, quoi comme virtualisation?
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 14:41
par yoplait21
virtualisé oui, esx
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 14:45
par yoplait21
tcpdump port 22 -i bond0 | grep 172.16.16.2
aucune communication apparente lors d'un accès extérieur, depuis l'intérieur je vois bien passer les trames
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 17:48
par poulpito
Fait pas un grep fait port 22 and host xxx.xxx.xxx.xxx
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 18:27
par yoplait21
tcpdump port 22 host 172.16.16.2
tcpdump: syntax error
mouarf O_o ......
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 18:36
par c0bw3b
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : ven. 29 juil. 2016 19:12
par yoplait21
merci ... décidément ... en ce moment je ne suis pas très attentif
et toujours rien en cas de tentative d'accès depuis l'extérieur ...
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : sam. 30 juil. 2016 08:44
par dsebire
tcpdump port 22 -i bond0 | grep 172.16.16.2
aucune communication apparente lors d'un accès extérieur, depuis l'intérieur je vois bien passer les trames
donc t'as bien un pb de NAT...
que renvoie sysctl net.ipv4.ip_forward ?
[NAT] règle non fonctionelle .(resolu soucis de mac)
Publié : sam. 30 juil. 2016 10:31
par yoplait21
root@vpn-wan:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
root@vpn-wan:~#