Windows で OpenVPN アダプターが点滅する？IP の重複を確認

Windows で、アドレスを取得しては落とし、数秒ごとにそれを繰り返す OpenVPN アダプターは、通常 DHCP の不具合ではありません。アダプターには、すでに別の何かが応答しているアドレスを使うよう指示されているため、Windows はそれを使用不可と見なし、クライアントは最初からやり直します。競合はその下、オペレーティングシステム自身のネットワークスタック内で解決されるので、クライアントのログは静かなままです。

この違いは重要です、なぜならトンネル設定に向けたトラブルシューティングの手順は、どれもサーバー側の重複アドレスを見逃すからです。

クライアントのログではなく、Windows のイベントログから始める

Windows はアドレスの競合をシステムログにイベント ID 4198 と 4199 で記録します。前者はあるアドレスに検出された競合を報告し、後者はインターフェースが設定されたアドレスを使用できなかったことを報告します。どちらも OpenVPN には触れないため、見落としやすいのです。

最近のイベントを取得し、そのタイムスタンプをアダプターの更新サイクルと比較します: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap。十五秒ごとの競合は、応答し続ける所有者に対して同じアドレスを再試行するクライアントに一致します。接続時の単発の競合は、むしろ一度きりの衝突を示します。いずれにせよ、次の問いはほかに誰がそのアドレスを持っているかです。

二台のホストを一つのアドレスに載せる三つの構成

サーバーに誰がアドレスを持っていると思うか尋ね、次にネットワークに誰がそれに応答しているか尋ねます。grep -H ifconfig-push /etc/openvpn/ccd/* は固定されたトンネルアドレスとそれが属する証明書を一覧にします。ip -4 neigh show dev tap0 はブリッジが第二層で学習した内容を示します。この二つの一覧を比べれば、ほとんどの重複が 一分未満で見つかります。

三つの構成でほぼすべてが説明できます：client-config-dir のエントリが二つの証明書に一つのアドレスを固定する、ブリッジされた tap セグメントが別のホストがすでに静的に持つアドレスをマシンに渡す、あるいは古いリースファイルが、まだ接続中のクライアントが自分のものと思っているアドレスを返す、というものです。三番目が最も厄介で、ifconfig-pool-persist は既知のクライアントに対して意図的にアドレスを再利用します。

アドレスを奪い合うのではなく、一意にする

起動順序は今日どちらが勝つかを決めるだけなので、再起動手順に基づく修正は一時的なものと考えてください。各クライアントに独自の ifconfig-push 行を与えるか、ブリッジやサーバーのインターフェースが触れない範囲から静的アドレスを割り当てます。クライアント一覧で共通名の重複も確認してください、duplicate-cn は二つのセッションに一つの ID を共有させ、結果として一つの固定アドレスを共有させるからです。ブリッジされたデバイスに本当に固定アドレスが必要なら、独自のサブネットに移すか、サーバーが記録する場所でプールから予約してください。

persist ファイルは、どんなリースを保持しているか分かってから削除してください、そうしないと、次の再接続で同じアドレスが再び配られます。

正しい順序で再起動し、アドレスごとに 一人の所有者を確認する

まずサーバーに変更を適用し、それからクライアントを再接続して、すべての参加者が修正されたプールに対して登録されるようにします。クライアントを先に再起動すると、サーバーがまだ使用中と見なすアドレスを持ったままになります。再起動後にステータスファイルを読み、各共通名が一つのアドレスで一度だけ現れることを確認します。一つの名前に二つのエントリがあるのは、古いセッションが閉じられなかったという意味で、プールが壊れているわけではありません。

クライアントがまだアドレスを保てない場合は、同じホスト上のブリッジインターフェースがそのアドレスを持っていないか確認してください。ベンダーのデバイスからアドレスを引き継いだブリッジは、VPN サーバーがすでにそのアドレスをクライアントに渡していても、ARP に応答します。

チケットを閉じる前に、更新サイクルを丸ごと観察する

きれいな 一度の読み取りでは何も証明できません。アダプターを少なくとも十分間観察し、途中で再接続を強制します: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState。アドレスは再接続を生き延び、優先状態にとどまるはずです。

その後、最初の手順のイベントクエリをもう一度実行し、新しいものが何も返らないことを確認します。再接続を通して静かなログが、競合が消えた証拠です、一方、一度の接続の後の静かなログは、競合がまだ起きていないというだけです。最後に、トンネルの存在理由であるリソースをテストしてください、アドレスを失ったブリッジは、VPN 自体が正常に見えてもベンダーの経路を壊すことがあるからです。

プールの範囲、各固定アドレス、それを所有するホストをサーバーのメモに記録します。そうすれば次に衝突が起きたとき、再発見に半日かける代わりに数分で気づけます。