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 vos communications échouent entre eux, comment pouvez-vous identifier le problème et son origine ?
Les outils les plus élémentaires sont ping et traceroute.
Ping
La commande Ping effectue un test de base pour déterminer si la destination ("hôte distant") est disponible depuis la source. Ping envoie un paquet ICMP Echo Request à un hôte distant et s'attend à recevoir un ICMP Echo Reply en retour. Si ping échoue, il n'y a pas de route entre la source et la destination. Si elle réussit, cela ne signifie pas pour autant que vos paquets peuvent transiter, mais que, de manière générale, 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 utilisée par les bases de données source et de destination pour communiquer entre elles (adresse IP sortante), procédez comme suit :
Accédez à la page "Instances SQL" dans Google Cloud console.
Cliquez sur le nom de l'instance associée à la tâche de migration que vous déboguez.
Faites défiler la page jusqu'à ce que le volet Se connecter à cette instance s'affiche. L'adresse IP sortante s'affiche dans ce volet.
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.
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 Cloud SQL.
Cloud Logging
Database Migration Service et Cloud SQL utilisent Cloud Logging. Consultez la documentation de Cloud Logging pour obtenir des informations complètes et accéder à des exemples de requêtes Cloud SQL.Afficher les journaux
Vous pouvez afficher les journaux des instances Cloud SQL et d'autres projets Google Cloud tels que des instances Cloud VPN ou Compute Engine. Pour afficher les journaux correspondant aux entrées de journal de votre instance Cloud SQL, procédez comme suit :Console
- Accéder à l'explorateur de journaux
- Sélectionnez un projet Cloud SQL existant en haut de la page.
- Dans le générateur de requêtes, ajoutez les éléments suivants :
- Ressource : sélectionnez Base de données Cloud SQL. Dans la boîte de dialogue, sélectionnez une instance Cloud SQL.
- Noms des journaux : faites défiler la page jusqu'à la section Cloud SQL et sélectionnez les fichiers journaux correspondant à votre instance. Par exemple :
- cloudsql.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/cloudsql.googleapis.com/postgres.log" --limit=10
Adresses IP privées
Les connexions à une instance Cloud SQL à l'aide d'une adresse IP privée sont automatiquement autorisées pour les plages d'adresses RFC 1918. Les plages d'adresses non-RFC 1918 doivent être configurées dans Cloud SQL en tant que réseaux autorisés. Vous devez mettre à jour l'appairage de réseaux vers Cloud SQL pour exporter les routes non-RFC 1918. Par exemple, gcloud compute networks peerings update cloudsql-postgres-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. De même, les instances Cloud SQL créées avec une adresse IP de cette plage sont inaccessibles. Les connexions depuis n'importe quelle adresse IP de cette plage vers des instances Cloud SQL utilisant une adresse IP privée échouent.
Dépannage du VPN
Consultez la page Google Cloud Dépannage de Cloud VPN.
Résoudre les problèmes liés au tunnel SSH inversé
Le tunneling SSH est une méthode permettant de transférer certaines communications sur une connexion SSH. Le tunneling SSH inversé permet de configurer un tunnel SSH, mais en veillant à ce que le réseau de destination soit celui qui initie la connexion au tunnel. Cela est utile lorsque vous ne souhaitez pas ouvrir de port dans votre propre réseau pour des raisons de sécurité.
Vous devez configurer les éléments suivants : Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
Nous partons du principe que :
Le Compute Engine VM bastion peut accéder à Cloud SQL DB.
Le source network bastion peut accéder au source DB (pour ce faire, le réseau Cloud SQL est appairé au réseau de VM Compute Engine).
Vous configurez ensuite un tunnel SSH du source network bastion vers le Compute Engine VM bastion, qui achemine toutes les connexions entrantes vers un port du Compute Engine VM bastion via le tunnel vers le source DB.
Chaque lien du scénario ci-dessus peut être mal configuré et empêcher le bon fonctionnement de l'ensemble du flux. Résolvez les problèmes liés à chaque lien, un par un :
source network bastion ---> source DB
- Connectez-vous à source network bastion à l'aide de SSH ou depuis le terminal s'il s'agit de la machine locale.
- 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, qui se terminent parConnected to x.x.x.x.[db_client] -h[source_db_host_or_ip] -P[source_db_port]- expect to see access denied
Si cela é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
- Ouvrez une session SSH sur Compute Engine VM bastion (à l'aide de
gcloud compute ssh VM_INSTANCE_NAME). - 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, qui se terminent parConnected to x.x.x.x.[db_client] -h127.0.0.1 -P[tunnel_port]: l'accès devrait être refusé
Si cela ne fonctionne pas, 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.
Cloud SQL DB ---> source DB
La meilleure façon de le tester est d'utiliser testing the migration job depuis Database Migration Service.
Si cela échoue, cela signifie qu'il y a un problème d'appairage ou de routage de VPC entre le réseau Cloud SQL 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 que l'instance de destination Cloud SQL utilisera comme champ privateNetwork dans ses paramètres ipConfiguration.
Pour trouver la plage d'adresses IP internes dans la console, procédez comme suit :
Accédez à la page "Réseaux VPC" dans la console Google Cloud .
Sélectionnez le réseau VPC que vous souhaitez utiliser.
Sélectionnez Accès aux services privés > Plages d'adresses IP allouées pour les services.
Recherchez la plage d'adresses IP internes associée à la connexion créée par servicenetworking-googleapis-com.
Vous pouvez également afficher le trafic entre l'instance Cloud SQL 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 de l'instance Cloud SQL. Dans les journaux de l'instance Cloud SQL, recherchez le trafic provenant de la VM Compute Engine.