Red Hat Training

A Red Hat training course is available for RHEL 8

26.3.11. IPsec VPN 設定のトラブルシューティング

IPsec VPN 設定に関連する問題は、主にいくつかの主な理由で発生します。このような問題が発生した場合は、問題の原因が以下のシナリオのいずれかに対応しているかどうかを確認して、対応するソリューションを適用します。

基本的な接続のトラブルシューティング

新規デプロイメントで VPN 接続に関連する問題の多くは、管理者がエンドポイントを一致しない設定オプションで設定している新規デプロイメントで問題が発生します。また、新たに導入された互換性のない値が原因で、作業の設定が機能しなくなることがあります。これは、管理者が設定を変更した結果になります。管理者が、特定のオプション(暗号化アルゴリズムなど)に、ファームウェア更新をインストールするか、特定のオプションに異なるデフォルト値でパッケージ更新がインストールされている可能性があります。

IPsec VPN 接続が確立されていることを確認するには、次のコマンドを実行します。

# ipsec trafficstatus
006 #8: "vpn.example.com"[1] 192.0.2.1, type=ESP, add_time=1595296930, inBytes=5999, outBytes=3231, id='@vpn.example.com', lease=100.64.13.5/32

出力が空であるか、または接続名を持つエントリーが表示されない場合は、トンネルが破損します。

接続に問題があることを確認するには、以下を実行します。

  1. vpn.example.com 接続を再読み込みします。

    # ipsec auto --add vpn.example.com
    002 added connection description "vpn.example.com"
  2. 次に、VPN 接続を開始します。

    # ipsec auto --up vpn.example.com

ファイアウォール関連の問題

最も一般的な問題は、IPsec エンドポイントの 1 つ、またはエンドポイント間のルーター上のファイアウォールがすべての Internet Key Exchange(IKE)パケットを破棄することです。

  • IKEv2 の場合、以下の例のような出力は、ファイアウォールの問題を示しています。

    # ipsec auto --up vpn.example.com
    181 "vpn.example.com"[1] 192.0.2.2 #15: initiating IKEv2 IKE SA
    181 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: sent v2I1, expected v2R1
    010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 0.5 seconds for response
    010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 1 seconds for response
    010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 2 seconds for
    ...
  • IKEv1 の場合は、開始しているコマンドの出力は以下のようになります。

    # ipsec auto --up vpn.example.com
    002 "vpn.example.com" #9: initiating Main Mode
    102 "vpn.example.com" #9: STATE_MAIN_I1: sent MI1, expecting MR1
    010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 0.5 seconds for response
    010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 1 seconds for response
    010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 2 seconds for response
    ...

IPsec の設定に使用される IKE プロトコルは暗号化されているため、tcpdump ツールを使用しての問題のサブセットのみのトラブルシューティングを行うことができます。ファイアウォールが IKE パケットまたは IPsec パケットを破棄している場合は、tcpdump ユーティリティーを使用して原因を見つけることができます。ただし、tcpdump は IPsec VPN 接続に関する他の問題を診断できません。

  • eth0 インターフェースで VPN およびすべての暗号化されたデータのネゴシエーションを取得するには、次のコマンドを実行 します。

    # tcpdump -i eth0 -n -n esp or udp port 500 or udp port 4500 or tcp port 4500

    不一致のアルゴリズム、プロトコル、およびポリシー

    VPN 接続では、エンドポイントが IKE アルゴリズム、IPsec アルゴリズム、および IP アドレス範囲に一致する必要があります。不一致が発生した場合、接続は失敗します。以下の方法のいずれかを使用して不一致を特定した場合は、アルゴリズム、プロトコル、またはポリシーを調整して修正します。

  • リモートエンドポイントが IKE/IPsec を実行していない場合は、そのパケットを示す ICMP パケットが表示されます。以下に例を示します。

    # ipsec auto --up vpn.example.com
    ...
    000 "vpn.example.com"[1] 192.0.2.2 #16: ERROR: asynchronous network error report on wlp2s0 (192.0.2.2:500), complainant 198.51.100.1: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
    ...
  • 一致しない IKE アルゴリズムの例:

    # ipsec auto --up vpn.example.com
    ...
    003 "vpn.example.com"[1] 193.110.157.148 #3: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni
  • 一致しない IPsec アルゴリズムの例:

    # ipsec auto --up vpn.example.com
    ...
    182 "vpn.example.com"[1] 193.110.157.148 #5: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_256 group=MODP2048}
    002 "vpn.example.com"[1] 193.110.157.148 #6: IKE_AUTH response contained the error notification NO_PROPOSAL_CHOSEN

    また、IKE バージョンが一致しないと、リモートエンドポイントが応答なしでリクエストを破棄する可能性がありました。これは、すべての IKE パケットを削除するファイアウォールと同じです。

  • IKEv2(Traffic Selectors - TS)で一致しない IP アドレス範囲の例:

    # ipsec auto --up vpn.example.com
    ...
    1v2 "vpn.example.com" #1: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=MODP2048}
    002 "vpn.example.com" #2: IKE_AUTH response contained the error notification TS_UNACCEPTABLE
  • IKEv1 で一致しない IP アドレス範囲の例

    # ipsec auto --up vpn.example.com
    ...
    031 "vpn.example.com" #2: STATE_QUICK_I1: 60 second timeout exceeded after 0 retransmits.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
  • IKEv1 で PreSharedKeys(PSK)を使用すると、両方の方向が同じ PSK に配置されなければ、IKE メッセージ全体が読み込めなくなります。

    # ipsec auto --up vpn.example.com
    ...
    003 "vpn.example.com" #1: received Hash Payload does not match computed value
    223 "vpn.example.com" #1: sending notification INVALID_HASH_INFORMATION to 192.0.2.23:500
  • IKEv2 では、不一致の不一致により AUTHENTICATION_FAILED メッセージが表示されます。

    # ipsec auto --up vpn.example.com
    ...
    002 "vpn.example.com" #1: IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED

Maximum transmission unit

IKE パケットまたは IPsec パケットをブロックするファイアウォール以外の一般的な原因は、暗号化パケットのパケットサイズの増加に関連します。ネットワークハードウェアは、最大伝送単位(MTU)を超えるパケットを 1500 バイトなどの断片化します。多くの場合、フラグメントは失われ、パケットは再アセンブルに失敗します。これにより、小規模なパケットを使用する ping テスト時に断続的なエラーが発生しますが、他のトラフィックは失敗します。この場合、SSH セッションを確立できますが、たとえばリモートホストに 'ls -al /usr' コマンドを入力するとすぐにターミナルがフリーズします。

この問題を回避するには、トンネル設定ファイルに mtu=1400 オプションを追加して、MTU サイズを縮小します。

TCP 接続の場合は、MSS 値を変更する iptables ルールを有効にします。

# iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

上記のコマンドでシナリオで問題が解決されない場合は、set-mss パラメーターで直接サイズを指定します。

# iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380

ネットワークアドレス変換 (NAT)

IPsec ホストが NAT ルーターとしても機能すると、パケットを再マッピングする可能性があります。以下の設定例は問題を示しています。

conn myvpn
    left=172.16.0.1
    leftsubnet=10.0.2.0/24
    right=172.16.0.2
    rightsubnet=192.168.0.0/16
…

172.16.0.1 アドレスのシステムには NAT ルールがあります。

iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE

アドレス 10.0.2.33 のシステムがパケットを 192.168.0.1 に送信する場合、ルーターは IPsec 暗号化を適用する前にソース 10.0.2.33 を 172.16.0.1 に変換します。

次に、ソースアドレス 10.0.2.33 のパケットは conn myvpn 設定と一致しなくなり、IPsec はこのパケットを暗号化しません。

この問題を解決するには、ルーターのターゲット IPsec サブネット範囲の NAT を除外するルールを挿入します。以下に例を示します。

iptables -t nat -I POSTROUTING -s 10.0.2.0/24 -d 192.168.0.0/16 -j RETURN

カーネル IPsec サブシステムのバグ

たとえば、バグにより IKE ユーザー空間と IPsec カーネルの同期が解除される場合など、カーネル IPsec サブシステムが失敗する可能性があります。このような問題を確認するには、以下を実行します。

$ cat /proc/net/xfrm_stat
XfrmInError                 0
XfrmInBufferError           0
...

上記のコマンドの出力のゼロ以外の値は、問題を示しています。この問題が発生した場合は、新しい サポートケース を作成し、直前のコマンドの出力と対応する IKE ログを割り当てます。

Libreswan のログ

デフォルトでは、syslog プロトコルを使用したLibreswan ログ。journalctl コマンドを使用して、IPsec に関連するログエントリーを検索できます。ログへの対応するエントリーは pluto IKE デーモンにより送信されるため、以下のようなキーワード「pluto」を検索します。

$ journalctl -b | grep pluto

ipsec サービスのライブログを表示するには、次のコマンドを実行します。

$ journalctl -f -u ipsec

ロギングのデフォルトレベルで設定問題が解決しない場合は、/etc/ipsec.conf ファイルの config setup セクションに plutodebug =all オプションを追加してデバッグログを有効にします。

デバッグロギングは多くのエントリーを生成し、journald サービスまたは syslogd サービスレートのいずれかが syslog メッセージを制限する可能性があることに注意してください。完全なログを取得するには、ロギングをファイルにリダイレクトします。/etc/ipsec.conf を編集し、config setup セクションに logfile=/var/log/pluto.log を追加します。