Déboguer la connectivité

Déboguer la connectivité

Vous avez configuré la connectivité entre vos bases de données source et de destination, mais comment savoir si elles sont connectées ? Lorsque les communications entre eux échouent, comment pouvez-vous identifier le problème et son origine ?

Les outils les plus élémentaires sont ping et traceroute.

Ping

Ping effectue un test de base pour déterminer si la destination ("hôte distant") est disponible à partir de la source. Ping envoie un paquet ICMP Echo Request à un hôte distant et attend un ICMP Echo Reply en retour. Si ping échoue, il n'y a pas de route entre la source et la destination. Toutefois, un succès ne signifie pas que vos paquets peuvent passer, mais seulement qu'en général, l'hôte distant est accessible.

Si ping peut déterminer si un hôte est actif et en état de répondre, la fiabilité de ce dernier n'est pas garantie. Certains fournisseurs de réseau bloquent ICMP par mesure de sécurité, ce qui peut compliquer le débogage de la connectivité.

Traceroute

La commande Traceroute teste la route complète suivie par les paquets réseau d'un hôte à un autre. Elle montre l'ensemble des étapes ("sauts") parcourues par le paquet tout au long de son acheminement, ainsi que le temps nécessaire à chaque étape. Si le paquet ne parvient pas à destination, traceroute ne se termine pas, mais indique en sortie une série d'astérisques. Dans ce cas, identifiez la dernière adresse IP atteinte avec succès dans l'acheminement. C'est là que la connectivité s'est interrompue.

La commande Traceroute peut expirer. Elle peut également échouer si une passerelle située le long du trajet n'est pas correctement configurée pour transmettre le paquet au saut suivant.

Lorsque traceroute échoue, vous pouvez éventuellement savoir où elle s'est arrêtée. Recherchez la dernière adresse IP indiquée par la sortie de traceroute et faites une recherche sur who owns [IP_ADDRESS] dans un navigateur. Les résultats peuvent afficher ou non le propriétaire de l'adresse, mais cela vaut la peine d'essayer.

mtr

L'outil mtr est une variante de traceroute qui reste active et mise à jour en continu, de la même manière que la commande top pour le suivi des processus locaux.

Localiser votre adresse IP locale

Si vous ne connaissez pas l'adresse locale de votre hôte, exécutez la commande ip -br address show. Sous Linux, cette commande affiche l'interface réseau, l'état de l'interface, l'adresse IP locale et les adresses MAC. Exemple : eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64.

Vous pouvez également exécuter ipconfig ou ifconfig pour afficher l'état de vos interfaces réseau.

Localiser l'adresse IP sortante

Si vous ne connaissez pas l'adresse IP que les bases de données source et de destination utilisent pour communiquer entre elles (l'adresse IP sortante), procédez comme suit :

  1. Accédez à la page Clusters dans la console Google Cloud  :

    Accéder à la page "Clusters AlloyDB pour PostgreSQL"

  2. Recherchez le cluster AlloyDB pour PostgreSQL associé au job de migration que vous déboguez.
  3. Les deux adresses IP publiques sortantes apparaissent dans les détails de l'instance principale du cluster.

Ports locaux ouverts

Pour vérifier que votre hôte écoute bien sur les ports que vous pensez, exécutez la commande ss -tunlp4. Cela vous indique quels ports sont ouverts et à l'écoute.

Par exemple, si une base de données PostgreSQL est en cours d'exécution, le port 5432 doit être opérationnel et à l'écoute. Pour SSH, vous devriez voir apparaître le port 22.

Ensemble de l'activité sur les ports locaux

Exécutez la commande netstat pour afficher l'ensemble de l'activité des ports locaux. Par exemple, netstat -lt affiche tous les ports actuellement actifs.

Se connecter à l'hôte distant à l'aide de telnet

Pour vérifier que vous pouvez vous connecter à l'hôte distant à l'aide de TCP, exécutez la commande telnet. Telnet tente de se connecter à l'adresse IP et au port que vous lui indiquez.

Par exemple, si votre hôte distant exécute une base de données PostgreSQL, vous devriez pouvoir vous y connecter par telnet sur le port 5432 : telnet 35.193.198.159 5432.

En cas de réussite, les éléments suivants s'affichent : 

Trying 35.193.198.159...
Connected to 35.193.198.159.

En cas d'échec, telnet cesse de répondre jusqu'à ce que vous forciez sa fermeture : 

Trying 35.193.198.159...
^C

Authentification client

L'authentification du client est contrôlée par un fichier de configuration nommé pg_hba.conf (HBA signifie "authentification basée sur l'hôte").

Assurez-vous que la section des connexions de réplication du fichier pg_hba.conf de la base de données source est mise à jour pour accepter les connexions de la plage d'adresses IP du VPC AlloyDB pour PostgreSQL.

Cloud Logging

Database Migration Service et AlloyDB pour PostgreSQL utilisent Cloud Logging. Pour en savoir plus, consultez la documentation de Cloud Logging.

Afficher les journaux

Vous pouvez afficher les journaux des instances AlloyDB pour PostgreSQL et d'autres projets Google Cloudtels que des instances Cloud VPN ou Compute Engine. Pour afficher les journaux correspondant aux entrées de journal de votre instance AlloyDB pour PostgreSQL, procédez comme suit :

Console

  1. Accéder à l'explorateur de journaux
  2. Sélectionnez votre projet AlloyDB pour PostgreSQL en haut de la page.
  3. Dans le générateur de requêtes, ajoutez les éléments suivants :
    • Ressource : sélectionnez Instance AlloyDB pour PostgreSQL. Dans la boîte de dialogue, sélectionnez votre instance AlloyDB pour PostgreSQL.
    • Noms des journaux : faites défiler la page jusqu'à la section AlloyDB pour PostgreSQL et sélectionnez les fichiers journaux correspondant à votre instance. Par exemple :
      • alloydb.googleapis.com/postgres.log
    • Gravité : sélectionnez un niveau de journalisation.
    • Période : sélectionnez une valeur prédéfinie ou créez une période personnalisée.

gcloud

Exécutez la commande gcloud logging pour afficher les entrées de journal. Dans l'exemple ci-dessous, remplacez PROJECT_ID. L'option limit est un paramètre facultatif qui indique le nombre maximal d'entrées à renvoyer.

gcloud logging read "projects/PROJECT_ID/logs/alloydb.googleapis.com%2Fpostgres.log" --limit=10

Adresses IP privées

Les connexions à un cluster AlloyDB pour PostgreSQL à l'aide d'une adresse IP privée sont autorisées pour les plages d'adresses RFC 1918. Si votre réseau utilise des plages d'adresses non-RFC 1918, vous devez mettre à jour l'appairage de réseaux pour exporter les routes non-RFC 1918. Exemple : gcloud compute networks peerings update servicenetworking-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT.

La plage d'adresses IP 172.17.0.0/16 est réservée au réseau de la liaison Docker. Les connexions depuis n'importe quelle adresse IP de cette plage vers des clusters AlloyDB pour PostgreSQL utilisant une adresse IP privée échouent.

Dépannage du VPN

Consultez la page Google Cloud Dépannage de Cloud VPN.

Résoudre les erreurs de proxy TCP

La configuration du proxy TCP peut également entraîner des erreurs. Pour résoudre les problèmes d'une erreur de proxy TCP, consultez les exemples de problèmes suivants et découvrez comment les résoudre :

Échec du démarrage de la machine virtuelle (VM)

Le message suivant s'affiche lorsque vous démarrez l'instance de VM dans Compute Engine :

You do not currently have an active account selected.

À essayer

Exécutez l'une des commandes suivantes pour configurer un compte actif :

  • Pour obtenir de nouveaux identifiants, exécutez la commande suivante :

    gcloud auth login

  • Pour sélectionner un compte déjà authentifié, exécutez la commande suivante :

    gcloud config set account <var>ACCOUNT</var>

    Remplacez ACCOUNT par le nom du compte que vous souhaitez configurer.

Échec de la connexion à l'instance de base de données source

Le message d'erreur suivant s'affiche lorsque vous testez le job de migration :

Failure connecting to the source database. Make sure the connectivity information on the connection profile is correct and the source database is reachable.

À essayer

Suivez les étapes ci-dessous pour identifier l'origine du problème :

  1. Vérifiez si la VM hébergeant le conteneur du proxy TCP est en cours d'exécution :
    1. Dans la console Google Cloud , accédez à la page Instances de VM de Compute Engine.

      Accéder à la page Instances de VM

    2. Recherchez la VM créée lors du processus de configuration du proxy. S'il n'est pas listé ou s'il n'est pas en cours d'exécution, configurez votre proxy TCP de zéro et mettez à jour les paramètres du profil de connexion source dans le job de migration avec l'adresse IP correcte.
  2. Si la VM est en cours d'exécution, vérifiez qu'aucune erreur ne s'est produite lors du téléchargement de l'image de conteneur du proxy TCP :
    1. Sélectionnez la VM créée lors du processus de configuration du proxy TCP. Dans la section Journaux, cliquez sur Port série 1 (console).
    2. Si vous ne voyez pas l'entrée Launching user container 'gcr.io/dms-images/tcp-proxy' dans les journaux, il est possible que votre instance n'ait pas pu extraire l'image de Container Registry. Pour vérifier si c'est le cas, connectez-vous à la VM et essayez d'extraire manuellement l'image de Container Registry à l'aide de la commande suivante : 
      docker pull gcr.io/dms-images/tcp-proxy

      Si l'erreur Error response from daemon: Get "https://gcr.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) s'affiche, cela signifie que votre VM n'a pas pu se connecter à Container Registry. Si votre VM ne dispose que d'une adresse IP privée, vous devez activer l'accès privé à Google sur le sous-réseau dont l'adresse IP fait partie. Sinon, la VM n'aura pas accès aux API Google Enterprise, telles que Container Registry.

  3. Vérifiez que le conteneur peut se connecter à l'instance source :
    1. Sélectionnez la VM créée lors du processus de configuration du proxy. Sous Journaux, cliquez sur Cloud Logging.
    2. Si le message suivant s'affiche : Connection refused, please verify that the machine you are using to run the script can connect to the source database at, cela signifie que le conteneur du proxy TCP n'a pas pu se connecter à l'instance de base de données source. Plusieurs raisons peuvent expliquer cette situation :
      • L'adresse IP de l'instance source est incorrecte.
      • Une stratégie de pare-feu refuse les connexions du proxy TCP à l'instance source.
      • L'instance source se trouve dans un réseau cloud privé virtuel (VPC) différent de celui de la VM hébergeant le proxy TCP.

    Vous pouvez déboguer le problème de connectivité à l'aide des tests de connectivité de Google Cloudpour vous assurer qu'il existe une connectivité entre la VM hébergeant le proxy TCP et la base de données source :

    1. Dans la console Google Cloud , accédez à la page Tests de connectivité.

      Tests de connectivité

    2. Cliquez sur Créer des tests de connectivité.
    3. Saisissez un nom pour le test.
    4. Sélectionnez TCP comme protocole.
    5. Sélectionnez Adresse IP dans la liste Point de terminaison source. Saisissez l'adresse IP publique du proxy TCP que vous venez de créer si la base de données source est accessible à l'aide d'une adresse IP publique. Sinon, saisissez l'adresse IP privée du proxy TCP.
    6. Sélectionnez Adresse IP dans la liste Point de terminaison de destination, puis saisissez l'adresse IP de la base de données source.
    7. Saisissez le numéro de port utilisé pour se connecter à la base de données source dans le champ Port de destination.
    8. Cliquez sur Créer.

    Exécutez le test de connectivité et résolvez les problèmes de connectivité qui surviennent. Une fois le problème de connectivité résolu, vérifiez que le proxy TCP peut se connecter à l'instance source :

    1. Accédez à Instances de VM dans Compute Engine.

      Accéder à la page Instances de VM

    2. Sélectionnez la VM créée lors du processus de configuration du proxy. Sous Journaux, cliquez sur Cloud Logging.
    3. Si l'entrée de journal Connection to source DB verified s'affiche, cela signifie que le proxy TCP peut désormais se connecter à l'instance source.
  4. Vérifiez que le test de migration n'échoue pas en raison de problèmes de connexion.

Échec de la connexion au cluster de base de données de destination

Si le conteneur de proxy TCP peut se connecter à l'instance source, mais que le test de migration échoue toujours en raison de problèmes de connexion, le problème peut être lié à la connectivité entre le cluster AlloyDB pour PostgreSQL de destination et la VM hébergeant le conteneur de proxy TCP.

Déboguer le problème

Pour résoudre le problème, vous pouvez utiliser les tests de connectivité Google Cloudpour vous assurer qu'il existe une connectivité entre le cluster AlloyDB pour PostgreSQL de destination et la VM hébergeant le proxy TCP :

  1. Dans la console Google Cloud , accédez à la page Tests de connectivité.

    Tests de connectivité

  2. Cliquez sur Créer des tests de connectivité.
  3. Définissez les paramètres suivants pour votre test :
    1. Saisissez un nom pour le test.
    2. Sélectionnez TCP comme protocole.
    3. Sélectionnez Adresse IP dans la liste Point de terminaison source, puis saisissez l'adresse IP du cluster AlloyDB pour PostgreSQL que vous venez de créer.
    4. Sélectionnez Adresse IP dans la liste Point de terminaison de destination, puis saisissez l'adresse IP privée du proxy TCP.
    5. Saisissez 5432 dans le champ Port de destination.
  4. Cliquez sur Créer.
  5. Exécutez le test de connectivité et résolvez les problèmes de connectivité qui surviennent.

Causes possibles

Une règle de pare-feu refuse la communication entre le cluster de destination et la VM du proxy TCP.

À essayer

Ajoutez une règle de pare-feu qui permet au cluster de destination de communiquer avec le proxy TCP à l'aide du port 5432.

Causes possibles

Il existe une incompatibilité de VPC entre le cluster de destination et la VM exécutant le conteneur de proxy TCP.

À essayer

Sélectionnez le même VPC pour le cluster de destination.

Résoudre les problèmes liés aux tunnels SSH inversés

Le tunneling SSH est une méthode permettant de transférer certaines communications via une connexion SSH. Le tunneling SSH inversé permet de configurer un tunnel SSH, tout en maintenant que le réseau de destination est celui qui initie la connexion au tunnel. Cela est utile lorsque vous ne souhaitez pas ouvrir de port sur votre propre réseau pour des raisons de sécurité.

Vous essayez de configurer les éléments suivants :

AlloyDB for PostgreSQL cluster ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

Nous partons du principe que :

  • Le AlloyDB for PostgreSQL cluster peut accéder au Compute Engine VM bastion (pour ce faire, le réseau AlloyDB pour PostgreSQL est appairé au réseau de la VM Compute Engine).

  • Le source network bastion peut accéder au source DB.

Vous configurez ensuite un tunnel SSH entre l'source network bastion et l'Compute Engine VM bastion, qui achemine toutes les connexions entrantes vers un port de l'Compute Engine VM bastion via le tunnel vers l'source DB.

Chaque lien du scénario ci-dessus peut être configuré de manière incorrecte et empêcher l'ensemble du flux de fonctionner. Résolvez les problèmes de chaque lien, un par un :

source network bastion ---> source DB

  1. Connectez-vous à source network bastion à l'aide de SSH ou depuis le terminal s'il s'agit de la machine locale.
  2. Testez la connectivité à la base de données source à l'aide de l'une des méthodes suivantes :
    • telnet [source_db_host_or_ip] [source_db_port] : vous devriez voir les chaînes de connexion telnet, se terminant par Connected to x.x.x.x.
    • psql -h [source_db_host_or_ip] -p [source_db_port] -U [username] -d [database_name] : vous devriez voir une invite de mot de passe ou un message d'accès refusé.

Si l'opération échoue, vous devez vérifier que vous avez activé l'accès de ce bastion à la base de données source.

Compute Engine VM bastion ---> source DB

  1. Connectez-vous en SSH à Compute Engine VM bastion (à l'aide de gcloud compute ssh VM_INSTANCE_NAME).
  2. Testez la connectivité à la base de données source à l'aide de l'une des méthodes suivantes :
    • telnet 127.0.0.1 [tunnel_port] : vous devriez voir les chaînes de connexion telnet, se terminant par Connected to x.x.x.x.
    • psql -h 127.0.0.1 -p [tunnel_port] -U [username] -d [database_name] : vous devriez voir une invite de mot de passe ou un message d'accès refusé.

Si cela échoue, vous devez vérifier que le tunnel est opérationnel et fonctionne correctement. L'exécution de sudo netstat -tupln affiche tous les processus d'écoute sur cette VM. Vous devriez voir sshd listening on the tunnel_port.

AlloyDB for PostgreSQL cluster ---> source DB

Pour tester cela, le mieux est d'testing the migration job depuis Database Migration Service. Si cette opération échoue, cela signifie qu'il y a un problème d'appairage de VPC ou de routage entre le réseau AlloyDB pour PostgreSQL et le réseau Compute Engine VM bastion.

Le pare-feu du serveur de base de données source doit être configuré pour autoriser l'intégralité de la plage d'adresses IP internes allouée à la connexion de service privée du réseau VPC utilisé par le cluster de destination AlloyDB pour PostgreSQL.

Pour trouver la plage d'adresses IP internes dans la console, procédez comme suit :

  1. Accédez à la page "Réseaux VPC" dans la console Google Cloud .
  2. Sélectionnez le réseau VPC que vous souhaitez utiliser.
  3. Sélectionnez Accès aux services privés > Plages d'adresses IP allouées pour les services.
  4. Recherchez la plage d'adresses IP internes associée à la connexion créée par servicenetworking-googleapis-com.

Vous pouvez également afficher le trafic entre le cluster AlloyDB pour PostgreSQL et l'instance de VM Compute Engine dans la console Cloud Logging du projet Cloud VPN gateway. Dans les journaux de la VM Compute Engine, recherchez le trafic provenant du cluster AlloyDB pour PostgreSQL. Dans les journaux du cluster AlloyDB pour PostgreSQL, recherchez le trafic provenant de la VM Compute Engine.