VM 間の内部接続をトラブルシューティングする
このドキュメントでは、同じ Virtual Private Cloud（VPC）ネットワーク（共有 VPC またはスタンドアロン）内または VPC ネットワーク ピアリングで接続された 2 つの VPC ネットワーク内にある Compute Engine VM 間の接続のトラブルシューティングについて説明します。ここでは、VM がそれぞれの仮想ネットワーク インターフェース コントローラ（vNIC）の内部 IP アドレスを使用して通信していることを前提としています。
このガイドの手順は、Compute Engine VM と Google Kubernetes Engine ノードの両方に適用されます。
その他のトラブルシューティングのシナリオについては、ページの下部にある [フィードバックを送信] をクリックしてお知らせください。
このガイドの説明は、次の VM と VPC の構成に適用されます。
- 単一 VPC ネットワーク内での内部 IP アドレスを使用した VM 間の接続。
- 共有 VPC ネットワーク内での内部 IP アドレスを使用した VM 間の接続。
- VPC ネットワーク ピアリングでピアリングされた複数の VPC ネットワークでの内部 IP アドレスを使用した VM-VM 間の接続。
このガイドで使用しているコマンドは、Google が提供するすべての OS イメージで使用できます。独自の OS イメージを使用している場合は、ツールのインストールが必要になることがあります。
問題を定量化する
- 完全なパケットロスが発生していると思われる場合は、完全な接続エラーのトラブルシューティングをご覧ください。
- レイテンシが発生している場合、部分的なパケットロス、または接続の途中でタイムアウトが発生している場合は、ネットワーク レイテンシまたはスループット低下の原因となる損失のトラブルシューティングをご覧ください。
完全な接続エラーのトラブルシューティング
以下のセクションでは、VM 間の完全な内部接続エラーをトラブルシューティングする手順を説明します。レイテンシや断続的な接続タイムアウトが増加している場合は、ネットワーク レイテンシまたはスループット低下の原因となる損失のトラブルシューティングに進んでください。
接続値を決定する
まず、次の情報を収集します。
- [VM インスタンス] ページで、両方の VM について次の情報を収集します。
- VM 名
- VM ゾーン
- 通信している vNIC の内部 IP アドレス
宛先のサーバー ソフトウェアの構成で、次の情報を収集します。
- レイヤ 4 プロトコル
- 宛先ポート
たとえば、宛先が HTTPS サーバーの場合、プロトコルは TCP でポートは通常
443ですが、特定の構成では別のポートが使用されていることがあります。
複数の VM で問題が発生した場合は、問題が発生している単一の VM と宛先の VM を選択し、それらの値を使用します。一般に、接続の送信元ポートは必要ありません。
これらの情報を取得したら、基盤となる Google ネットワークの問題を調査するに進みます。
基盤となる Google ネットワークの問題を調査する
最近変更された設定がある場合は、基盤となる Google ネットワークに問題がある可能性があります。Network Intelligence Center のパフォーマンス ダッシュボードで、VM ゾーン間のパケットロスを確認します。ネットワーク タイムアウトの期間中にゾーン間のパケットロスが増加した場合は、仮想ネットワークの基盤となる物理ネットワークに問題がある可能性があります。サポートケースを送信する前に、Google Cloud ステータス ダッシュボードで既知の問題を確認してください。
原因が基盤となる Google ネットワークにあると思われる場合は、Google Cloud ファイアウォール ルールの構成ミスを確認するに進みます。
Google Cloud で正しく構成されていないファイアウォール ルールを確認する
接続テストでは、2 つの VM 間の VPC ネットワーク パス構成を分析し、プログラムされた構成でトラフィックが許可されるべきかどうかが示されます。トラフィックが許可されていない場合、Google Cloud の下り（外向き）または上り（内向き）ファイアウォール ルールによってトラフィックがブロックされているのか、ルートが利用できないのかが表示されます。
接続テストでは、VM のハイパーバイザ間でパケットを送信して、パスを動的にテストすることもできます。これらのテストを行うと、テスト結果が表示されます。
接続テストでは、VPC ネットワークの構成のみを調べます。オペレーティング システムのファイアウォール、オペレーティング システムのルート、VM 上のサーバー ソフトウェアはテストされません。
次の手順では、Google Cloud コンソールから接続テストを実行します。テストを実行するその他の方法については、接続テストの実施をご覧ください。
テストを作成して実行する手順は次のとおりです。
Google Cloud コンソールで、[接続テスト] ページに移動します。
プロジェクトのプルダウン メニューで、正しいプロジェクトにいることを確認するか、正しいプロジェクトを指定します。
[接続テストを作成] をクリックします。
テストに名前を付けます。
以下を指定します。
- プロトコル
- 送信元エンドポイントの IP アドレス
- ソース プロジェクトと VPC ネットワーク
- 宛先エンドポイントの IP アドレス
- 宛先プロジェクトと VPC ネットワーク
- 宛先ポート
[作成] をクリックします。
テストはすぐに実行されます。結果を確認するには、[結果の詳細] 列の [表示] をクリックします。
- Google Cloud ファイアウォール ルールによって破棄されている場合は、目的のセキュリティ設定で接続を許可する必要があります。詳しくは、セキュリティ管理者またはネットワーク管理者にご確認ください。トラフィックを許可する場合は、次の点を確認します。
- 常にブロックされるトラフィックのリストを確認します。トラフィックが、常にブロックされるトラフィックのリストにあり、Google Cloud によってブロックされている場合、既存の構成は機能しません。
- [ファイアウォール ポリシー] ページに移動して、ファイアウォール ルールを確認します。ファイアウォールが正しく構成されていない場合は、ファイアウォール ルールを作成または変更して接続を許可します。ルールには、VPC ファイアウォール ルールまたは階層型ファイアウォール ポリシールールを使用できます。
- このトラフィックをブロックするファイアウォール ルールが正しく構成されている場合は、セキュリティ管理者またはネットワーク管理者に確認してください。組織のセキュリティ要件により、VM が相互に接続すべきでない場合は、設定を再設計する必要があります。
- 結果が VPC 接続パスに問題がないことを示す場合、問題は次のいずれかである可能性があります。
- ゲスト OS 構成に関する問題（ファイアウォール ソフトウェアに関する問題など）。
- クライアントまたはサーバー アプリケーションに関する問題（アプリケーションがフリーズする場合や、誤ったポートでリッスンするように構成された場合など）
以降の手順では、これらの可能性をそれぞれ調べる方法を説明します。VM 内から TCP 接続をテストするに進みます。
VM 内から TCP 接続をテストする
VM 間の接続テストで VPC 構成に問題が検出されなかった場合は、OS 間の接続テストを開始します。次の手順では、以下のことを確認できます。
- 指定されているポートで TCP サーバーがリッスンしているかどうか
- サーバー側のファイアウォール ソフトウェアで、クライアント VM からのポートへの接続が許可されているかどうか
- クライアント側のファイアウォール ソフトウェアで、サーバーからのポートへの接続が許可されているか
- サーバー側ルートテーブルがパケットを転送するように正しく構成されているか
- クライアント側ルートテーブルがパケットを転送するように正しく構成されているか
TCP handshake をテストするには、Linux または Windows 2019 で curl を使用するか、Windows PowerShell で New-Object System.Net.Sockets.TcpClient コマンドを使用します。このセクションのワークフローでは、接続成功、接続タイムアウト、接続セットのいずれかの結果を得ることができます。
- 成功: TCP handshake が正常に完了すると、OS ファイアウォール ルールによって接続がブロックされません。OS はパケットを正しく転送し、なんらかのサーバーが宛先ポートでリッスンします。この場合、アプリケーション自体に問題がある可能性があります。詳細については、サーバー ロギングでサーバーの動作を確認するをご覧ください。
- タイムアウト: 接続がタイムアウトした場合、通常は次のいずれかを意味します。
- その IP アドレスにマシンが存在しない
- ファイアウォールが通知せずにパケットを破棄している
- OS パケットのルーティングが、処理できない宛先にパケットを送信しているか、非対称ルーティングが、無効なパスでリターン パケットを送信している
リセット: 接続がリセットされている場合、宛先 IP がパケットを受信していますが、OS またはアプリケーションがパケットを拒否しています。これは次のいずれかを意味します。
- パケットが間違ったマシンに到達し、そのポート上でプロトコルに応答するように構成されていない
- パケットは正しいマシンに到達しているが、そのポートでリッスンしているサーバーがない
- パケットは正しいマシンとポートに到達しているが、上位レベルのプロトコル（SSL など）で handshake が完了していない
- ファイアウォールが接続をリセットしている。ファイアウォールが通知なくパケットを破棄する場合と比べると、可能性は低くなりますが、発生する可能性がないわけではありません。
Linux
Google Cloud コンソールで [ファイアウォール ポリシー] ページに移動します。
IAP から VM への SSH 接続を許可するファイアウォール ルールがあることを確認するか、新しいルールを作成します。
Google Cloud コンソールで [VM インスタンス] ページに移動します。
移行元の VM を確認します。
その VM の [接続] 列で [SSH] をクリックします。
クライアント マシンのコマンドラインから、次のコマンドを実行します。DEST_IP:DEST_PORT は、宛先 IP アドレスとポートに置き換えます。
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
Windows
Google Cloud コンソールで [VM インスタンス] ページに移動します。
移行元の VM を確認します。
Windows VM への接続で説明されている方法で VM に接続します。
クライアント マシンのコマンドラインから、次のコマンドを実行します。
- Windows 2019:
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
- Windows 2012 または Windows 2016 Powershell:
PS C:> New-Object System.Net.Sockets.TcpClient('DEST_IP',DEST_PORT)`
- Windows 2019:
接続成功
次の結果は、TCP handshake が成功したことを示しています。TCP handshake が正常に完了した場合、問題は TCP 接続のタイムアウトまたはリセットに関連していません。タイムアウトの問題はアプリケーション レイヤ内で発生します。接続が成功した場合は、サーバー ロギングでサーバーの動作を確認するに進みます。
Linux と Windows 2019
$ curl -vso /dev/null --connect-timeout 5 192.168.0.4:443
[接続先] 行に、TCP handshake の成功が示されます。
Expire in 0 ms for 6 (transfer 0x558b3289ffb0) Expire in 5000 ms for 2 (transfer 0x558b3289ffb0) Trying 192.168.0.4... TCP_NODELAY set Expire in 200 ms for 4 (transfer 0x558b3289ffb0) Connected to 192.168.0.4 (192.168.0.4) port 443 (#0) > GET / HTTP/1.1 > Host: 192.168.0.4:443 > User-Agent: curl/7.64.0 > Accept: */* > Empty reply from server Connection #0 to host 192.168.0.4 left intact
Windows 2012 と 2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
接続成功の結果。「Connected: True」行が関連します。
Available : 0 Client : System.Net.Sockets.Socket Connected : True ExclusiveAddressUse : False ReceiveBufferSize : 131072 SendBufferSize : 131072 ReceiveTimeout : 0 SendTimeout : 0 LingerState : System.Net.Sockets.LingerOption NoDelay : False
接続タイムアウト
次の結果は、接続がタイムアウトしたことを示します。接続がタイムアウトしている場合は、サーバーの IP アドレスとポートを確認するに進みます。
Linux と Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
接続タイムアウトの結果:
Trying 192.168.0.4:443... Connection timed out after 5000 milliseconds Closing connection 0
Windows 2012 と 2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
接続タイムアウトの結果:
New-Object: Exception calling ".ctor" with "2" argument(s): "A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. 192.168.0.4:443"
接続リセット
リセットは、デバイスがクライアントに RST パケットを返し、接続の終了をクライアントに通知するものです。次のいずれかの理由で接続がリセットされる場合があります。
- 受信サーバーが、そのポートでそのプロトコル接続を受け入れるように構成されていない。パケットが間違ったサーバーまたはポートに送信されたか、サーバー ソフトウェアが正しく構成されなかった。
- ファイアウォール ソフトウェアが接続の試みを拒否した
接続がリセットされた場合は、正しい IP アドレスとポートにアクセスしていることを確認するに進みます。
Linux と Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
接続リセットの結果:
Trying 192.168.0.4:443... connect to 192.168.0.4 port 443 failed: Connection refused Failed to connect to 192.168.0.4 port 443: Connection refused Closing connection 0
Windows 2012 と 2016
PS C:\> New-Object System.Net.Sockets.TcpClientt('DEST_IP_ADDRESS', PORT)
接続リセットの結果:
New-Object: Exception calling ".ctor" with "2" argument(s): "No connection could be made because the target machine actively refused it. 192.168.0.4:443"
サーバーの IP アドレスとポートを確認する
サーバーで次のいずれかのコマンドを実行します。これは、必要なポートをリッスンしているサーバーがあるかどうかを示します。
Linux
$ sudo netstat -ltuvnp
出力には、TCP サーバーがポート 22 で任意の送信元アドレス（0.0.0.0）と任意の送信元ポート（*）から任意の宛先 IP アドレス（0.0.0.0）をリッスンしていることが示されます。「PID / プログラム名」列に、ソケットにバインドされた実行可能ファイルが示されます。
Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 588/sshd tcp6 0 0 :::22 :::* LISTEN 588/sshd udp 0 0 0.0.0.0:68 0.0.0.0:* 334/dhclient udp 0 0 127.0.0.1:323 0.0.0.0:* 429/chronyd udp6 0 0 ::1:323 :::* 429/chronyd
Windows
PS C:\> Get-NetTcpConnection -State "LISTEN" -LocalPort DEST_PORT
出力には、DEST_PORT が 443 に設定されたコマンドの実行結果が示されます。この出力は、TCP サーバーがポート 443 で任意のアドレス（0.0.0.0）をリッスンし、任意の送信元アドレス（0.0.0.0）と任意の送信元ポート（0）からの接続を受け入れています。「OwningProcess」列には、ソケットをリッスンするプロセスのプロセス ID を示します。
LocalAddress LocalPort RemoteAddress RemotePort State AppliedSetting OwningProcess ------------ --------- ------------- ---------- ----- -------------- ------------- :: 443 :: 0 Listen 928 0.0.0.0 443 0.0.0.0 0 Listen 928
サーバーが正しいポートまたは IP にバインドされていないか、リモート プレフィックスがクライアントと一致しない場合は、サーバーのドキュメントまたはベンダーに問い合わせて、問題を解決してください。サーバーは特定のインターフェースの IP アドレスまたは 0.0.0.0 にバインドされ、正しいクライアント IP プレフィックスまたは 0.0.0.0 からの接続を受け入れる必要があります。
アプリケーション サーバーが正しい IP アドレスとポートにバインドしている場合は、クライアントが誤ったポートにアクセスしているか、上位レベルのプロトコル（多くの場合 TLS）が接続を拒否しているか、または接続を承認しないファイアウォールがあることが示されています。
クライアントとサーバーが同じ TLS バージョンと暗号化形式を使用していることを確認します。
クライアントが正しいポートにアクセスしていることを確認します。
上記の手順で問題が解決しない場合は、クライアントとサーバーでファイアウォールの破棄を確認するに進みます。
クライアントとサーバーのファイアウォールでパケットの破棄を確認する
サーバーがクライアント VM からアクセスできないものの、正しいポートをリッスンしている場合は、接続に関連付けられたパケットを破棄しているファイアウォール ソフトウェアを実行している VM が存在する可能性があります。次のコマンドを使用して、クライアント VM とサーバー VM の両方でファイアウォールを確認します。
ルールによってトラフィックがブロックされる場合は、ファイアウォール ソフトウェアを更新してトラフィックを許可します。ファイアウォールを更新する場合は、コマンドの構成と実行を慎重に行ってください。ファイアウォールの構成に誤りがあると、トラフィックが予期せずブロックされる可能性があります。続行する前に、VM シリアル コンソール アクセスの設定を検討してください。
Linux iptables
インストール済みの iptables チェーンとルールごとに処理されるパケットの数をパケット数で確認します。送信元と宛先の IP アドレス / ポートを iptables ルールで指定された接頭辞 / ポートと比較することで、どの DROP ルールが照合されているかを判断します。
マッチしたルールで接続タイムアウトによる破棄が増加していることが示されている場合は、iptables のドキュメントを参照して、正しい allow ルールを適切な接続に適用してください。
$ sudo iptables -L -n -v -x
この INPUT チェーンの例では、任意の IP アドレス間での宛先 TCP ポート 5000 へのパケットがファイアウォールで破棄されていることを示しています。pkts 列は、このルールが 10,342 個のパケットをドロップしたことを示しています。テスト目的で、このルールによって破棄される接続を作成すると、pkts カウンタが増え、動作が確認できます。
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 10342 2078513 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5000
次のコマンドを使用して、iptables に上り（内向き）ルールまたは下り（外向き）ルールを追加できます。
上り（内向き）ルール:
$ sudo iptables -A INPUT -p tcp -s SOURCE_IP_PREFIX --dport SERVER_PORT -j ACCEPT
下り（外向き）ルール:
$ sudo iptables -A OUTPUT -p tcp -d DEST_IP_PREFIX --dport DEST_PORT -j ACCEPT
Windows ファイアウォール
Windows ファイアウォールで、クライアントからの下り（外向き）とサーバーへの上り（内向き）が可能な接続を確認します。ルールによってトラフィックがブロックされている場合は、Windows ファイアウォールで必要な修正を行って接続を許可します。Windows ファイアウォールのロギングを有効にすることもできます。
Windows ファイアウォールのデフォルトの DENY 動作では、拒否されたパケットが通知なく破棄され、タイムアウトになります。
次のコマンドでサーバーを確認します。クライアント VM の下り（外向き）ルールを確認するには、-match 値を Outbound に変更します。
PS C:\> Get-NetFirewallPortFilter | `
>> Where-Object LocalPort -match "PORT" | `
>> Get-NetFirewallRule | `
>> Where-Object {$_.Direction -match "Inbound" -and $_.Profile -match "Any"}
Name : {80D79988-C7A5-4391-902D-382369B4E4A3}
DisplayName : iperf3 udp
Description :
DisplayGroup :
Group :
Enabled : True
Profile : Any
Platform : {}
Direction : Inbound
Action : Allow
EdgeTraversalPolicy : Block
LooseSourceMapping : False
LocalOnlyMapping : False
Owner :
PrimaryStatus : OK
Status : The rule was parsed successfully from the store. (65536)
EnforcementStatus : NotApplicable
PolicyStoreSource : PersistentStore
PolicyStoreSourceType : Local
Windows に新しいファイアウォール ルールを追加するには、次のコマンドを使用します。
下り（外向き）ルール:
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=out action=allow protocol=TCP remoteport=DEST_PORT
上り（内向き）ルール:
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=in action=allow protocol=TCP localport=PORT
サードパーティ ソフトウェア
サードパーティ製のアプリケーション ファイアウォールやウイルス対策ソフトウェアが接続をドロップまたは拒否している可能性があります。詳しくは、ベンダーから提供されたドキュメントをご覧ください。
ファイアウォール ルールに問題があることが判明した場合は、接続を再テストします。ファイアウォール ルールに問題はないと思われる場合は、OS ルーティングの構成を確認するに進みます。
OS のルーティング構成を確認する
オペレーティング システムのルーティングに関する問題が発生した場合、次のいずれかの状況が考えられます。
- ルーティングの問題は、複数のネットワーク インターフェースを持つ VM でよくあるものです。これは、ルーティングが複雑になるためです。
- Google Cloud で VM が 1 つのネットワーク インターフェースで作成された場合は、デフォルト ルーティング テーブルを手動で変更した場合にのみ、ルーティングで問題が発生します。
- オンプレミスから移行された VM では、オンプレミスで必要だった VPC ネットワーク内のルーティングや MTU 設定が引き継がれることがあります。
複数のネットワーク インターフェースを持つ VM を使用している場合は、正しい vNIC とサブネットに下り（外向き）方向のルートを構成する必要があります。たとえば、VM に内部サブネットを宛先とするトラフィックが 1 つの vNIC に送信されるように構成されたルートがある一方、デフォルト ゲートウェイ（宛先 0.0.0.0/0）が、外部 IP アドレスまたは Cloud NAT へのアクセスを持つ別の vNIC に構成されている場合があります。
ルートを 1 つずつ確認するか、VM ルーティング テーブル全体を確認してルートを確認できます。いずれかの方法でルーティング テーブルの問題が見つかった場合は、必要に応じてルーティング テーブルを更新するの手順をご覧ください。
すべてのルートを確認する
すべてのルートを一覧表示して、VM にすでに存在するルートを確認します。
Linux
$ ip route show table all
default via 10.3.0.1 dev ens4 10.3.0.1 dev ens4 scope link local 10.3.0.19 dev ens4 table local proto kernel scope host src 10.3.0.19 broadcast 10.3.0.19 dev ens4 table local proto kernel scope link src 10.3.0.19 broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 ::1 dev lo proto kernel metric 256 pref medium fe80::/64 dev ens4 proto kernel metric 256 pref medium local ::1 dev lo table local proto kernel metric 0 pref medium local fe80::4001:aff:fe03:13 dev ens4 table local proto kernel metric 0 pref medium multicast ff00::/8 dev ens4 table local proto kernel metric 256 pref medium
Windows
PS C:\> Get-NetRoute
ifIndex DestinationPrefix NextHop RouteMetric ifMetric PolicyStore ------- ----------------- ------- ----------- -------- ----------- 4 255.255.255.255/32 0.0.0.0 256 5 ActiveStore 1 255.255.255.255/32 0.0.0.0 256 75 ActiveStore 4 224.0.0.0/4 0.0.0.0 256 5 ActiveStore 1 224.0.0.0/4 0.0.0.0 256 75 ActiveStore 4 169.254.169.254/32 0.0.0.0 1 5 ActiveStore 1 127.255.255.255/32 0.0.0.0 256 75 ActiveStore 1 127.0.0.1/32 0.0.0.0 256 75 ActiveStore 1 127.0.0.0/8 0.0.0.0 256 75 ActiveStore 4 10.3.0.255/32 0.0.0.0 256 5 ActiveStore 4 10.3.0.31/32 0.0.0.0 256 5 ActiveStore 4 10.3.0.1/32 0.0.0.0 1 5 ActiveStore 4 10.3.0.0/24 0.0.0.0 256 5 ActiveStore 4 0.0.0.0/0 10.3.0.1 0 5 ActiveStore 4 ff00::/8 :: 256 5 ActiveStore 1 ff00::/8 :: 256 75 ActiveStore 4 fe80::b991:6a71:ca62:f23f/128 :: 256 5 ActiveStore 4 fe80::/64 :: 256 5 ActiveStore 1 ::1/128 :: 256 75 ActiveStore
個々のルートを確認する
特定の IP 接頭辞に問題があると思われる場合は、クライアント VM とサーバー VM の送信元 IP と宛先 IP に、適切なルートが存在することを確認します。
Linux
$ ip route get DEST_IP
良い結果:
有効なルートが表示されています。この場合、パケットはインターフェース ens4 から下り（外向き）に送信されます。
10.3.0.34 via 10.3.0.1 dev ens4 src 10.3.0.26 uid 1000 cache
悪い結果:
宛先ネットワークへのパスが存在しないため、パケットが破棄されたことを確認できます。ルートテーブルに、正しい下り（外向き）インターフェースのパスが含まれていることを確認します。
**RTNETLINK answers: Network is unreachable
Windows
PS C:\> Find-NetRoute -RemoteIpAddress "DEST_IP"
良い結果:
IPAddress : 192.168.0.2 InterfaceIndex : 4 InterfaceAlias : Ethernet AddressFamily : IPv4 Type : Unicast PrefixLength : 24 PrefixOrigin : Dhcp SuffixOrigin : Dhcp AddressState : Preferred ValidLifetime : 12:53:13 PreferredLifetime : 12:53:13 SkipAsSource : False PolicyStore : ActiveStore Caption : Description : ElementName : InstanceID : ;:8=8:8:9<>55>55:8:8:8:55; AdminDistance : DestinationAddress : IsStatic : RouteMetric : 256 TypeOfRoute : 3 AddressFamily : IPv4 CompartmentId : 1 DestinationPrefix : 192.168.0.0/24 InterfaceAlias : Ethernet InterfaceIndex : 4 InterfaceMetric : 5 NextHop : 0.0.0.0 PreferredLifetime : 10675199.02:48:05.4775807 Protocol : Local Publish : No State : Alive Store : ActiveStore ValidLifetime : 10675199.02:48:05.4775807 PSComputerName : ifIndex : 4
悪い結果:
Find-NetRoute : The network location cannot be reached. For information about network troubleshooting, see Windows Help.
At line:1 char:1
+ Find-NetRoute -RemoteIpAddress "192.168.0.4"
+ ----------------------------------------
+ CategoryInfo : NotSpecified: (MSFT_NetRoute:ROOT/StandardCimv2/MSFT_NetRoute) [Find-NetRoute], CimException
+ FullyQualifiedErrorId : Windows System Error 1231,Find-NetRoute
宛先 IP アドレスへの経路がないため、パケットが破棄されています。デフォルト ゲートウェイがあり、ゲートウェイが正しい vNIC とネットワークに適用されていることを確認します。
ルーティング テーブルを更新する
必要に応じて、オペレーティング システムのルートテーブルにルートを追加できます。ルーティング VM のルーティング テーブルを更新するコマンドを実行する前に、コマンドをよく理解し、考えられる影響を理解しておくことをおすすめします。ルート更新コマンドを不用意に使用すると、予期しない問題や VM との切断が発生する可能性があります。続行する前に、VM シリアル コンソール アクセスの設定を検討してください。
ルートを更新する手順については、オペレーティング システムのドキュメントをご覧ください。
ルートに問題があることが判明した場合は、接続を再テストしてください。ルートに問題がないと思われる場合は、インターフェース MTU の確認に進みます。
MTU を確認する
VM のインターフェース MTU は、接続先の VPC ネットワークの MTU と一致する必要があります。相互に通信を行う VM に同じ MTU が設定されているのが理想的です。通常、MTU の不一致は TCP の問題ではありませんが、UDP で問題が発生することがあります。
VPC の MTU を確認します。VM が 2 つの異なるネットワークに存在する場合は、両方のネットワークを確認します。
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
クライアントとサーバーのネットワーク インターフェースの MTU 構成を確認します。
Linux
$ netstat -i
lo（ループバック）インターフェースの MTU は常に 65536 です。このステップでは無視できます。
Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg ens4 1460 8720854 0 0 0 18270406 0 0 0 BMRU lo 65536 53 0 0 0 53 0 0 0 LRU
Windows
PS C:\> Get-NetIpInterface
ループバック擬似インターフェースの MTU は常に 4294967295 です。この手順では無視してかまいません。
ifIndex InterfaceAlias Address NlMtu(Bytes) Interface Dhcp Connection PolicyStore
Family Metric State
------- -------------- ------- ------------ --------- ---- ---------- -----------
4 Ethernet IPv6 1500 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
4 Ethernet IPv4 1460 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected Active
インターフェースと MTU が一致しない場合、インターフェース MTU を再構成できます。詳しくは、VM と MTU の設定をご覧ください。これらが一致し、ここまでのトラブルシューティングの手順を実施している場合は、サーバー自体に問題がある可能性があります。サーバーの問題のトラブルシューティングについては、サーバー ロギングでサーバーの動作情報を確認するに進みます。
サーバー ロギングでサーバーの動作情報を確認する
上記の手順で問題が解決しない場合、アプリケーションがタイムアウトしている可能性があります。サーバーとアプリケーションのログで、発生している内容を説明する動作を確認します。
確認するログソース:
- VM 用 Cloud Logging
- VM シリアルログ
- Linux Syslog と kern.log、または Windows イベント ビューア
それでも問題が解決しない場合
それでも問題が解決しない場合は、サポートの利用をご覧ください。前のトラブルシューティングの結果を他のメンバーと共有しておくと便利です。
スループット低下の原因となるネットワーク レイテンシや損失のトラブルシューティング
ネットワーク レイテンシや損失の問題は通常、VM またはネットワーク パス内のリソースの枯渇またはボトルネックが原因で発生します。ネットワーク損失が原因で、断続的な接続タイムアウトが発生することがあります。vCPU の過剰な使用や vNIC の飽和などが原因でレイテンシとパケットロスが増加すると、ネットワークのパフォーマンスが低下する可能性があります。
以下の手順では、接続がタイムアウトにならないこと、容量またはパフォーマンスが制限されることを前提としています。完全なパケットロスが発生している場合は、完全な接続エラーのトラブルシューティングをご覧ください。
レイテンシが数ミリ秒変動するなど、わずかなレイテンシの変化は正常です。レイテンシは、ネットワークの負荷または VM 内のキューイングによって変わります。
接続値を決定する
まず、次の情報を収集します。
- [VM インスタンス] ページで、両方の VM について次の情報を収集します。
- VM 名
- VM ゾーン
- 通信している vNIC の内部 IP アドレス
- 宛先のサーバー ソフトウェアの構成で、次の情報を収集します。
- レイヤ 4 プロトコル
- 宛先ポート
複数の VM で問題が発生した場合は、問題が発生している単一の VM と宛先の VM を選択し、それらの値を使用します。一般に、接続の送信元ポートは必要ありません。
これらの情報を取得したら、基盤となる Google ネットワークの問題を調査するに進みます。
基盤となる Google ネットワークの問題を調査する
最近変更された設定がある場合は、基盤となる Google ネットワークに問題がある可能性があります。Network Intelligence Center のパフォーマンス ダッシュボードで、VM ゾーン間のパケットロスを確認します。ネットワーク タイムアウトの期間中にゾーン間のパケットロスが増加した場合は、仮想ネットワークの基盤となる物理ネットワークに問題がある可能性があります。サポートケースを送信する前に、Google Cloud ステータス ダッシュボードで既知の問題を確認してください。
Google ネットワークに問題がないと思われる場合は、handshake レイテンシを確認するに進みます。
handshake レイテンシを確認する
接続ベースのどのプロトコルでも、接続設定の handshake を行う間に一定のレイテンシが発生します。プロトコルの handshake ごとにオーバーヘッドが発生します。たとえば、SSL / TLS 接続の場合、SSL handshake を開始する前に TCP handshake を完了し、データが送信される前に TLS handshake を完了する必要があります。
通常、同じ Google Cloud ゾーンでの handshake レイテンシは無視できる程度ですが、グローバルに離れた場所で handshake が行われると、接続開始時の遅延が増加する可能性があります。リソースが距離の離れたリージョンにある場合は、発生しているレイテンシがプロトコル handshake に起因するものかどうか確認できます。
Linux と Windows 2019
$ curl -o /dev/null -Lvs -w 'tcp_handshake: %{time_connect}s, application_handshake: %{time_appconnect}s' DEST_IP:PORT
tcp_handshake: 0.035489s, application_handshake: 0.051321s
- tcp_handshake は、クライアントが最初の SYN パケットを送信してから TCP handshake の ACK を送信するまでの時間です。
- application_handshake は、TCP handshake の最初の SYN パケットから TLS（通常は）handshake 完了までの時間です。
- 追加の handshake 時間 = application_handshake - tcp_handshake
Windows 2012 と 2016
デフォルトの OS ツールでは利用できません。ファイアウォール ルールで許可されていれば、参考として ICMP ラウンドトリップ時間を使用できます。
レイテンシが handshake による遅延よりも大きい場合は、VM タイプの最大スループットを決定するに進みます。
VM タイプの最大スループットを決定する
VM の下り（外向き）スループットは、VM CPU アーキテクチャと vCPU 数によって制限されます。ネットワーク帯域幅のページを参照して、VM の潜在的な下り（外向き）帯域幅を特定します。
VM が下り（外向き）要件を満たすことができない場合は、容量の大きな VM へのアップグレードを検討してください。手順については、インスタンスのマシンタイプの変更をご覧ください。
マシンタイプで十分な下り（外向き）帯域幅が許可されている場合は、永続ディスクの使用量が下り（外向き）ネットワークに影響しているかどうかを調べます。永続ディスクのオペレーションに許容されるのは、VM のネットワーク スループットの合計の 60% までです。永続ディスクのオペレーションによってネットワーク スループットが低下しているかどうかを確認するには、永続ディスクのパフォーマンスを確認するをご覧ください。
VM へのネットワーク上り（内向き）は、VPC ネットワークまたは VM インスタンス タイプによって制限されません。代わりに、パケット キューイングによる影響と、VM のオペレーティング システムまたはアプリケーションの処理パフォーマンスの影響を受けます。下り（外向き）帯域幅が十分であるにもかかわらず、上り（内向き）で問題が発生している場合は、サーバー ロギングでサーバーの動作を確認するをご覧ください。
インターフェース MTU を確認する
VPC ネットワークの MTU は構成可能です。VM 上のインターフェース MTU は、接続先の VPC ネットワークの MTU 値と一致する必要があります。VPC ネットワーク ピアリングでは、異なるネットワークの VM に別の MTU が設定されていることがあります。この状況が発生している場合は、小さいほうの MTU 値を関連するインターフェースに適用します。通常、MTU の不一致は TCP の問題ではありませんが、UDP で問題が発生することがあります。
VPC の MTU を確認します。VM が 2 つの異なるネットワークに存在する場合は、両方のネットワークを確認します。
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
ネットワーク インターフェースの MTU 構成を確認します。
Linux
lo（ループバック）インターフェースの MTU は常に 65536 です。このステップでは無視できます。
$ netstat -i
Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg ens4 1460 8720854 0 0 0 18270406 0 0 0 BMRU lo 65536 53 0 0 0 53 0 0 0 LRU
Windows
PS C:\> Get-NetIpInterface
ループバック擬似インターフェースの MTU は常に 4294967295 です。この手順では無視してかまいません。
ifIndex InterfaceAlias Address NlMtu(Bytes) Interface Dhcp Connection PolicyStore
Family Metric State
------- -------------- ------- ------------ --------- ---- ---------- -----------
4 Ethernet IPv6 1500 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
4 Ethernet IPv4 1460 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected Active
インターフェースと MTU が一致しない場合、インターフェース MTU を再構成できます。Windows VM の MTU の更新手順については、VM と MTU の設定をご覧ください。一致している場合は、サーバーの可用性に問題がある可能性があります。次のステップでは、ログを参照して VM の再起動、停止、ライブ マイグレーションを確認し、該当する時間内に VM に何が発生したのかを確認します。
ログを参照して VM の再起動、停止、ライブ マイグレーションを確認する
VM のライフサイクル中に、ユーザーが VM を再起動することがあります。また、Google Cloud のメンテナンスでライブ マイグレーションが行われることもあります。まれですが、VM を含む物理ホストで障害が発生し、VM が失われたり、再作成されることもあります。これらのイベントにより、レイテンシや接続タイムアウトが増加する可能性があります。このようなイベントが VM で発生すると、ログに記録されます。
VM のログを表示する方法は次のとおりです。
Google Cloud コンソールで [ロギング] ページに移動します。
レイテンシが発生した期間を選択します。
次の Logging クエリを使用して、レイテンシが発生した期間の前後に VM イベントが発生したかどうかを確認します。
resource.labels.instance_id:"INSTANCE_NAME" resource.type="gce_instance" ( protoPayload.methodName:"compute.instances.hostError" OR protoPayload.methodName:"compute.instances.OnHostMaintenance" OR protoPayload.methodName:"compute.instances.migrateOnHostMaintenance" OR protoPayload.methodName:"compute.instances.terminateOnHostMaintenance" OR protoPayload.methodName:"compute.instances.stop" OR protoPayload.methodName:"compute.instances.reset" OR protoPayload.methodName:"compute.instances.automaticRestart" OR protoPayload.methodName:"compute.instances.guestTerminate" OR protoPayload.methodName:"compute.instances.instanceManagerHaltForRestart" OR protoPayload.methodName:"compute.instances.preempted" )
関連する時間内に VM の再起動または移行が発生していない場合は、リソースが枯渇している可能性があります。これを確認するには、ネットワークと OS の統計情報でリソース枯渇によるパケットの破棄を確認するに進みます。
ネットワークと OS の統計情報でリソース枯渇によるパケットの破棄を確認する
一般に、リソースの枯渇は、下り（外向き）帯域幅など、VM 上のリソースに対して許容範囲を超えたリクエストが行われていることを意味します。リソースが枯渇すると、パケットが定期的に破棄され、接続レイテンシやタイムアウトが発生します。こうしたタイムアウトがクライアントやサーバーの起動時に発生することはまれですが、システムによるリソース使用量の増加に伴い、発生する可能性があります。
以下に、パケット カウンタと統計情報を表示するコマンドのリストを示します。一部のコマンドでは、他のコマンドの結果が重複して返されることがあります。このような場合は、より適切なコマンドを使用できます。コマンドの実行で意図される結果の詳細については、各セクションの注意事項をご覧ください。異なるタイミングでコマンドを実行すると、問題だけでなく、破棄やエラーが発生しているかどうかも確認できます。
Linux
ネットワークの統計情報を表示するには、
netstatコマンドを使用します。$ netstat -sTcpExt: 341976 packets pruned from receive queue because of socket buffer overrun 6 ICMP packets dropped because they were out-of-window 45675 TCP sockets finished time wait in fast timer 3380 packets rejected in established connections because of timestamp 50065 delayed acks sent
netstat コマンドは、破棄されたパケットの値を含むネットワーク統計情報をプロトコル別に出力します。アプリケーションまたはネットワーク インターフェースによるリソースの枯渇がパケットの破棄につながる可能性があります。カウンタが増加している理由を確認します。
kern.log で、
nf_conntrack: table full, dropping packetに一致するログを確認します。Debian:
cat /var/log/kern.log | grep "dropping packet"CentOS:
sudo cat /var/log/dmesg | grep "dropping packet"このログは、VM の接続トラッキング テーブルが追跡可能な最大接続数に達したことを示します。この VM との接続がタイムアウトする可能性があります。conntrack が有効になっている場合、最大接続数は
sudo sysctl net.netfilter.nf_conntrack_maxで確認できます。最大数のトラッキングを追跡するには、sysctl
net.netfilter.nf_conntrack_maxを変更するか、VM ワークロードを複数の VM に分散して負荷を軽減します。
Windows UI
Perfmon
- Windows メニューで「perfmon」を検索してプログラムを開きます。
- 左側のメニューで、[Performance] > [Monitoring Tools] > [Performance Monitor] を選択します。
- メインビューで緑色のプラス「+」をクリックして、モニタリング グラフにパフォーマンス カウンタを追加します。次のカウンタが重要です。
- ネットワーク アダプタ
- 出力キューの長さ
- 破棄されたアウトバウンド パケット
- パケット送信エラー
- 破棄された受信パケット
- パケット受信エラー
- 受信された不明パケット
- ネットワーク インターフェース
- 出力キューの長さ
- 破棄されたアウトバウンド パケット
- パケット送信エラー
- 破棄された受信パケット
- パケット受信エラー
- 受信された不明パケット
- プロセッサごとのネットワーク インターフェース カードのアクティビティ
- ローリソース受信表示/秒
- ローリソース受信パケット/秒
- プロセッサ
- 割り込み時間（%）
- 特権時間（%）
- プロセッサ時間（%）
- ユーザー時間（%）
- ネットワーク アダプタ
Pefmon を使用すると、上記のカウンタを時系列グラフで表示できます。これは、テストが行われているときや、サーバーに問題があるときに監視するのに便利です。割り込み時間や特権時間など、CPU 関連のカウンタが急増している場合は、VM が CPU スループットの上限に達し、飽和状態になっている可能性があります。CPU が飽和状態になると、パケットの破棄やエラーが発生する可能性があります。その場合、クライアントまたはサーバーのソケットで処理される前に、パケットが失われます。また、CPU が飽和状態になると、出力キューの長さも増加します。これは、処理するパケットがキューに格納される回数が増えるためです。
Windows Powershell
PS C:\> netstat -s
IPv4 Statistics Packets Received = 56183 Received Header Errors = 0 Received Address Errors = 0 Datagrams Forwarded = 0 Unknown Protocols Received = 0 Received Packets Discarded = 25 Received Packets Delivered = 56297 Output Requests = 47994 Routing Discards = 0 Discarded Output Packets = 0 Output Packet No Route = 0 Reassembly Required = 0 Reassembly Successful = 0 Reassembly Failures = 0 Datagrams Successfully Fragmented = 0 Datagrams Failing Fragmentation = 0 Fragments Created = 0
netstat コマンドは、破棄されたパケットの値を含むネットワーク統計情報をプロトコル別に出力します。アプリケーションまたはネットワーク インターフェースによるリソースの枯渇がパケットの破棄につながる可能性があります。
リソースが枯渇している場合は、より多くのインスタンスにワークロードを分散する、より多くのリソースを備えた VM にアップグレードする、特定のパフォーマンスニーズに合わせて OS またはアプリケーションを調整する、検索エンジンにエラー メッセージを入力して解決策を探す、などの対策を行います。また、それでも問題が解決しない場合で説明されている方法でサポートを利用することもできます。
リソースの枯渇が問題でないと思われる場合は、サーバー ソフトウェア自体に問題がある可能性があります。サーバー ソフトウェアの問題のトラブルシューティングについては、サーバー ロギングでサーバーの動作情報を確認するに進みます。
サーバー ロギングでサーバーの動作情報を確認する
上記の手順で問題が解決しない場合は、vCPU の過剰な負荷により処理が停止しているなど、アプリケーションの動作が原因でタイムアウトが発生している可能性があります。サーバーログとアプリケーション ログで、発生している動作を確認します。
たとえば、負荷の高いデータベースなど、アップストリーム システムが原因でサーバーのレイテンシが増加している場合、過剰な量のリクエストがキューに格納され、メモリ使用量と CPU 待機時間が増大する可能性があります。これらの要因により、接続が失敗するか、ソケット バッファがオーバーランする可能性があります。
TCP 接続では、時折パケットが失われますが、通常は、選択的な確認応答とパケットの再送信により、失われたパケットが回復し、接続タイムアウトが回避されます。アプリケーション サーバーの障害や再デプロイでタイムアウトが発生する場合は、一時的な接続エラーが発生する可能性があります。
サーバー アプリケーションがデータベースやその他のサービスへの接続に依存している場合は、連携しているサービスのパフォーマンスが低下していないことを確認します。これらの指標は、アプリケーションで追跡できる場合があります。
それでも問題が解決しない場合
それでも問題が解決しない場合は、サポートの利用をご覧ください。トラブルシューティングの出力を、他のメンバーと共有しておくと便利です。
次のステップ
- それでも問題が解決しない場合は、リソースページをご覧ください。