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

VPN 接続の問題は、エンドポイント間の設定の不一致が原因で発生することがよくあります。

IPsec 接続が確立されていることを確認するには、次のように入力します。

ipsec trafficstatus

# 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=198.51.100.1/32

接続が正常な場合、このコマンドで、接続の名前と詳細を含むエントリーが表示されます。出力が空の場合、トンネルが確立されていません。

エンドポイントまたは中間ルートのファイアウォールが Internet Key Exchange バージョン 2 (IKEv2) のパケットを破棄すると、ipsec up コマンドがタイムアウトし、retransmission メッセージが繰り返し表示されます。

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 response
...

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 response
...

tcpdump ユーティリティーを使用してトラフィックをキャプチャーすると、IKE または IPsec パケットがファイアウォールによって破棄されているかどうかを確認できます。次に例を示します。

tcpdump -i <interface> -n -n esp or udp port 500 or udp port 4500 or tcp port 4500

# tcpdump -i <interface> -n -n esp or udp port 500 or udp port 4500 or tcp port 4500

IKE プロトコルは暗号化されているため、tcpdump は他の種類の IPsec の問題の診断には限定的にしか使用できないことに注意してください。

各エンドポイントが、同じ Internet Key Exchange (IKE) バージョン、アルゴリズム、IP アドレス範囲、または事前共有鍵 (PSK) で設定されていない場合、VPN 接続は失敗します。不一致が見つかった場合は、両方のエンドポイントの設定を調整して問題を解決する必要があります。

パケットのサイズは、暗号化およびカプセル化のプロセスにより増加します。パケットがネットワークの最大転送単位 (MTU) (通常は 1500 バイト) を超えると、パケットは断片化されます。これにより、断続的な接続障害が発生し、断片が失われ、元のパケットを再構成できなくなることがあります。一般的な症状としては、ping などの小さなパケットでは正常に動作するが、SSH セッションなどの大きなパケットではログイン後にフリーズすることなどが挙げられます。

この問題を解決するには、設定ファイルに mtu=1400 オプションを追加して、トンネルの MTU を下げます。

IPsec ホストが NAT ルーターとしても機能する場合、IPsec トンネル宛のパケットに誤って NAT が適用されることがあります。たとえば、IPsec 暗号化が適用される前に、パケットの送信元 IP アドレスがマスカレードルールによって変換されると、そのパケットの送信元が IPsec ポリシーと一致しなくなり、Libreswan がそのパケットを暗号化せずにネットワーク経由で送信してしまいます。

この問題を解決するには、IPsec サブネット間のトラフィックを NAT から除外するファイアウォールルールを追加します。このルールは、一般的な NAT ルールの前に処理されるように、POSTROUTING チェーンの先頭に挿入する必要があります。

nft add table ip nat
nft add chain ip nat postrouting { type nat hook postrouting priority 100 \; }
nft add rule ip nat postrouting ip saddr 192.0.2.0/24 ip daddr 198.51.100.0/24 return

# nft add table ip nat
# nft add chain ip nat postrouting { type nat hook postrouting priority 100 \; }
# nft add rule ip nat postrouting ip saddr 192.0.2.0/24 ip daddr 198.51.100.0/24 return

よくある問題として、VPN トンネルが正常に確立されたように見えても、トラフィックが通過しないことがあります。このような場合は、カーネルの IPsec の状態を調べて、トンネルポリシーと暗号鍵が正しくインストールされているかどうかを確認できます。

このプロセスでは、次の 2 つのコンポーネントをチェックします。

まず、SPD に正しいポリシーが存在するかどうかを確認します。

ip xfrm policy

# ip xfrm policy
src 192.0.2.1/32 dst 10.0.0.0/8
	dir out priority 666 ptype main
	tmpl src 198.51.100.13 dst 203.0.113.22
		proto esp reqid 16417 mode tunnel

出力に、leftsubnet および rightsubnet パラメーターに一致するポリシーが、in 方向と out 方向の両方で含まれているはずです。トラフィックのポリシーが表示されない場合は、Libreswan がカーネルルールの作成に失敗しており、トラフィックは暗号化されていません。

ポリシーが存在する場合は、SAD 内に対応する鍵セットがあるかどうかを確認します。

ip xfrm state

# ip xfrm state
src 203.0.113.22 dst 198.51.100.13
	proto esp spi 0xa78b3fdb reqid 16417 mode tunnel
	auth-trunc hmac(sha1) 0x3763cd3b... 96
	enc cbc(aes) 0xd9dba399...

ポリシーが存在するにもかかわらず、同じ reqid を持つ対応する状態が表示されない場合は、通常、Internet Key Exchange (IKE) ネゴシエーションが失敗しています。2 つの VPN エンドポイントが、鍵セットについて合意できなかったということです。

より詳細な診断を行うには、いずれかのコマンドで -s オプションを使用します。このオプションはトラフィックカウンターを追加します。これは、カーネルが特定のルールに従ってパケットを処理しているかどうかを確認するのに役立ちます。

まれに、カーネルの IPsec サブシステムの不具合により、Internet Key Exchange (IKE) ユーザー空間デーモンとの同期が失われる場合があります。この同期のずれにより、ネゴシエートされたセキュリティーアソシエーションと、カーネル内における IPsec ポリシーの実際の適用との間にずれが生じ、セキュアなネットワーク通信が中断される場合があります。カーネルレベルのエラーを確認するには、変換 (XFRM) の統計情報を表示します。

cat /proc/net/xfrm_stat

# cat /proc/net/xfrm_stat

出力内のいずれかのカウンター (XfrmInError など) がゼロ以外の値を示している場合、カーネルサブシステムに問題があります。このような場合は、サポートケース を作成し、コマンドの出力と対応する IKE ログを添付してください。

Libreswan はイベントをジャーナルに記録します。ipsec サービスのジャーナルを表示するには、次のように入力します。

journalctl -xeu ipsec

# journalctl -xeu ipsec

デフォルトのロギングレベルでは十分な詳細情報が得られない場合は、/etc/ipsec.conf ファイルの config setup セクションに次の設定を追加して、包括的なデバッグロギングを有効にします。

plutodebug=all
logfile=/var/log/pluto.log

plutodebug=all
logfile=/var/log/pluto.log

デバッグロギングでは多数のエントリーが生成されることがあります。そのため、メッセージを専用のログファイルにリダイレクトすると、journald および systemd サービスによるメッセージのレート制限を防ぐことができます。