Bonjour,
J'ai contacté le support pour une question réseau (Ticket 2353561056) mais à part un mail générique, je n'ai pas eu de réponse à mon problème/question. Je vous la soumet ici en espérant avoir des billes…
J'ai installé pour un petit projet calico sur 2 noeuds kimsufi afin de faire un POC. La configuration par défaut fonctionnait, en particulier calico configuré en ipip (encapsulation IP in IP).
J'ai ensuite déployer de la même façon calico cette fois-ci sur 2 serveurs OVH Advance-2. Calico s'installe correctement mais je ne peux communiquer via calico entre mes applications (elles ne se ping pas). J'ai creusé le sujet avec les experts de calico et on en est arrivé à mettre en évidence que les paquets IP-in-IP étaient bien créés sur le 1er serveur, transitaient bien via l'interface de sortie avec le protocole IP-in-IP mais n'arrivaient pas au niveau du second serveur sur l'interface réseau d'entrée. Il y a quelque chose entre les deux qui filtre (drop) ces paquets, mais quoi?
Voici les trames IP de sortie du 1er serveur et d'entrée sur le second. J'ai modifié les vraies IP pour ne pas laisser de traces publiques.
- 1er serveur: ns3111111 / 54.44.44.144 / RBX7 Baie R709A16 / CentOS 8 / interface enp1s0f0
- 2nd serveur: ns88888888 / 51.155.155.55 / RBX7 Baie R717B04 / CentOS 8 / interface eno1
[root@ns3111111 ~]# tcpdump -nli enp1s0f0 proto 4
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp1s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:56:23.210730 IP 51.155.155.55 > 54.44.44.144: IP 10.233.101.195.60548 > 10.233.96.57.webcache: Flags [S], seq 2542447413, win 29200, options [mss 1460,sackOK,TS val 928610232 ecr 0,nop,wscale 7], length 0 (ipip-proto-4)
09:56:23.210780 IP 54.44.44.144 > 51.155.155.55: IP 10.233.96.57.webcache > 10.233.101.195.60548: Flags [S.], seq 2530656524, ack 2542447414, win 28960, options [mss 1460,sackOK,TS val 902363693 ecr 928610232,nop,wscale 7], length 0 (ipip-proto-4)
09:56:23.233342 IP 54.44.44.144 > 51.155.155.55: IP 10.233.96.3 > 10.233.101.129: ICMP echo request, id 14592, seq 0, length 64 (ipip-proto-4)
09:56:24.233392 IP 54.44.44.144 > 51.155.155.55: IP 10.233.96.3 > 10.233.101.129: ICMP echo request, id 14592, seq 1, length 64 (ipip-proto-4)
09:56:24.274216 IP 54.44.44.144 > 51.155.155.55: IP 10.233.96.57.webcache > 10.233.101.195.60548: Flags [S.], seq 2530656524, ack 2542447414, win 28960, options [mss 1460,sackOK,TS val 902364756 ecr 928610232,nop,wscale 7], length 0 (ipip-proto-4)
09:56:25.233439 IP 54.44.44.144 > 51.155.155.55: IP 10.233.96.3 > 10.233.101.129: ICMP echo request, id 14592, seq 2, length 64 (ipip-proto-4)
09:56:26.066220 IP 54.44.44.144 > 51.155.155.55: IP 10.233.96.57.webcache > 10.233.101.194.54126: Flags [S.], seq 2050427398, ack 3879540973, win 28960, options [mss 1460,sackOK,TS val 3017341428 ecr 1026291517,nop,wscale 7], length 0 (ipip-proto-4)
09:56:26.233511 IP 54.44.44.144 > 51.155.155.55: IP 10.233.96.3 > 10.233.101.129: ICMP echo request, id 14592, seq 3, length 64 (ipip-proto-4)
09:56:26.322263 IP 54.44.44.144 > 51.155.155.55: IP 10.233.96.57.webcache > 10.233.101.195.60548: Flags [S.], seq 2530656524, ack 2542447414, win 28960, options [mss 1460,sackOK,TS val 902366804 ecr 928610232,nop,wscale 7], length 0 (ipip-proto-4)
^C
9 packets captured
10 packets received by filter
0 packets dropped by kernel
[root@ns88888888 ~]# tcpdump -nli eno1 proto 4
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
09:56:23.214207 IP 51.155.155.55 > 54.44.44.144: IP 10.233.101.195.60548 > 10.233.96.57.webcache: Flags [S], seq 2542447413, win 29200, options [mss 1460,sackOK,TS val 928610232 ecr 0,nop,wscale 7], length 0 (ipip-proto-4)
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel
Est-ce que quelqu'un pourrait me dire si au niveau configuration réseau OVH/ADV-2 les trames IP-in-IP sont filtrées quelque part (à la différence de Kimsufi)?
Est-ce qu'il y a quelque chose à faire niveau serveur (je n'ai pas vu de firewall ou règles de filtrage sur les installation template CentOS 8 fournies par OVH)?
Merci de vos conseils et infos.
RN.
Alors aucune idée si ovh filtre quelque part.
Ce qui pourrait être utile ce serait de tester de déployer un vpn entre les 2 serveurs et tenter de communiquer à l'intérieur du vpn ?
ça permettrait de contourner un éventuel drop de paquet…
Les ADV-2 sont éligibles au vRack (https://www.ovhcloud.com/fr/bare-metal/advance/adv-2/#included avec un réseau 100Mb/s); je vais tenter (c'était dans mes options).
Ca va me prendre un peu de temps; si d'ici là quelqu'un a une info…
je n'ai pas parlé du vrack dans le cas où le filtrage aurait lieu également sur ce rzo 
Un vRack, c'est privé… j'espère qu'ils ne filtrent pas ça!!! Je vais tester, ça a l'air simple à mettre en place et à configurer via calico.
Jamais fait de VPN. Tu as un tuto quelque part pour mettre en place un vpn sur 2 serveurs linux CentOS 8 OVH?
perso j'utilise ça : http://1vpn.org/vpn.org/
Assez simple et fiable (quand on a comprit la logique).
Merci. J'essaierai avec un playbook ansible (https://github.com/thisismitch/ansible-tinc).
Pour info, le VPN avec Tinc a bien fonctionné. Les pods peuvent maintenant se pinger entre les noeuds.
Config: VPN + Calico (ipip)
J'ai eu un hic quand même. Mes pods (webapps) recevaient les requests (sur les pods des 2 nœuds), répondaient avec un 200 mais cette réponse n'était pas retournée au navigateur: Timeout (504) au niveau des logs de l'ingress; qui refaisait une tentative de request qui partait sur l'autre nœud qui lui répondait et transmettait la réponse au navigateur.
Pour contourner le problème, j'ai passé calico en mode vxlan et là ça marche.
Donc VPN + Calico (vxlan) fonctionne sur OVH.
J'en déduis donc qu'OVH filtre les paquests IPinIP transitant entre ses serveurs; et il ne le fait pas sur le réseau des nœuds Kimsufi.
Merci pour ce retour !
ça craint qu'ovh fasse du filtrage… testé sur le vrack aussi ?
Le but du vrack c'est justement d'avoir un rzo privé sans filtrage ni restriction…
J'ai configuré le vRack mais pas essayé.
Après je ne pense pas que ce soit plus intéressant que ça car le vRack OVH par défaut st limité à 100 Mbps alors que l'interface publique est à 1000 Mbps. Il faudrait voir au niveau perf si il y a une différence (démon tinc vs rien du tout) mais bon, là vu que ça marche je vais laisser comme ça pour l'instant… j'ai d'autres pb encore à fixer (perfs) 
Merci encore pour le tuyau.