Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

接続のデバッグ

接続をデバッグする

移行元データベースと移行先データベースの間の接続を設定しましたが、接続されているかどうかを確認するにはどうすればよいでしょうか。それらの間の通信に失敗した場合、何がどこでうまくいかなかったのかをどのようにして見つけることができるでしょうか。

最も基本的なツールは ping と traceroute です。

Ping

Ping は、宛先（「リモートホスト」）が送信元から利用可能かどうかを判断するための基本的なテストを実行します。Ping は ICMP Echo Request パケットをリモートホストに送信し、ICMP Echo Reply が返されることを想定しています。ping が正常に通らない場合、送信元から宛先へのルートはありません。ただし、成功したからといって、パケットが通過できるとは限りません。一般に、リモートホストに到達できることを意味するだけです。

ping によってホストが稼働中で応答することは確認できますが、信頼性は保証されません。一部のネットワークプロバイダでは、セキュリティ保護のため ICMP をブロックしているため、接続のデバッグは難しい場合があります。

traceroute

Traceroute は、あるホストから別のホストへのネットワークパケットの完全なルートをテストします。パケットが通過するすべてのステップ（「ホップ」）と、各ステップでの所要時間が表示されます。パケットが宛先まで到達できない場合、traceroute は完了せず、後ろには連続したアスタリスクが続きます。この場合、途中で正常に到達した最後の IP アドレスを確認します。ここが接続の途切れた場所になります。

Traceroute は、タイムアウトする場合があります。また、経路中のゲートウェイがパケットをネクストホップに渡すように正しく構成されておらず、完了しない場合もあります。

traceroute が完了しなかった場合、停止した場所を特定できる可能性があります。traceroute の出力に表示された最後の IP アドレスを見つけて、ブラウザで who owns [IP_ADDRESS] を検索します。結果にアドレスの所有者が表示されないこともありますが、試してみる価値はあります。

mtr

mtr ツールは traceroute の形式で、ローカルプロセスの top コマンドと同じように動作し続けて継続的に更新されます。

ローカル IP アドレスを確認する

ホストのローカルアドレスがわからない場合は、ip -br address show コマンドを実行します。Linux では、ネットワークインターフェース、インターフェースのステータス、ローカル IP、MAC アドレスが表示されます。例: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64。

あるいは、ipconfig や ifconfig を実行して、ネットワークインターフェースのステータスを確認することもできます。

送信 IP アドレスを確認する

ソースデータベースと宛先データベースが相互に通信するために使用する IP アドレス（送信 IP アドレス）がわからない場合は、次の手順を完了します。

Google Cloud コンソールで [SQL インスタンス] ページに移動します。
Cloud SQL の [インスタンス] ページに移動
デバッグする移行ジョブに関連付けられているインスタンスの名前をクリックします。
[このインスタンスとの接続] ペインが表示されるまで下にスクロールします。このペインに、送信 IP アドレスが表示されます。

開いているローカルポート

ホストがリッスンしていると思われるポートを確認するには、ss -tunlp4 コマンドを実行します。これにより、開いているポートとリッスンしているポートがわかります。

たとえば、動作している PostgreSQL データベースがある場合は、ポート 5432 が開いており、リッスンしています。SSH の場合は、ポート 22 が表示されます。

すべてのローカルポートアクティビティ

すべてのローカルポートアクティビティを表示するには、netstat コマンドを使用します。たとえば、netstat -lt を使用すると、現在アクティブなポートがすべて表示されます。

telnet を使用してリモートホストに接続する

TCP を使用してリモートホストに接続できることを確認するには、telnet コマンドを実行します。Telnet は、指定された IP アドレスとポートに接続しようとします。

たとえば、リモートホストで PostgreSQL データベースを実行している場合は、telnet 35.193.198.159 5432 と指定すると、ポート 5432 で telnet 接続できます。

成功すると、次のように表示されます。

Trying 35.193.198.159...
Connected to 35.193.198.159.

失敗すると、試行を強制終了するまで telnet が応答を停止します。

Trying 35.193.198.159...
^C

クライアント認証

クライアント認証は、pg_hba.conf という名前の構成ファイルで制御されます（HBA はホストベースの認証を意味します）。

ソースデータベース上の pg_hba.conf ファイルのレプリケーション接続セクションを更新して、Cloud SQL VPC の IP アドレス範囲からの接続を受け入れるようにします。

Cloud Logging

Database Migration Service と Cloud SQL は、Cloud Logging を使用します。詳細については、Cloud logging のドキュメントをご覧ください。また、Cloud SQL のサンプルクエリもご覧ください。

ログを表示

Cloud SQL インスタンスと、Cloud VPN や Compute Engine インスタンスなどのその他の Google Cloudプロジェクトのログを表示できます。Cloud SQL インスタンスのログエントリのログを表示するには:

コンソール

ログエクスプローラに移動
ページの上部で既存の Cloud SQL プロジェクトを選択します。
クエリビルダーに以下のクエリを追加します。
- リソース: [Cloud SQL データベース] を選択します。ダイアログで、Cloud SQL インスタンスを選択します。
- ログ名: Cloud SQL セクションまでスクロールし、インスタンスに適したログファイルを選択します。次に例を示します。
  - cloudsql.googleapis.com/postgres.log
- 重大度: ログレベルを選択します。
- 期間: プリセットを選択するか、カスタム範囲を作成します。

gcloud

gcloud logging コマンドを使用して、ログエントリを表示します。次の例では、PROJECT_ID を置き換えます。 limit フラグは、返されるエントリの最大数を示すオプションのパラメータです。

gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/postgres.log" --limit=10

プライベート IP アドレス

プライベート IP アドレスを使用した Cloud SQL インスタンスへの接続については、RFC 1918 アドレス範囲が自動的に承認されます。RFC 1918 以外のアドレス範囲は、Cloud SQL で認可済みネットワークとして構成される必要があります。また、RFC 1918 以外のルートをエクスポートするには、Cloud SQL へのネットワークピアリングを更新する必要もあります。例: gcloud compute networks peerings update cloudsql-postgres-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT

IP 範囲 172.17.0.0/16 は、Docker ブリッジネットワーク用に予約されています。この範囲内の IP アドレスで作成された Cloud SQL インスタンスはすべて到達不能になります。プライベート IP アドレスを使用して、この範囲内の IP アドレスから Cloud SQL インスタンスに接続することもできません。

VPN のトラブルシューティング

Google Cloud Cloud VPN のトラブルシューティングのページをご覧ください。

リバース SSH トンネルの問題のトラブルシューティング

SSH トンネリングは、SSH 接続を介して一部の通信を転送する方法です。リバース SSH トンネリングを使用すると、SSH トンネルを設定できますが、宛先ネットワークがトンネル接続を開始するネットワークであることを維持できます。これは、セキュリティ上の理由から、独自のネットワークでポートを開きたくない場合に便利です。

実現しようとしているのは、次の設定です。

Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

次のことを前提としています。

Compute Engine VM bastion は Cloud SQL DB にアクセスできます。
source network bastion は source DB にアクセスできます（これは、Cloud SQL ネットワークを Compute Engine VM ネットワークにピアリングすることで実現されます）。

次に、source network bastion から Compute Engine VM bastion への SSH トンネルを設定します。これにより、Compute Engine VM bastion のポートへの受信接続がトンネルを介して source DB にルーティングされます。

上記のシナリオの各リンクが不適切に設定されていると、フロー全体が機能しなくなる可能性があります。各リンクを 1 つずつトラブルシューティングします。

`source network bastion` ---> `source DB`

SSH を使用して source network bastion に接続します。ローカルマシンの場合は、ターミナルから接続します。
次のいずれかの方法で、ソース DB への接続をテストします。
- telnet [source_db_host_or_ip] [source_db_port] - Connected to x.x.x.x で終わる telnet 接続文字列が表示されます。
- psql -h [source_db_host_or_ip] -p [source_db_port] -U [username] -d [database_name] - パスワードの入力を求めるメッセージが表示されるか、アクセスが拒否されます。

この処理が失敗した場合は、この踏み台からソース DB へのアクセスが有効になっていることを確認する必要があります。

`Compute Engine VM bastion` ---> `source DB`

Compute Engine VM bastion に SSH 接続します（gcloud compute ssh VM_INSTANCE_NAME を使用）。
次のいずれかの方法で、ソース DB への接続をテストします。
- telnet 127.0.0.1 [tunnel_port] - Connected to x.x.x.x で終わる telnet 接続文字列が表示されます。
- psql -h 127.0.0.1 -p [tunnel_port] -U [username] -d [database_name] - パスワードプロンプトが表示されるか、アクセスが拒否されます。

この処理が失敗した場合は、トンネルが稼働していて、正しく機能していることを確認する必要があります。sudo netstat -tupln を実行すると、この VM でリッスンしているすべてのプロセスが表示されます。sshd listening on the tunnel_port が表示されます。

`Cloud SQL DB` ---> `source DB`

これは、Database Migration Service の testing the migration job でテストするのが最適です。これが失敗した場合は、Cloud SQL ネットワークと Compute Engine VM bastion ネットワーク間の VPC ピアリングまたはルーティングに問題があることを意味します。

ソースデータベースサーバーのファイアウォールは、Cloud SQL の宛先インスタンスが ipConfiguration 設定の privateNetwork フィールドとして使用する VPC ネットワークのプライベートサービス接続に割り当てられた内部 IP 範囲全体を許可するように構成する必要があります。

Console で内部 IP 範囲を確認するには:

Google Cloud コンソールの [VPC ネットワーク] ページに移動します。
使用する VPC ネットワークを選択します。
[プライベートサービスアクセス] > [サービスに割り当てられた IP 範囲] を選択します。
servicenetworking-googleapis-com によって作成された接続に関連付けられている内部 IP 範囲を見つけます。

Cloud SQL インスタンスと Compute Engine VM インスタンス間のトラフィックは、Cloud VPN gateway プロジェクトの Cloud Logging コンソールでも確認できます。Compute Engine VM ログで、Cloud SQL インスタンスからのトラフィックを探します。Cloud SQL インスタンスのログで、Compute Engine VM からのトラフィックを探します。