[RÉSOLU] VM avec réseau privé + vrack + NAT

JonathanTron 2021-07-18 15:01:19 UTC #1

Bonjour,

je souhaites avoir des instances qui sortent sur le net via une autre instance qui fera le NAT (SNAT).

PRIVATE = machine sortant via le NAT (ubuntu 20.04)
NAT = machine avec réseaux privée + publique (ubuntu 20.04)

Je peux faire des ping NAT->PRIVATE et PRIVATE->NAT (pareil avec un simple nc -l 5000).
Un tcpdump sur la machine NAT me sort bien les paquets venant de PRIVATE de l'interface privée vers l'interface publique et le retour depuis l'interface publique vers l'interface privéee, par contre je ne reçois jamais les paquets retour sur PRIVATE.

Sur NAT je configure de la façon suivante:

sysctl -w net.ipv4.ip_forward=1
# ens3 = interface publique liée à Ext-Net
# ens4 = interface privée (ip statique 10.4.2.136)
iptables -t nat -A POSTROUTING -o ens3 -j SNAT --to IP_PUBLIQUE

Sur la machine PRIVATE:

# ens3 = interface privée (ip statique 10.4.2.129)
# pour forcer une gateway via NAT
ip route add 0.0.0.0/0 via 10.4.2.136 metric 99

ip r sur NAT:

default via 152.228.228.1 dev ens3 proto dhcp src IP_PUBLIQUE metric 100 
10.4.2.0/24 dev ens4 proto kernel scope link src 10.4.2.136
152.228.228.1 dev ens3 proto dhcp scope link src IP_PUBLIQUE metric 100

ip r sur PRIVATE:

default via 10.4.2.136 dev ens4 metric 99 
default via 152.228.228.1 dev ens3 proto dhcp src IP_PUBLIQUE_2 metric 100 
10.4.0.0/16 dev ens4 scope link 
10.4.2.0/24 dev ens4 proto kernel scope link src 10.4.2.129 
152.228.228.1 dev ens3 proto dhcp scope link src IP_PUBLIQUE_2 metric 100

iptables -xnvL sur NAT:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

iptables -xnvL sur NAT:

Chain PREROUTING (policy ACCEPT 6 packets, 1016 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 4 packets, 360 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 404 packets, 29223 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 117 packets, 8545 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
     287    20678 SNAT       all  --  *      ens3    0.0.0.0/0            0.0.0.0/0            to:IP_PUBLIQUE

Est-ce qu'il y a une limitation spéciale avec le NAT sur les private network / vrack ?

ArnaudM18 2021-07-19 07:27:16 UTC #2

Bonjour,

Non aucune limitation, vous rencontrez des soucis?

ArnaudM18 2021-07-19 07:29:45 UTC #3

Voici le script que jutilise pour faire le NAT sur mon router:

https://dl.plik.ovh/file/CZC6SN8PBhMdVRXg/3ehTfGsRc4xPCY8Q/router.sh

JonathanTron 2021-07-19 07:43:37 UTC #4

Bonjour @ArnaudM18,

oui tout semble bon sur le NAT, tcpdump/iptables logs me donne tout ce que j'attend, mais la machine PRIVATE ne reçoit jamais le paquet correspondant.

J'ai vu votre script sur un autre thread, et j'ai essayé mais j'ai le même résultat.

J'ai bien vérifié mes security group, et j'arrive bien à établir des connexions dans les deux sens en utilisant par example nc... Je suis à court d'idée de quoi checker.

ArnaudM18 2021-07-19 07:46:35 UTC #5

Vous pouvez check la MTU ?

Par defaut la MTU est plus eleve sur les interfaces vrack me semble-t-il.

JonathanTron 2021-07-19 08:03:53 UTC #6

Oui j'ai bien vérifié d'avoir 9000:

3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UP group default qlen 1000
    link/ether fa:16:3e:b8:42:bb brd ff:ff:ff:ff:ff:ff
    inet 10.4.2.136/24 brd 10.4.2.255 scope global ens4
       valid_lft forever preferred_lft forever

ArnaudM18 2021-07-19 08:23:57 UTC #7

Essayez avec 1500

JonathanTron 2021-07-19 08:29:51 UTC #8

ip link set dev ens4 mtu 1500
ip a show ens4

3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether fa:16:3e:e9:56:c2 brd ff:ff:ff:ff:ff:ff
    inet 10.4.2.136/24 brd 10.4.2.255 scope global ens4
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fee9:56c2/64 scope link 
       valid_lft forever preferred_lft forever

Voilà quelques logs tcpdump/iptables sur l'instance NAT pour un dig google.com lancé depuis le server PRIVATE.

tcpdump -vvvi ens3 proto UDP

08:21:59.841306 IP (tos 0x0, ttl 63, id 6482, offset 0, flags [DF], proto UDP (17), length 67)
    NAT_INSTANCE.49562 > cdns.ovh.net.domain: [udp sum ok] 17502+ [1au] A? google.com. ar: . OPT UDPsize=512 (39)
08:21:59.841307 IP (tos 0x0, ttl 63, id 6483, offset 0, flags [DF], proto UDP (17), length 67)
    NAT_INSTANCE.com.41889 > cdns.ovh.net.domain: [udp sum ok] 45715+ [1au] A? google.com. ar: . OPT UDPsize=512 (39)
08:21:59.852405 IP (tos 0x0, ttl 53, id 38483, offset 0, flags [none], proto UDP (17), length 83)
    cdns.ovh.net.domain > NAT_INSTANCE.com.41889: [udp sum ok] 45715 q: A? google.com. 1/0/1 google.com. [4m35s] A 216.58.213.142 ar: . OPT UDPsize=1232 (55)
08:21:59.852443 IP (tos 0x0, ttl 53, id 52103, offset 0, flags [none], proto UDP (17), length 83)
    cdns.ovh.net.domain > NAT_INSTANCE.com.49562: [udp sum ok] 17502 q: A? google.com. 1/0/1 google.com. [3m24s] A 172.217.13.110 ar: . OPT UDPsize=1232 (55)

tcpdump -vvvi ens4 host 10.4.2.129 and proto UDP

08:21:59.841306 IP (tos 0x0, ttl 64, id 48968, offset 0, flags [DF], proto UDP (17), length 67)
    PRIVATE_INSTANCE.36822 > cdns.ovh.net.domain: [udp sum ok] 43395+ [1au] A? google.com. ar: . OPT UDPsize=512 (39)
08:21:59.841307 IP (tos 0x0, ttl 64, id 48969, offset 0, flags [DF], proto UDP (17), length 67)
    PRIVATE_INSTANCE.56182 > cdns.ovh.net.domain: [udp sum ok] 18446+ [1au] A? google.com. ar: . OPT UDPsize=512 (39)
08:21:59.852405 IP (tos 0x0, ttl 52, id 11689, offset 0, flags [none], proto UDP (17), length 83)
    cdns.ovh.net.domain > PRIVATE_INSTANCE.36822: [udp sum ok] 43395 q: A? google.com. 1/0/1 google.com. [3m32s] A 216.58.213.142 ar: . OPT UDPsize=1232 (55)
08:21:59.852443 IP (tos 0x0, ttl 52, id 11690, offset 0, flags [none], proto UDP (17), length 83)
    cdns.ovh.net.domain > PRIVATE_INSTANCE.56182: [udp sum ok] 18446 q: A? google.com. 1/0/1 google.com. [3m32s] A 216.58.213.142 ar: . OPT UDPsize=1232 (55)

iptables -t nat -I POSTROUTING 1 -j LOG --log-prefix "NAT1:" --log-level 7

Jul 19 08:21:59 nat-sbg7-0 kernel: [  471.943456] NAT1:IN= OUT=ens3 SRC=10.4.2.129 DST=213.186.33.99 LEN=67 TOS=0x0
0 PREC=0x00 TTL=63 ID=48968 DF PROTO=UDP SPT=36822 DPT=53 LEN=47 
Jul 19 08:21:59 nat-sbg7-0 kernel: [  471.943540] NAT1:IN= OUT=ens3 SRC=10.4.2.129 DST=213.186.33.99 LEN=67 TOS=0x0
0 PREC=0x00 TTL=63 ID=48969 DF PROTO=UDP SPT=56182 DPT=53 LEN=47

JonathanTron 2021-07-19 08:36:46 UTC #9

Avec un peu plus de logs iptables:

iptables -I FORWARD 1 -j LOG --log-prefix "FWD1:" --log-level 7

Jul 19 08:35:44 nat-sbg7-0 kernel: [ 1296.196055] FWD1:IN=ens4 OUT=ens3 MAC=fa:16:3e:e9:56:c2:fa:16:3e:fb:20:a6:08:00 SRC=10.4.2.129 DST=213.186.33.99 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=29876 DF PROTO=UDP SPT=50270 DPT=53 LEN=47 
Jul 19 08:35:44 nat-sbg7-0 kernel: [ 1296.196058] NAT1:IN= OUT=ens3 SRC=10.4.2.129 DST=213.186.33.99 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=29876 DF PROTO=UDP SPT=50270 DPT=53 LEN=47 
Jul 19 08:35:44 nat-sbg7-0 kernel: [ 1296.286644] FWD1:IN=ens3 OUT=ens4 MAC=fa:16:3e:e1:f0:6b:8e:47:dc:7f:e1:0c:08:00 SRC=213.186.33.99 DST=10.4.2.129 LEN=83 TOS=0x00 PREC=0x00 TTL=52 ID=62905 PROTO=UDP SPT=53 DPT=50270 LEN=63 
Jul 19 08:35:44 nat-sbg7-0 kernel: [ 1296.286901] FWD1:IN=ens3 OUT=ens4 MAC=fa:16:3e:e1:f0:6b:8e:47:dc:7f:e1:0c:08:00 SRC=213.186.33.99 DST=10.4.2.129 LEN=83 TOS=0x00 PREC=0x00 TTL=52 ID=1604 PROTO=UDP SPT=53 DPT=60527 LEN=63

JonathanTron 2021-07-19 08:38:19 UTC #10

Je n'ai pas précisé avant, mais VMs dans SBG7.

ArnaudM18 2021-07-19 09:40:53 UTC #11

Tu peux me prendre une trace tcpdump sur ta GW:

tcpdump -lne -i any -w /tmp/trace.pcap icmp

Pendant que tu essayes de ping: 1.1.1.1 depuis ton prive?

Envoi en prive si ca derange.

Merci

JonathanTron 2021-07-19 15:05:57 UTC #12

Après pas mal de debug, @ArnaudM18 a finalement trouvé que le problème vient d'une config de l'hyperviseur, pour le fixer il va falloir modifier une config dans neutron.

Normalement c'est prévu pour cette semaine ou la semaine prochaine.

ArnaudM18 2021-07-27 13:39:33 UTC #13

Hello,

Cest good, j'ai prod le change dans neutron sur SBG7 (et seulement SBG7 pour le moment / GRA9 viendra plus tard).

Attention, en faisant la manipulation qui suit, votre port n'aura plus de regle de security group:

Il faut commencer par trouver les ports associes a votre instance:

openstack port list --server arnaud-gw

Ensuite, il faut supprimer le security group sur ce port:

openstack port set --no-security-group edc65b06-4c4a-4f9d-a2b3-251783119de6

Enfin, il faut desactiver les security checks:

openstack port set --disable-port-security edc65b06-4c4a-4f9d-a2b3-251783119de6

JonathanTron 2021-07-30 10:34:09 UTC #14

Salut,
merci pour le retour et la modif, je te confirme que ça fonctionne maintenant.

ArnaudM18 2021-07-30 12:04:14 UTC #15

impec.
Depuis jai prod toutes les regions, donc GRA9 est good aussi

d18c7f27213d5942a566 2023-05-17 07:06:15 UTC #16

Bonsoir,

Je me permet de remonter ce sujet assez vieux.
J'ai exactement le même soucis que @JonathanTron
J'ai tenté d'effectuer la manip de désactiver de la sécu sur le port LAN de ma GW, sans succès.
J'imagine que la conf Openstack a bien changé depuis 2 ans, est-ce qu'il y aurait une solution pour répondre à cette problématique?

Propulsé par Discourse, le rendu est meilleur avec le JavaScript activé

OVHcloud Community

Bienvenue sur votre espace communautaire. Posez des questions, recherchez des informations, publiez du contenu et interagissez avec d’autres membres d'OVHcloud Community.