再起動後にWireGuardのピアが消える：本当の設定を見つける

wg set で追加したピアは午後いっぱい ping に応答し、再起動後には消えています。壊れたわけではありません——カーネルはそのピアを稼働中のインターフェース以外のどこにも保存しておらず、起動時にインターフェースを作り直す何かが、あなたが触っていないファイルからそれを組み直しただけです。直し方は、もう一度 wg set を打つことではありません。どのコンポーネントがインターフェースを所有しているかを見極め、そのコンポーネントの状態を編集し、ピアがそれを消したライフサイクルイベントを実際に生き延びることを証明することです。

まず一度、意図的に再現する

再起動の問題は、自分の目で起きるのを見るまで直してはいけません。コンソールかアウトオブバンドの経路を確保したうえでピア一覧を控え、インターフェースを所有しているサービス経由で再起動し、比べます。ピアがまだ残っているなら、あなたの変更はすでに永続状態に届いており、見当違いのイベントを追っています。

その作業中に三つの事実を書き留めます——インターフェース名、それを起動したユニットまたはプロファイル、そして生き残ったピアのハンドシェイク回数がリセットされたかどうかです。回数がリセットされていれば、インターフェースは破棄されて作り直されており、回数が変わらないのにピアが消えているなら、何かがあなたの足元で設定を書き換えています。

インターフェースの所有者は誰か？

WireGuard 自体にはデーモンも設定ファイルもありません。その上にある何かが起動時に wg を呼び出しており、その何かが真実の源です。よくある候補は [email protected]、NetworkManager の接続プロファイル、ディストリビューション固有のネットワークユニット、あるいは独自のデータベースに書き込む管理パネルです。

ディストリビューションのドキュメントではなく、システムに尋ねてください。systemctl status wg-quick@wg0 と nmcli connection show なら、たいていは一つずつで決着します。両方がインターフェースを主張しているなら、何かを編集する前にバグを突き止めたことになります——二人の所有者が起動のたびに同じデバイスを書き換え、最後に走ったほうが勝つのです。

systemctl status wg-quick@wg0 --no-pager
grep -R "Address\|SaveConfig\|PostUp" /etc/wireguard/wg0.conf
nmcli -g NAME,TYPE connection show
wg show wg0 peers

実行時の状態と起動時の状態は同じファイルではない

wg set は netlink を通じて稼働中のデバイスを操作します。/etc/wireguard/wg0.conf や NetworkManager のプロファイル、パネルのデータベースには書き込みません。その後で wg show が成功しても、カーネルがピアを受け入れたことしか示さず、何かがそれを復元する保証にはなりません。

逆向きの落とし穴もあります。wg-quick の SaveConfig オプションは、インターフェースを下ろすときに現在の状態を設定ファイルへ書き戻します。これが有効だと、インターフェースが上がっている間のファイル編集は、直後の停止で上書きされ得ます——そしてあなたは、あの行は確かにあったと誓うことになります。ピアが何度も戻ってくるなら、ファイルは停止後に読んでください——停止前ではありません。

NetworkManager はさらに別の振る舞いをします——プロファイルを所有し、有効化時に適用するので、稼働中の NetworkManager 接続の隣にある手編集の .conf は飾りにすぎません。インターフェースの所有者を一人に決め、もう一方の管理側には手を出させないでください。

変更を両方の場所に届かせる

まず永続状態を編集し、次に所有者に適用させ、最後に稼働中の状態を確認します。この順序なら、どの段階で失敗しても、三つではなく一つの原因を指します。

# 1. persistent state (wg-quick owner)
sudo vi /etc/wireguard/wg0.conf

# 2. apply through the owner, not by hand
sudo systemctl restart wg-quick@wg0

# 3. verify runtime matches the file
sudo wg show wg0
sudo wg showconf wg0

wg showconf は稼働中の設定を、ファイルと同じ構文で出力します——だから二つを直接見比べられます。この出力は秘密として扱ってください——秘密鍵が含まれるので、チケットやチャットに貼ってはいけません。ピアの公開鍵と許可された IP を比べ、意図的に外したピアが戻っていないことを確認します。

ライフサイクルイベントを生き延びることを証明する

所有者経由でもう一度再起動し、三つの別々の事実を確認します——ピアが wg show に現れること、通信後にハンドシェイク回数が増えること、トンネルに依存するアプリケーションが実際に応答することです。古いハンドシェイクのまま一覧に出ているピアは、ルーティングか鍵の問題であり、永続性の問題ではありません——この区別が、無駄な設定編集を防ぎます。

最後に、再起動が何を復元したかを確認します。意図的に消したピアが蘇る再起動は、符号が逆なだけで同じバグであり、たいていは設定の古いコピーがどこかからまだ読み込まれていることを意味します。所有者、ファイルパス、ピアの公開鍵、確認コマンドを設定のそばに記録しておけば、次の人が本番ホストを再起動して同じ発見を繰り返すことはありません。