Déboguer la connectivité
Vous avez configuré la connectivité entre vos bases de données source et de destination, mais comment savoir qu'elles sont connectées ? Lorsque les communications entre eux échouent, comment pouvez-vous savoir où et pourquoi le problème est survenu ?
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 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 que les bases de données source et de destination utilisent pour communiquer entre elles (l'adresse IP sortante), procédez comme suit:
Accédez à la page "Instances SQL" dans la console Google Cloud.
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. Dans ce volet, l'adresse IP sortante s'affiche.
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 Cloudtels 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 du VPN Cloud.
Résoudre les problèmes liés aux tunnels SSH inversés
Le tunnel SSH est une méthode permettant de transférer certaines communications sur une connexion SSH. Le tunnel SSH inversé permet de configurer un tunnel SSH, tout en veillant à ce que le réseau de destination soit celui qui lance la connexion du tunnel. Cette option est utile lorsque vous ne souhaitez pas ouvrir de port dans votre propre réseau à des fins de sécurité.
Vous essayez de configurer ce qui suit : Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
Nous partons des hypothèses suivantes:
Le Compute Engine VM bastion peut accéder au Cloud SQL DB.
Le source network bastion peut accéder au source DB (cela est possible en établissant un peering entre le réseau Cloud SQL et le réseau de la VM Compute Engine).
Vous configurez ensuite un tunnel SSH de source network bastion vers Compute Engine VM bastion, qui achemine toutes les connexions entrantes vers un port sur Compute Engine VM bastion via le tunnel vers source DB.
Chaque maillon du scénario ci-dessus peut être mal configuré et empêcher l'ensemble du flux de fonctionner. 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 à partir du 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 se terminant parConnected to x.x.x.x.[db_client] -h[source_db_host_or_ip] -P[source_db_port]: l'accès devrait être refusé.
Si cette 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
- Se connecter à l'Compute Engine VM bastion via SSH (à 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 se terminant parConnected to x.x.x.x.[db_client] -h127.0.0.1 -P[tunnel_port]: l'accès devrait être refusé
Si cela échoue, vous devez vérifier que le tunnel est opérationnel.
L'exécution de sudo netstat -tupln affiche tous les processus d'écoute sur cette VM. sshd listening on the tunnel_port devrait s'afficher.
Cloud SQL DB ---> source DB
Il est préférable de le tester avec testing the migration job à partir de Database Migration Service.
Si l'opération échoue, cela signifie qu'il existe un problème d'appairage ou de routage 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 l'onglet CONNEXION AU SERVICE PRIVÉ.
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.