VPN接続後にローカルIPアドレスの競合を解消する

こうした報告はどれも同じに聞こえて、意味はそれぞれ違います：ノートPCがアドレス競合を訴えるのですが、起きるのは時々で、多くはVPNが有効なときです。このメッセージを出す障害は三つあります：自分のリンク上の本物の重複、リモートネットワークがLANの範囲を使っていて何も重複していない重なり、そして一つのアドレスを二つのピアに渡したトンネルです。修理の仕方はそれぞれ違い、間違った処置は症状を取り除くどころか場所を移すだけです。だから何かを編集する前に、どのケースなのかを決めてください。

同じエラーメッセージを出す三つの障害

重複とは、同じセグメントの二台が同じアドレスを主張している状態です。カーネルが気づくのは、自分のプローブへの応答が別のMACから来るからで、その後の動きはスタック次第です：Linuxはログに残し、Windowsはインターフェースを無効にしてシステムログに項目を書き、DHCPクライアントはその提供を拒否することがあります。

重なりはどのアドレスも重複させません。あなたのLANは192.168.1.0/24、オフィスのネットワークも192.168.1.0/24で、オフィスへの経路が、プリンタやNASでもあるアドレスを指しています。ARPの意味では何も競合しておらず、パケットは二つのネットワークの片方で誤った機器に届くだけです。

プールの衝突はトンネル自身の不具合です。二つのピアが同じトンネルアドレスで設定されたか、割り当てられたため、戻りのトラフィックを送るときにサーバが両者を区別できません。二つのクライアントの片方はハンドシェイクが通りながらデータが来ない状態になり、これはルーティングの問題に見えて、そうではありません。

テスト1: 重複は自分のセグメントにあるか

まず、覚えている設定ではなく、実際にマシンが持っているものを一覧にします。VPNアダプタのアドレスはトンネル専用で、ウェブサイトが見るアドレスとは違います、共有の公開出口は競合ではありません。

ip -br addr
ip neigh
ip route show table all | grep -E 'wg|tun|ppp'

Windowsでは同じ情報がipconfig /allとGet-NetIPAddressから得られ、近隣キャッシュはarp -aにあります。争点のアドレスが物理アダプタ側にあり、VPNを動かさなくても不具合が出るなら、VPNは傍観者であり、その診断はやめるべきです。

推測ではなく重複を証明するには、そのアドレスを持たない機器からプローブします。arping -Dは送信元アドレスをゼロにしてプローブを送るので、予期しないMACからの応答があれば、別のホストがすでにそのアドレスに応答している証拠になります。

sudo arping -D -I eth0 -c 3 192.168.1.50

次に、自分で別のアドレスを選ぶのではなく、ネットワーク管理者を通じて持ち主を探します。誰かのメモにしか存在しない固定割り当て、固定アドレスのプリンタ、DHCPサーバの予約が常連の原因で、電源の切れた機器もリースを保持しています。

テスト2: 二つのネットワークは重なっているか

トンネルが渡すプレフィックスと、自分のインターフェースのプレフィックスを比べます。リモートの範囲がLANと同じか、それを含んでいるなら、障害は重なりで、手がかりは、VPNなしで届いていたホストが消えること、あるいは自分のプリンタがオフィスのアドレスで応答することです。

ip route get 192.168.1.10
ip -br addr show

経路の照会はカーネルがどのインターフェースを使うかを教えてくれ、その答えが診断のすべてです。ローカルのプリンタに属するアドレスに対してトンネルを返すなら、重なりがあり、リースを更新しても変わりません。

出口は三つあり、ふつう使えるのは一つだけです。リモート側が重なったサブネットのトラフィックをマスカレードすれば、クライアントが見るのはサーバのトンネルアドレスだけになります。トンネルがLANと衝突しない狭いリモートプレフィックスを運ぶこともできます。あるいはクライアントがポリシールールで送信元アドレスごとに経路を分ける方法もありますが、動くものの脆く、同僚に引き継ぐのは難しいです。

オフィスのネットワークを振り直すかどうかは、めったにあなたの決定ではありません。衝突を避けるために自分のLANを振り直すのは、プリンタやカメラ、固定ホストが絡むと、多くの人が思うより大きな変更になります。

テスト3: トンネルは同じアドレスを二度配ったか

WireGuardにアドレスのプールはありません。各ピアは公開鍵とAllowedIPsのプレフィックスで識別されるので、同じトンネルアドレスを二つのピア項目に書いたり、同じ鍵ペアを二台に入れたりすると重複が現れます。

wg show all allowed-ips
wg show wg0 latest-handshakes
wg show wg0 transfer

ここで役に立つ列はトラフィックカウンタです：最近のハンドシェイクがあるのに転送がないピアは、アドレスが誤っているか、同じプレフィックスを主張する別の項目に隠れています。プレフィックスはちょうど一つのピアに置き、各機器に固有の鍵ペアを与えてください。

OpenVPNにはプールがあり、よくある衝突は固定の--ifconfig行を含むクライアントプロファイルを二台目にコピーすることです。すると両方のクライアントが同じトンネルアドレスを要求し、サーバは先に処理したセッションを受け入れます。--duplicate-cnを付けた状態でのプール枯渇も、一つの証明書の複数セッションが一つの項目を奪い合うと同じ結果になります。

この件ではクライアントのログではなくサーバのログを読みます。どのセッションがどのアドレスを取ったかをサーバは知っており、そこで重複したアドレスはクライアントには届かない警告として現れます。

発生源で直し、そのうえで両方の機器を再確認する

順序が重要です。まずLANの重複を直します、アドレスを保てないクライアントはトンネルも保てないからです。次にVPN側の割り当てを直します、プール割り当てに対するクライアント側の変更は次の接続で取り消されるからです。最後に重複した身元を扱います：WireGuardでは鍵ペアを分け、OpenVPNでは証明書か、少なくともプロファイルを分けてください。

クライアント側の作業は短いものです。DHCPリースを解放して更新するか、予約のためにサーバ側でアドレスを変えてもらいます。空いていそうな適当なアドレスを打ち込まないでください。

sudo dhclient -r eth0 && sudo dhclient eth0
ipconfig /release && ipconfig /renew

そして片側ではなく両側で確認します。ゲートウェイ、実際に必要なサービス、再接続して再確認、の順です。二台が関わったなら両方を確認してください：片方のアドレスを動かすと、もう片方に古い近隣項目や、後で再び現れる古いリースが残ります。

途中でやってはいけないこと

症状を黙らせないでください。重複アドレス検出は、使用中のアドレスを取ってしまうのを防ぐ仕組みであり、切ると見えていた競合が、追跡の難しい断続的なパケット損失に変わります。予期しないホストの証明書警告を受け入れるのも同じで、それはアドレスの問題ですらなく、素通りさせると別の障害を隠します。

管理されたネットワークのアドレス設計も自分で変えないでください。元の設定を記録し、アドレスが中央で割り当てられる場合は管理者に確認し、変更は戻せる範囲に留めます。RFC 5227のアドレス競合検出の規則は、正しいプローブが何を証明するかを説明しており、競合を本物と判断する前に知っておく価値があります。