Oracle Cloud Infrastructureドキュメント

ハンギング接続

このトピックでは、クラウド・ネットワークとオンプレミス・ネットワーク間の通信で発生する最も一般的な問題の1つについて説明: 接続を介してホストにpingを送信することができます。

問題と解決策の要約

症状: 仮想クラウド・ネットワーク(VCN)は、IPSec VPNまたはOracle Cloud Infrastructure FastConnectを介して既存のオンプレミス・ネットワークに接続します。 接続の片側のホストは、相手側のホストにpingを実行できますが、接続はハングします。 例えば:

  • 接続を介してホストにSSH接続できますが、ホストにログインすると接続がハングアップします。
  • Virtual Networking Computing (VNC)接続を開始できますが、セッションがハングします。
  • SFTPダウンロードを開始することはできますが、ダウンロードはハングアップします。

一般的な問題: パス最大伝送ユニット発見(PMTUD)は、接続の一方または両方の側で動作していない可能性があります。 両方の側が接続には大きすぎるパケットを送信しようとしているかどうかを知ることができるように、接続の両側で作業している必要があります。 Maximum Transmission Unit (MTU)とPMTUDの概要については、「MTUの概要」「PMTUDの概要」を参照してください。

PMTUDを固定するための解決策:

  1. ホストがPMTUDを使用するように構成されていることを確認します: オンプレミス・ネットワーク内のホストがPMTUDを使用しない場合(つまり、パケットにDon't Fragmentフラグが設定されていない場合)、接続には大きすぎるパケットを送信しているかどうかを検出できません。 接続のOracle側のインスタンスは、デフォルトでPMTUDを使用します。 インスタンスの構成を変更しないでください。
  2. VCNセキュリティ・リストとインスタンス・ファイアウォールの両方でICMPタイプ3コード4メッセージが許可されていることを確認します: PMTUDが使用されている場合、送信ホストは、接続には大きすぎるパケットを送信すると、特別なICMPメッセージを受信します。 メッセージを受信すると、ホストは、接続に適合するようにパケットのサイズを動的に更新することができます。 ただし、VCN内のサブネットまたはインスタンス・ファイアウォールのセキュリティ・リストがそれらを受け入れるように構成されていない場合、インスタンスはこれらの重要なICMPメッセージを受信できません。

    ヒント

    「ステートフル・セキュリティ・リストのルール」 (TCP、UDP、またはICMPトラフィック用)を使用している場合は、セキュリティ・リストにICMPタイプ3コード4メッセージを許可するルールがあることを確認する必要はありません。
    ステートフル・ルールを使用すると、ネットワーキング・サービスは接続を追跡し、明示的なルールを必要とせずに、対応するICMPタイプ3コード4メッセージを自動的に許可します。 ステートレス・ルールを使用している場合のみ、ICMPタイプ3コード4メッセージ用の明示的なイングレス・セキュリティ・リスト・ルールが必要です。 また、インスタンス・ファイアウォールが正しく設定されていることを確認する必要があります。

    ホストがメッセージを受信しているかどうかを確認するには、「PMTUDが壊れている場所を探す」を参照してください。

  3. ルーターがDon't Fragmentフラグを守っていることを確認してください: ルーターがフラグを守らずにPMTUDの使用を無視すると、フラグメント化されたパケットがVCNのインスタンスに送信されます。これは悪いです(なぜフラグメンテーションを避けるのか?を参照)。 VCNセキュリティ・リストは、最初のフラグメントのみを認識し、残りのフラグメントは破棄され、接続がハングアップするように構成されている可能性があります。 代わりに、ルーターはPMTUDを使用し、Don't Fragmentフラグを守って、接続を介して送信されるフラグメント化されていないパケットの正しいサイズを判断する必要があります。

次の図では、ソリューションの部分に番号が付けられ、赤の斜体で呼び出されます。 オンプレミス・ネットワークがIPSec VPN経由でVCNに接続されているシナリオの例を示しています。

このイメージは、ハンギング接続を固定するためのソリューションのさまざまな部分を示しています

MTUとPMTUD、ネットワーク接続の両側にある「PMTUDが動作しているかどうかを確認する方法」の概要をお読みください。

なぜフラグメンテーションを避けるのか?

なぜフラグメンテーションを避けたいのだろうかと疑問に思うかもしれません。 まず、アプリケーションのパフォーマンスに悪影響を与えます。 フラグメンテーションは、フラグメントの再アセンブリと、フラグメントが失われた場合再送信が必要です。 再アセンブリと再送信には、時間とCPUリソースが必要です。

第2に、最初のフラグメントだけがソースおよび宛先ポート情報を含みます。 これは、通常、ポート情報を評価するように構成されているファイアウォールやVCN 「セキュリティ・リスト」によって他のパケットが破棄される可能性があることを意味します。 ファイアウォールとセキュリティ・リストでフラグメンテーションを処理するには、通常よりも許容性が高くなるように構成する必要がありますが、これは望ましくありません。

MTUの概要

インターネット・プロトコル(IP)ネットワーク上の任意の2つのホスト間の通信は、パケットを使用します。 各パケットには、送信元と宛先のIPアドレスとペイロードのデータがあります。 2つのホスト間のすべてのネットワーク・セグメントには、単一のパケットが伝送できるバイト数を表す「最大伝送ユニット(MTU)」があります。

インターネット上では、MTUは1500バイトです。 これは、ほとんどのホーム・ネットワークと多くの企業ネットワーク(およびそのWi-Fiネットワーク)にも当てはまります。 Oracle Cloud Infrastructureのデータセンターを含む一部のデータセンターには、より大きなMTUがあります。 コンピュート・インスタンスはデフォルトでMTUが9000です。 Linuxホストでは、ifconfigコマンドを使用して、ホスト・ネットワーク接続のMTUを表示できます。 たとえば、Ubuntuインスタンスからのifconfig出力を次に示します(MTUは赤い斜体で強調表示されています):

ifconfig
ens3 Link encap:Ethernet HWaddr 00:00:17:01:17:83
inet addr:10.0.6.9 Bcast:10.0.6.31 Mask:255.255.255.224
inet6 addr: fe80::200:17ff:fe01:1783/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1

比較のために、企業ネットワークに接続されたマシンからの出力を以下に示します:

ifconfig
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST>
mtu 1500

そのMTUがより一般的な1500バイトであることに注目してください。

ホストが企業のVPN経由で接続されている場合、VPNトンネルはIPSecパケット内のトラフィックをカプセル化してローカル・ネットワークを介して送信する必要があるため、MTUはさらに小さくなります。 例えば:

ifconfig
utun0: flags=81d1<UP,POINTOPOINT,RUNNING,NOARP,PROMISC,MULTICAST>
mtu 1300

2人のホストは、どのくらいの大きさのパケットを互いに送ることができるのでしょうか? HTTP、SSH、FTPなどの多くのタイプのネットワーク・トラフィックでは、ホストはTCP (Transmission Control Protocol)を使用して新しい接続を確立します。 2つのホスト間の最初の3者間のハンドシェイクの間、それぞれのペイロードがどれくらいの大きさであるかについて「最大セグメント・サイズ(MSS)」を送信します。 これはMTUよりも小さい。 (TCPはインターネット・プロトコル(IP)内で実行されるため、TCP/IPと呼ばれています)。 セグメントはTCPにどのパケットをIPに送るかです。)

tcpdumpアプリケーションを使用すると、ハンドシェイク中に共有されたMSS値を確認できます。 次に、tcpdumpの例を示します(MSSは赤い斜体で強調表示されています):

12:11:58.846890 IP 129.146.27.25.22 > 10.197.176.19.58824: Flags [S.], seq
2799552952, ack 2580095593, win 26844, options [mss 1260,sackOK,TS val
44858491 ecr 1321638674,nop,wscale 7], length 0

前のパケットは、SSH接続から企業のVPNに接続されたラップトップのインスタンスへのパケットです。 ラップトップがインターネット接続に使用するローカル・ネットワークのMTUは1500バイトです。 VPNトンネルは1300バイトのMTUを強制します。 その後、SSH接続が試行されると、TCP (IP接続内で実行中)は、1260バイト以下のTCPセグメントをサポートすることをOracle Cloud Infrastructureインスタンスに通知します。 企業のVPN接続では、VPNに接続されたラップトップは、通常、インターネットを介して通信しているものと比較して、MTUとMSSが最小です。

より複雑なケースは、2つのホストがそれらの間のいくつかのネットワーク・リンクより大きなMTUを持つ場合です。 次の図は、例を示しています。

このイメージは、ネットワーク接続全体のさまざまなポイントで異なるMTUレベルを示しています

この例では、2台のサーバーがあり、それぞれが9000バイトのMTUをサポートする独自のルー・テッド・ネットワークに直接接続されています。 サーバーは異なるデータセンターにあります。 各データセンターは1500バイトのMTUをサポートするインターネットに接続されています。 2つのデータセンターの間にIPSec VPNトンネルがあります。 そのトンネルはインターネットを横切っているので、トンネルの内部はインターネットよりも小さなMTUを持っています。 この図では、MTUは1380バイトです。

2つのサーバーが3ウェイ・ハンドシェーク中に(SSHなどで)通信しようとすると、約8960のMSSに同意します。 最初のSSH接続は正常に終了する可能性があります。これは、最初のSSH接続設定時の最大パケット・サイズが通常1380バイト未満であるためです。 片側が2つのエンドポイント間の最小リンクより大きなパケットを送信しようとすると、Path MTU Discovery (PMTUD)が重要になります。

PMTUDの概要

Path MTU DiscoveryはRFC 1191で定義されています。 これは、2つの通信するホストに、それぞれ送信するパケットに「Don't Fragment」フラグを設定するよう要求することによって機能します。 これらのホストの1つからのパケットが、エグレス(またはアウトバウンド)インタフェースのパケット長より小さいMTUを持つルーターに到達すると、ルーターはそのパケットを廃棄します。 ルーターはまた、ICMPタイプ3コード4メッセージをホストに返す。 このメッセージには、"Destination Unreachable, Fragmentation Needed and Don't Fragment Was Set"と表示されます (RFC 792で定義されています)。 効果的にルーターはホストに通知: "大きすぎるパケットや大きすぎるパケットをフラグメントしないようにと教えてくれました。 送信していません。" ルーターはまた、そのエグレス・インタフェースを通して許容される最大サイズのパケットをホストに伝えます。 アウトバウンド側ホストは、アウトバウンド・パケットのサイズを調整して、ルーターがメッセージ内で指定した値より小さくなるようにします。

インスタンスが8000バイトのパケットとDon't Fragmentフラグが設定された(つまり、PMTUDが使用されている)インターネット上でホスト(8.8.8.8)にpingを実行しようとしたときの結果を示す例です。 返されたICMPメッセージは、赤い斜体で強調表示されます:

ping 8.8.8.8 -M do -s 8000
PING 8.8.8.8 (8.8.8.8) 8000(8028) bytes of data.
From 4.16.139.250 icmp_seq=1 Frag needed and DF set (mtu = 1500)

レスポンスはまさに期待されるものです。 宛先ホストはインターネット上にあり、MTUは1500バイトです。 送信ホスト・ローカル・ネットワーク接続のMTUが9000バイトであっても、ホストは8000バイト・パケットの宛先ホストに到達できず、それに応じてICMPメッセージを取得します。 PMTUDが正しく機能しています。

比較のため、同じpingがありますが、宛先ホストはIPSec VPNトンネルを経由しています:

ping 192.168.6.130 -M do -s 8000
PING 192.168.6.130 (192.168.6.130) 8000(8028) bytes of data.
From 129.146.13.49 icmp_seq=1 Frag needed and DF set 

ここで、VPNルーターは、このパケットを宛先にアウトバウンドすることを認識します。アウトバウンド・インタフェースは、VPNトンネルです。 そのトンネルはインターネットを横断するので、トンネルはインターネットの1500バイトのMTUリンクに収まる必要があります。 その結果、トンネル内部では1360バイトまでのパケットしか許可されません(ルーターは1358に下がり、混乱を招く可能性があります)。

PMTUDが壊れている場所を探す

PMTUDが接続のどこかで動作していない場合は、理由と場所を把握する必要があります。 通常は、ICMPタイプ3コード4パケット(パケットに収まらない制約付きリンクを持つルーターから)が送信ホストに戻ってこないためです。 これは、ホストとルーターの間でこの種のトラフィックをブロックするものがある場合に発生します。 また、VPNトンネル(または他の拘束されたMTUリンク)のいずれかの側で発生する可能性があります。

接続の各側からpingを試してみてください

壊れたPMTUDのトラブルシューティングを行うには、接続の各側でPMTUDが動作しているかどうかを判断する必要があります。 このシナリオでは、接続がIPSec VPNであると仮定します。

pingの方法: PMTUDの概要の場合と同様に、接続の反対側のホストに対して、VPNトンネル(たとえば、1500バイト以上)に収まらないほど大きいパケットでpingを実行します。 送信ホストが使用するオペレーティング・システムに応じて、Don't Fragmentフラグが設定されていることを確認するために、pingコマンドを少しずつフォーマットする必要があります。 UbuntuとOracle Linuxの両方で、pingコマンドで-Mフラグを使用します。

-Mフラグの情報は次のとおりです:

-M pmtudisc_opt
Select Path MTU Discovery strategy. pmtudisc_option may be either do
(prohibit fragmentation, even local one), want (do PMTU discovery, fragment
locally when packet size is large), or dont (do not set DF flag).

次に、pingの例を示します( -Mフラグと結果のICMPメッセージが赤の斜体で強調表示されています)

ping -M do -s 1500 192.168.6.130
PING 192.168.6.130 (192.168.6.130) 1500(1528) bytes of data.
From 129.146.13.49 icmp_seq=1 Frag needed and DF set (mtu = 1358)
良い: PMTUDが働いています
悪い: 接続の側をテストしており、pingが成功した場合
悪い: 接続のVCN側をテストしていて、ICMPメッセージが表示されない場合

PMTUDの必要性を避ける

PMTUDを使用することをお薦めします。 ただし、状況によっては、サーバーに依存する必要がないようにサーバーを構成することも可能です。 オンプレミス・ネットワーク内のホストにIPSec VPN経由で通信するVCNのインスタンスのケースを考えてみましょう。 オンプレミス・ネットワークのIPアドレスの範囲を知っています。 そのアドレス範囲のホストと通信するときに使用する最大MTUを指定する特別なルートをインスタンスに追加できます。 VCN内のインスタンスからインスタンスへの通信でも、9000バイトのMTUが使用されます。

次の情報は、Linuxインスタンスでそのルートを設定する方法を示しています。

インスタンスのデフォルト・ルート表には、通常、2つのルートがあります: デフォルト・ルート(デフォルト・ゲートウェイ用)、およびローカル・ルート(ローカル・サブネット用)を指定します。 例えば:

ip route show
default via 10.0.6.1 dev ens3
10.0.6.0/27 dev ens3  proto kernel  scope link  src 10.0.6.9

同じデフォルト・ゲートウェイを指し示すが、オンプレミス・ネットワークのアドレス範囲とより小さいMTUを指す別のルートを追加できます。 たとえば、オンプレミス・ネットワークに送信されるパケットの場合、オンプレミス・ネットワークは1.0.0.0/8、デフォルト・ゲートウェイは10.0.6.1、最大MTUサイズは1300です。

ip route add 1.0.0.0/8 via 10.0.6.1 mtu 1300

更新されたルート表は次のようになります:

ip route show
default via 10.0.6.1 dev ens3
1.0.0.0/8 via 10.0.6.1 dev ens3  mtu 1300
10.0.6.0/27 dev ens3  proto kernel  scope link  src 10.0.6.9

VCN内では、インスタンスとインスタンス間の通信は引き続き9000 MTUを使用します。 ただし、オンプレミス・ネットワークとの通信では最大1300を使用します。 この例では、オンプレミス・ネットワークと、1300より小さいMTUを使用するVCNの間に接続の部分がないことを前提としています。

重要

前述のコマンドは、インスタンスを再起動しても保持されません。
これをOSの構成ファイルに追加することで、ルートを恒久的にすることができます。 たとえば、Oracle Linuxの場合、/etc/sysconfig/network-scripts/route-<interface>というインタフェース固有のファイルです。 詳細については、使用しているLinuxのマニュアルを参照してください。