Public Cloud OVHcloud – [RÉSOLU] VM avec réseau privé + vrack + NAT
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
question

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

J
Par
JonathanTron
Créé le 2021-07-18 15:01:19 (edited on 2024-11-18 11:03:20) dans Public Cloud OVHcloud

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 ?
Avis positifs (0)
2513 Vues
1 réponse ( Latest reply on 2024-11-18 11:04:42 Par
CyrilD37
)
A

Bonjour,

Non aucune limitation, vous rencontrez des soucis?
Utile (0)
A

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

https://dl.plik.ovh/file/CZC6SN8PBhMdVRXg/3ehTfGsRc4xPCY8Q/router.sh
Utile (0)
J

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.
Utile (0)
A

Vous pouvez check la MTU ?

Par defaut la MTU est plus eleve sur les interfaces vrack me semble-t-il.
Utile (0)
J

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

```
3: ens4: 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
```
Utile (0)
A

Essayez avec 1500
Utile (0)
J

`ip link set dev ens4 mtu 1500`
`ip a show ens4`
```
3: ens4: 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
```
Utile (0)
J

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
```
Utile (0)
J

Je n'ai pas précisé avant, mais VMs dans `SBG7`.
Utile (0)
A

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
Utile (0)
J

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.
Utile (0)
A

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
Utile (0)
J

Salut,
merci pour le retour et la modif, je te confirme que ça fonctionne maintenant.
Utile (0)
A

impec.
Depuis jai prod toutes les regions, donc GRA9 est good aussi
Utile (0)
D

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?
Utile (0)
C

Hello,
Je viens de tester les commandes de Arnaud sur des machines nouvellement louées et ça a fonctionné.
Merci beaucoup !
Utile (0)

Rejoindre la discussion