[NAT] règle non fonctionelle .(resolu soucis de mac)

Message par **biour** » mar. 26 juil. 2016 15:42

Morena !! depuis SG1/atlantis/firefly miam que de chemin parcouru !!

Message par **yoplait21** » mer. 27 juil. 2016 23:24

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

Message par **yoplait21** » ven. 29 juil. 2016 01:04

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.

Message par **poulpito** » ven. 29 juil. 2016 01:27

Cad. Donne les commandes que tu as lancées et à quel endroit

Message par **Zedoune** » ven. 29 juil. 2016 09:05

Question bête mais t'as bien activé le ip_forward ?

Message par **poulpito** » ven. 29 juil. 2016 09:10

oui c'est pas faux ca

dans le doute toujours le remettre en début de fichier de règles ^^

Message par **c0bw3b** » ven. 29 juil. 2016 09:35

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/

Message par **Zedoune** » ven. 29 juil. 2016 09:41

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/

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

Message par **yoplait21** » ven. 29 juil. 2016 10:01

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

Message par **yoplait21** » ven. 29 juil. 2016 10:59

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

Message par **dsebire** » ven. 29 juil. 2016 11:50

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)

Message par **yoplait21** » ven. 29 juil. 2016 12:01

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 ?

Message par **dsebire** » ven. 29 juil. 2016 12:46

oui, c ça.
par contre, je vois pas trop pourquoi ça marche pas la....

Message par **kalistyan** » ven. 29 juil. 2016 13:10

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]

Message par **yoplait21** » ven. 29 juil. 2016 13:23

snirfff .. grand moment de solitude du coup ^^

Message par **dsebire** » ven. 29 juil. 2016 13:57

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

Message par **gizmo78** » ven. 29 juil. 2016 14:06

ton debian c'est une virtuelle?
SI oui, quoi comme virtualisation?

Message par **yoplait21** » ven. 29 juil. 2016 14:41

virtualisé oui, esx

Message par **yoplait21** » ven. 29 juil. 2016 14:45

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

Message par **poulpito** » ven. 29 juil. 2016 17:48

Fait pas un grep fait port 22 and host xxx.xxx.xxx.xxx

Message par **yoplait21** » ven. 29 juil. 2016 18:27

tcpdump port 22 host 172.16.16.2
tcpdump: syntax error

mouarf O_o ......

Message par **c0bw3b** » ven. 29 juil. 2016 18:36

te manque le 'and'

http://alumni.cs.ucr.edu/~marios/ethereal-tcpdump.pdf

Message par **yoplait21** » ven. 29 juil. 2016 19:12

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 ...

Message par **dsebire** » sam. 30 juil. 2016 08:44

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 ?

Message par **yoplait21** » sam. 30 juil. 2016 10:31

root@vpn-wan:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
root@vpn-wan:~#