削除した WireGuard の peer が再起動後に戻ってくる理由
peer の一覧を保持する状態は二つあります。稼働中のインターフェースと、起動時にそれを書き込む側です。両方から外し、何かを編集する前に SaveConfig を確認してください。
アイデンティティは稼働中のインターフェースから消え、変更は完了したように見えます。サービスが再起動すると戻ってきます。これは WireGuard がコマンドを無視したように読めますが、実際に起きたことはもっと単純です。起動時の設定に、その peer がまだ残っているのです。
その一覧を保持する状態は二つあります。取り消しが本当になるのは、両方がそれを失ったときだけです。
wg set が実際に変えるもの
コマンド wg set wg0 peer <public-key> remove は、カーネル内で稼働中のインターフェースを編集します。ディスクには何も書きません。設定ファイル、NetworkManager のプロファイル、ルーターの保存状態はいずれも手つかずのままです。これは設計であり、不具合ではありません。
この分離は意図的です。ツールはインターフェースの所有者を知る由もないからです。実行時のコマンドは、別の何かが管理するインターフェースに対しても安全でなければなりません。永続的なコピーがどこにあるかは推測できません。結論は簡単です。実行時の削除は、構造上、一時的なものなのです。
だから次の再起動で peer は戻り、元の許可プレフィックスもそのまま復活します。そこを通る経路もすべて作り直されます。取り消したはずのアイデンティティが、再読み込みのあとに以前の宛先へ届いてしまうのです。実行時の出力には、警告ひとつ出ていませんでした。
ファイルを編集する前に、書き込む側を突き止める
インターフェースには所有者がいます。ファイルを読む wg-quick、プロファイルを適用する NetworkManager、ルーター自身のインターフェース設定、起動時にインターフェースを作り直すコンテナのエントリポイントなどです。所有者が決して読まないファイルを編集しても、永続的な変化は何も生まれません。
稼働中のインターフェースから始め、公開鍵を特定します。名前やアドレスは鍵そのものより弱い識別子だからです。そのうえで、その一覧を所有者が実際に読む保存済みの設定と突き合わせます。
wg show wg0 peers
wg show wg0 allowed-ips
systemctl status wg-quick@wg0 --no-pager
ls -l /etc/wireguard
稼働中のインターフェースの peer 一覧とファイルの中身が食い違っていれば、それが診断のすべてです。起動時には保存済みの設定が勝ち、実行時の状態は負けます。どちらかを変える前に、両者を比べてください。
SaveConfig の罠
wg-quick には、ファイルを手で編集する人を捕まえるねじれがあります。SaveConfig が有効な場合、文書化された停止時の挙動が、現在の実行時の状態を設定ファイルに書き戻します。
これは永続化の向きを逆にします。ファイルから peer を消し、そのあとサービスが止まります。すると稼働中の状態が編集の上に書き戻され、いま消した peer が復活します。
だから順序が重要です。インターフェースを止めた状態でファイルを編集するか、編集の前に SaveConfig を無効にし、そのあとインターフェースを上げ直して、何が読み込まれたかを確認します。インターフェースが上がったままの手編集は、停止時の書き込みとの競争です。
両方の状態を変えてから再読み込みする
実行時には鍵で peer を外します。保存済みの設定では、同じブロックを所有者がサポートする操作で外します。周りを編集して済ませるのではありません。
そのうえで、peer が何を担っていたかを見直します。取り消したアイデンティティに属していた経路は、意図して再割り当てするか削除すべきで、次に編集する peer に黙って引き継がせてはいけません。
ゲートウェイが管理用のアクセスも担っているなら、復旧の道を残しておきます。誤った peer を外す再起動は、自ら招いた停止です。誤った経路を外す再起動も同じです。
通るテストとはどんなものか
サービスを再読み込みするか再起動し、peer 一覧をもう一度読みます。古い鍵が消えていること、残すつもりの peer が今も存在して動いていることを確認します。
wg show wg0 peers
wg show wg0 allowed-ips
sudo wg-quick down wg0 && sudo wg-quick up wg0
wg show wg0 peers
状況が許すなら、古いアイデンティティが以前のリソースにもう届かないことを確かめます。再起動前の整ったインターフェース一覧は、テストの半分です。残りの半分は、そのあとアイデンティティがまだ何をできるかです。
何らかのマネージャーが peer を復活させ続けるなら、低レベルな削除の繰り返しをやめます。その書き込み側が読む台帳を直してください。それまでは、再起動のたびにアイデンティティへ再登場の招待を送っているのです。