1 votes

Ryota avatar

VPN entre l'infra sur site et GCP : routes partagées mais le ping ne passe pas

Demandé el 21 de Décembre, 2019
Quand la question a-t-elle été
1448 affichage
Nombre de visites la question a
2 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

J'ai eu des difficultés avec la configuration du VPN entre on-prem et GCP pendant plus d'une semaine. Je suis complètement à court d'idées à ce stade, et j'aimerais obtenir de l'aide de spécialistes réseau.

Objectif

L'objectif final est simple : faire en sorte qu'une instance de VM sur GCP communique de manière transparente avec une VM on-prem - mais avec 2 routeurs en jeu.
La configuration est quelque chose comme ci-dessous :

       GCP_VM                                                           OP_VM
    10.0.0.25                                                    10.100.0.200
            |                                                    |
            |                                           (Passerelle du routeur DC)
            |                                               10.100.0.80
            |                                                    |
            -- HA_VPN (AS65001) <==========> Routeur (AS65002) --

     IP publique : xx.xx.xx.xx                   yy.yy.yy.yy
     Annonce : 10.0.0.0/24 BGP               10.100.0.0/24 BGP
  Plage IP VPN : 169.254.0.1/30                169.254.0.2 (en tant que pair)
    IP privée : NA                            10.100.0.50

La complication ici est que le Routeur n'est pas directement connecté à OP_VM. C'est la configuration on-prem sur laquelle nous n'avons aucun contrôle. OP_VM obtient son IP 10.100.0.200 d'un autre routeur, et notre Routeur est connecté au même LAN. Nous n'avons qu'une seule baie dans le centre de données, et nous devons atteindre OP_VM hébergé par une autre partie (dans une autre baie). Notre baie est associée à 10.100.0.50.

Et avec cela, je veux être capable de faire fonctionner ce qui suit :

me@GCP_VM:10.0.0.25:~$ ping 10.100.0.200

État actuel

Avec la configuration ci-dessus, le VPN et le BGP semblent sains d'après les journaux des deux côtés.

Depuis GCP_VM, je peux pinguer 10.100.0.50 (Routeur) avec succès.

me@GCP_VM:10.0.0.25:~$ ping 10.100.0.50
PING 10.100.0.50 (10.100.0.50) 56(84) octets de données.
64 octets de 10.100.0.50 : icmp_seq=1 ttl=254 temps=24.9 ms
...

Aussi, depuis Routeur, j'ai pu confirmer que je peux pinguer 10.100.0.200 (OP_VM).

# Avec la configuration du Routeur quelque chose comme
#
#     ip route 10.100.0.0/24 passerelle 10.100.0.80

root@Routeur:10.100.0.50:~$ ping 10.100.0.200
ping 10.100.0.200
provenant de 10.100.0.200 : icmp_seq=0 ttl=63 temps=0,583ms
provenant de 10.100.0.200 : icmp_seq=1 ttl=63 temps=0,571ms

2 paquets transmis, 2 reçus, perte 0 %, durée 0 ms

Depuis GCP_VM, cependant, le ping vers 10.100.0.200 (OP_VM) est manquant.

# Avec la configuration du Routeur quelque chose comme
#
#     ip route 10.100.0.0/24 passerelle 10.100.0.80

me@GCP_VM:10.0.0.25:~$ ping 10.100.0.200
PING 10.100.0.200 (10.100.0.200) 56(84) octets de données.
^C
--- 10.100.0.200 statistiques ping ---
4 paquets transmis, 0 reçus, perte 100 %, temps 3051ms

Je comprends probablement mal la configuration de la passerelle, mais en changeant la route comme ci-dessous me donne un résultat différent :

# Avec la configuration du Routeur quelque chose comme
#
#     ip route 10.100.0.0/24 passerelle 10.100.0.50
#                                             ~~ <- Routeur lui-même

me@GCP_VM:10.0.0.25:~$ ping 10.100.0.200
PING 10.100.0.200 (10.100.0.200) 56(84) octets de données.
De 169.254.0.2 icmp_seq=7 Hôte de destination injoignable
De 169.254.0.2 icmp_seq=6 Hôte de destination injoignable
De 169.254.0.2 icmp_seq=5 Hôte de destination injoignable
De 169.254.0.2 icmp_seq=4 Hôte de destination injoignable
De 169.254.0.2 icmp_seq=3 Hôte de destination injoignable
De 169.254.0.2 icmp_seq=2 Hôte de destination injoignable
De 169.254.0.2 icmp_seq=1 Hôte de destination injoignable
^C
--- 10.100.0.200 statistiques ping ---
9 paquets transmis, 0 reçus, +7 erreurs, perte 100 %, temps 8141ms
pipe 7

Avec cette configuration de passerelle, Routeur ne peut plus pinguer OP_VM. Il semble au moins que le VPN soit établi et l'IP soit diffusée correctement. Mais cela ne semble pas correct du point de vue du réseau réel.

Questions

Je ne pense pas qu'il y ait beaucoup plus à faire du côté de GCP, et le problème semble être purement du côté de l'on-prem.

Y a-t-il des problèmes de configuration ou des préoccupations qui pourraient causer un dysfonctionnement du VPN, du BGP, de l'ARP, etc.? Qu'est-ce qui pourrait causer un cas où les routes semblent être partagées, mais ne peuvent pas y accéder réellement?

Autres notes

  • J'ai confirmé que la table ARP sur Routeur inclut 10.100.0.200
  • Je vois les routes propagées dans GCP
  • J'ai testé la configuration du pare-feu de la VPC GCP pour autoriser 169.254.0.0/30 et 10.100.0.0/24
  • J'aurai besoin d'accès depuis GKE à la fin, mais j'ai confirmé que GKE obtient exactement le même comportement que GCP_VM
  • Routeur est de marque Yamaha
  • J'ai essayé TCPdump (packetdump dans les routeurs Yamaha), mais je n'ai pas vu 10.0.0.25 dans le journal

  • TCPdump a montré la trace de 10.0.0.25 lorsque j'ai exécuté nmap -Pn 10.100.0.200 depuis GCP_VM, mais avec une seule ligne comme celle-ci :

    2019/12/21 16:35:40: LAN1 OUT:IP TCP 10.100.0.227:50516 > 10.103.24.1:80

Mise à jour (24 décembre)

J'ai réalisé tcpdump pour un simple ping entre GCP_VM et Routeur.

De GCP_VM à Routeur (journaux de GCP_VM)

$ ping 10.100.0.50 > /dev/null &
$ sudo tcpdump -i eth0 | grep 10.100
...
18:49:18.696178 IP GCP_VM.(snip) > 10.100.0.50: ICMP demande d'écho
, id 32396, seq 0, longueur 64
18:49:18.700395 IP 10.100.0.50 > GCP_VM.(snip): Réponse d'écho ICMP, 
id 32396, seq 0, longueur 64

De Routeur à GCP_VM (journaux de GCP_VM)

# ping depuis le Routeur, avec `ping 10.0.0.25`
$ sudo tcpdump -i eth0 | grep 169.254
...
18:40:18.554555 IP 169.254.0.2 > GCP_VM.(snip): Demande d'écho ICMP,
 id 3369, seq 0, longueur 72
18:40:18.554586 IP GCP_VM.(snip) > 169.254.0.2: Réponse d'écho ICMP, i
d 3369, seq 0, longueur 72

Bien que tcpdump montre que la réponse est envoyée ici, elle n'est jamais reçue par le Routeur.
En outre, le ping vers 169.254.0.2 depuis GCP_VM n'a pas de réponse.

$ ping 169.254.0.2 > /dev/null &
$ sudo tcpdump -i eth0 | grep 169.254
...
18:59:07.113101 IP GCP_VM.(snip) > 169.254.0.2: Demande d'écho ICMP, i
d 32531, seq 0, longueur 64
18:59:08.137103 IP GCP_VM.(snip) > 169.254.0.2: Demande d'écho ICMP, i
d 32531, seq 1, longueur 64
...

Mise à jour (27 décembre)

Le ping depuis le Routeur a été réussi après avoir défini son adresse source sur 10.100.0.50, car il essayait d'utiliser 169.254.0.2 par défaut.

Le ping n'atteint toujours pas OP_VM, et je suis toujours confronté à un problème de configuration NAT pour assurer que la traduction se déroule correctement.

Mise à jour (31 décembre)

La connexion a finalement été établie. Je vais résumer les étapes prises dans une réponse distincte pour désembouteiller la question.

Demandé el 21 de Décembre, 2019 par Ryota

0 votes

Avatar de Serhii Rohoza

Veuillez ajouter votre solution comme vous l'avez mentionné dans votre dernière mise à jour.

Commenté el 13 de Janvier, 2020 par Serhii Rohoza

0 votes

Avatar de Ryota

J'ai ajouté des éclaircissements supplémentaires et la solution que j'ai dû mettre en place dans une réponse ci-dessous.

Commenté el 15 de Janvier, 2020 par Ryota

Réponses

Trop de publicités?

2voto

Serhii Rohoza avatar
Serhii Rohoza Points 1304

Il semble y avoir un problème de routage sur site. Je pense que OP_VM n'a pas de route vers 10.0.0.0/24 et envoie par défaut vers la passerelle DC Router Gateway où il est abandonné car DC Router Gateway (10.100.0.80) n'a également pas de route vers 10.0.0.0/24 (car il y a un peering sur Router).

Pour résoudre ce problème, vous devez définir une route statique sur OP_VM vers 10.0.0.0/24 via Router et conserver DC Router Gateway comme passerelle par défaut.

Vous devez supprimer la route ip route 10.100.0.0/24 gateway 10.100.0.50 de Router - le réseau 10.100.0.0/24 est directement connecté à lui.

MODIFIER

Depuis GCP_VM, je peux pinger 10.100.0.50 (Router) avec succès.

À ce stade, il semble que vous ayez configuré correctement un peering entre Router et HA_VPN.

Vous devriez pouvoir pinger GCP_VM et OP_VM depuis Router et également Router depuis OP_VM pour être sur la bonne voie.

Avec la configuration du routeur quelque chose comme

 ip route 10.100.0.0/24 gateway 10.100.0.80

Avec la configuration du routeur quelque chose comme

 ip route 10.100.0.0/24 gateway 10.100.0.80

Vous n'avez pas besoin de ces routes car Router est directement connecté au sous-réseau 10.100.0.0/24 et a une IP 10.100.0.50

Cependant, depuis GCP_VM, le ping vers 10.100.0.200 (OP_VM) est manquant.

C'est normal car OP_VM et DC Router Gateway n'ont pas de route vers 10.0.0.0/24OP_VM vers 10.0.0.0/24 via Router et conserver DC Router Gateway comme passerelle par défaut.

MODIFIER 2 OP_VM envoie des réponses à DC Router Gateway car il n'a pas de route vers 10.100.0.0/24 et essaie de l'atteindre via la passerelle par défaut, et à DC Router Gateway elles sont abandonnées car il n'y a pas non plus de route.

Vous devez ajouter une route statique sur OP_VM ou sur DC Router Gateway vers 10.100.0.0/24 pour résoudre ce problème.

Répondu el 23 de Décembre, 2019 par Serhii Rohoza (1304 Points )

0 votes

Avatar de Ryota

Merci pour l'information, je soupçonne également ce scénario. 10.0.0.0/24 est annoncé au Routeur via BGP, et cela devrait être suffisant pour le routage. Cependant, je constate que le ping du Routeur vers 10.0.0.25 échoue, bien que l'inverse fonctionne. Il semble qu'il manque quelque chose dans le Routeur, ou potentiellement dans la configuration du pare-feu GCP.

Commenté el 24 de Décembre, 2019 par Ryota

0 votes

Avatar de Serhii Rohoza

Le pare-feu sur GCP doit accepter le réseau sur site 10.100.0.0/24 que vous annoncez via BGP (doit être dans la table de routage du Routeur et après la mise en service avec HA_VPN) et vice versa, le pare-feu sur site doit accepter le réseau cloud 10.0.0.0/24 (le réseau 10.0.0.0/24 doit être dans la table de routage de HA_VPN et après la mise en service avec Routeur). Vous devez pouvoir pinguer tout dans le cloud depuis le Routeur et vice versa. Quel est la passerelle par défaut de votre Routeur?

Commenté el 24 de Décembre, 2019 par Serhii Rohoza

1 votes

Avatar de Ryota

FW est configuré sur GCP pour permettre le trafic vers/depuis 10.100.0.0/24, et sur site a la même configuration pour 10.0.0.0/24. J'ai effectué le tcpdump aux deux extrémités, et il semble que l'ICMP passe par les deux routes et traverse le FW correctement. J'ai mis à jour la question originale avec plus de détails. Mais il semble maintenant que la route de GCP vers 169.254.0.2 ne fonctionne pas. À ce stade, je ne suis pas sûr si cela est lié au problème principal de GCP_VM qui ne peut pas atteindre 10.100.0.200

Commenté el 24 de Décembre, 2019 par Ryota
Afficher 7 autres commentaires

1voto

Ryota avatar
Ryota Points 121

Après de nombreux tests et débogages, j'ai résolu le problème de connexion entre GCP et l'infra locale. Ce qui suit est la démarche entreprise, ainsi que les considérations prises en compte pour mettre en lumière le problème.

Analyses du trafic dans les deux directions

J'ai négligé de disséquer le trafic dans les deux directions. Cela signifie décomposer comment chaque paquet voyage de/vers la source/destination, ce qui donnerait une vue claire de l'origine du problème.

Paquets de GCP vers l'infra locale

  1. Paquet envoyé de GCP_VM (10.0.0.25) à HA_VPN (169.254.0.1/30)
  2. Paquet envoyé de GCP_VM (10.0.0.25) à Routeur (AS65002) (10.100.0.50)
  3. Paquet envoyé de GCP_VM (10.0.0.25) à Passerelle du Routeur du Centre de données (10.100.0.80)
  4. Paquet envoyé de GCP_VM (10.0.0.25) à OP_VM (10.100.0.200)
  5. Paquet envoyé de Routeur (AS65002) (10.100.0.50) à OP_VM (10.100.0.200)

Paquets de l'infra locale vers GCP (route de retour)

  1. Paquet envoyé de OP_VM (10.100.0.200) à Routeur (AS65002) (10.100.0.50)
  2. Paquet envoyé de OP_VM (10.100.0.200) à GCP_VM (10.0.0.25)
  3. Paquet envoyé de Routeur (AS65002) (10.100.0.50) à GCP_VM (10.0.0.25)

Étant donné les points de contrôle ci-dessus, voici les statuts :

  1. Cela n'a pas été testé, car le point de terminaison Cloud VPN (169.254.0.1/30) ne faisait pas partie des routes dans la VPC
  2. Je pouvais confirmer que le ping atteignait le Routeur (AS65002) (10.100.0.50), et que la réponse était renvoyée (cela signifie que le point #9 correspondant était également confirmé)
  3. Je n'ai PAS pu confirmer que le ping atteignait la Passerelle du Routeur du Centre de données (10.100.0.80), car le ping n'a pas reçu de réponse
  4. Je n'ai PAS pu confirmer que le ping atteignait le OP_VM (10.100.0.200), car le ping n'a pas reçu de réponse
  5. Je pouvais confirmer que le ping atteignait le OP_VM (10.100.0.200), et que la réponse était renvoyée (cela signifie que le point #7 correspondant était également confirmé)
  6. Comme mentionné, le point #6 a également confirmé ce trafic
  7. Aucun trafic ne correspond à ce cas
  8. Comme mentionné, le point #2 a également confirmé ce trafic

Voici le schéma pour décrire la situation :

    GCP_VM     HA_VPN (AS65001)     Routeur (AS65002)   (Passerelle du Routeur du Centre de données)    OP_VM
 10.0.0.25                          10.100.0.50        10.100.0.80            10.100.0.200

1. NA
2.    +--------------------------------> OK (réponse renvoyée)
3.    +----------------------------------------------------x NG ?
4.    +---------------------------------------------------------------------------x NG ?
5.                                      +-----------------------------------------> OK (réponse renvoyée)
6.                                   OK <-----------------------------------------+
7. Pas où envoyer le paquet ??  PERDU -------------------------------------------+
8. OK <--------------------------------+

Cela clarifie que tout trafic initié depuis GCP_VM peut présenter 2 problèmes potentiels :

  • Possibilité A. Le paquet n'atteint pas OP_VM (10.100.0.200)
  • Possibilité B. Le paquet atteint OP_VM (10.100.0.200), mais la réponse ne revient pas au Routeur (AS65002) (10.100.0.50)

Je pouvais confirmer avec les points #5 et #6 ci-dessus que le paquet atteint bien OP_VM (10.100.0.200) lorsque initié au Routeur (AS65002) (10.100.0.50). Cela signifie que la Possibilité A est peu probable. Le routage lui-même fonctionne comme il se doit.

Cela signifiait qu'il y avait une forte probabilité que la réponse du ping soit perdue et ne parvienne jamais au Routeur (AS65002) (10.100.0.50). Et pour mon cas spécifique ici, cette Possibilité B était la cause racine du problème.

Je pouvais confirmer que c'était le cas en créant un réseau simulé imitant le même setup ci-dessus, et en utilisant Wireshark pour écouter à chaque point. Cela signifiait que le schéma ci-dessous est le cas réel.

    GCP_VM     HA_VPN (AS65001)     Routeur (AS65002)   (Passerelle du Routeur du Centre de données)    OP_VM
 10.0.0.25                          10.100.0.50        10.100.0.80            10.100.0.200

1. NA
2.    +--------------------------------> OK (réponse renvoyée)
3.    +----------------------------------------------------> OK
4.    +---------------------------------------------------------------------------> OK
5.                                      +-----------------------------------------> OK (réponse renvoyée)
6.                                   OK <-----------------------------------------+
7.                  Où dois-je envoyer le paquet ??  PERDU -----------------------+
8. OK <--------------------------------+

Solution

Dans mon cas, lorsque le trafic démarre depuis GCP_VM, l'IP source était réglée sur 10.0.0.25. Cela signifiait que lorsque OP_VM essayait d'envoyer le trafic en retour, il ne pouvait pas trouver où se trouvait 10.0.0.25, et le paquet était perdu.

J'ai dû ajouter une entrée NAT statique au Routeur (AS65002) pour mapper l'IP source de 10.0.0.25 à 10.100.0.50 lorsque le paquet quitte le Routeur (AS65002), afin que le OP_VM puisse router correctement le trafic de retour vers le Routeur (AS65002). Après réception de la réponse, le NAT prend effet à nouveau, et le Routeur (AS65002) remplace alors 10.100.0.50 par 10.0.0.25 et envoie les paquets de retour vers GCP_VM.

Répondu el 15 de Janvier, 2020 par Ryota (121 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X