/etc/wireguard/wg0.conf にピアを追加し、systemctl restart wg-quick@wg0 を実行して、もう一度見るとピアはファイルから消えています。何かが壊れたわけではありません。再起動は停止の後に起動が続くものであり、停止の段階が現在の実行状態を、たった今編集したファイルの上に書き戻すことがあります。原因となる設定は、編集していたのと同じファイルの中にあり、それがこのループを初めて遭遇したときにこれほど混乱させる理由です。

二つの状態、一つのファイル、そして停止時の保存

WireGuard の実行状態と wg-quick の設定ファイルは関連していますが別物です。ファイルは入力です:wg-quick がそれを読み、インターフェースを作成し、アドレスとルートを設定し、ピアを構成します。カーネルデバイスが生きたオブジェクトであり、wg で行った低レベルの変更は決して自分自身を書き戻しません。

一方向を除いて。インターフェースのセクションに SaveConfig = true があると、wg-quick はインターフェースを下ろす一環として、生きた設定をファイルに保存します。wg-quick のマニュアルはまさにこの点を警告しています:インターフェースが有効な間にファイルへ加えた変更は、削除時に上書きされる可能性があります。これは停止時の保存であり、バックグラウンドのタイマーではないため、何かがインターフェースを停止したときにだけ作動します。

ActionWhat it writesWhen it surprises you
wg set on a live interfaceKernel state onlyAfter reboot, when the file was never updated
wg-quick down with SaveConfigLive state into the fileRight after you edited the file
wg syncconfKernel state onlyNever; it does not touch the file
wg-quick upKernel state from the fileIf the file is stale, you get the old tunnel

この表は順序に関する警告として読んでください。この領域での偶発的な消失はすべて、保存の後ではなく前に起きた編集から生じます。

まず停止し、次に編集し、最後に起動する

ファイルがあなたの真実の源なら、希望ではなく構造によってファイルを権威あるものにしてください。インターフェースを下ろし、消えたことを確認してから編集し、その後で再び上げます。規則は単純です:保存がまだ実行できるうちは、編集が存在してはなりません。

sudo cp -a /etc/wireguard/wg0.conf /root/wg0.conf.$(date +%F-%H%M)
sudo wg-quick down wg0
ls /sys/class/net/wg0 2>/dev/null || echo "interface is gone"
sudoedit /etc/wireguard/wg0.conf
sudo wg-quick up wg0

バックアップの行は儀式ではありません。トンネルがこのマシンへの到達手段なら、下ろす段階でセッションが終わる可能性があり、ディスク上のコピーとコンソールまたは帯域外の経路だけが機能するロールバックです。その二行目を信じる前に確認してください:静かに失敗するスクリプトの中の古いインターフェース名こそ、人々がまだ生きているファイルを編集してしまう原因です。

通常の停止の前に SaveConfig = false を設定するのがもう一つの認められた方法で、それは wg-quick が実際に読むファイルの中で行う必要があります。それによってあの自動保存を一つ防げます。別の NetworkManager プロファイル、ルーターのエクスポート、コンテナのエントリポイントがあなたの編集を再読み込みすることはありません、なぜならそれらの管理機構はこのファイルをまったく読まないからです。

インターフェースを引き裂かずにピアの変更を適用する

すべての編集に停止が必要なわけではありません。ピアレベルの変更は、ファイルを設定に変換して同期することで稼働中のインターフェースに適用でき、停止の段階を完全に避け、したがって保存も避けられます:

sudo wg syncconf wg0 <(sudo wg-quick strip wg0)
sudo wg show wg0 peers
sudo wg show wg0 latest-handshakes

strip の段階が重要です。wg-quick 専用のキーを取り除いたファイルを出力するので、アドレス、DNS、ルーティングの指示が、それらを理解しないツールに渡ることはありません。その後、同期はインターフェースを再作成せずにピアとキーを生きたデバイスに適用するため、既存のセッションとルートは生き残ります。

限界について正確に。ピアの同期はインターフェースのアドレス、wg-quick が追加したルート、リゾルバーの設定を変えません、なぜならそれらのどれも WireGuard デバイスに属していないからです。AllowedIPs にサブネットを追加してカーネルがルーティングすると期待するのは古典的な誤読です:ルートは起動時に wg-quick が、あるいはあなた自身が追加する必要があります。

何かを編集する前にインターフェースの所有者を確認する

設定システムに管理されたデスクトップやサーバーでは、ファイルは入力ではなく出力かもしれません。NetworkManager の接続、ルーターが生成したプロファイル、コンテナの起動スクリプトはどれも同じインターフェース名を所有でき、その場合、完璧な wg-quick の手順でも間違った成果物を編集してしまいます。

systemctl status wg-quick@wg0 --no-pager
nmcli connection show | grep -i wireguard
sudo wg showconf wg0 | head -n 5

三番目のコマンドは生きた設定をファイルと同じ形式で出力し、秘密鍵も含みますが、比較には便利でチケットでは危険です。貼り付ける前に伏せてください:サポートスレッドの秘密鍵は恒久的な漏えいであり、誤字ではありません。

サービスユニットが非アクティブなのにインターフェースが存在するなら、何か別のものがそれを作っており、ファイルは権威ではありません。その一つの観察が、何も読まないファイルを編集する一時間を節約します。

次の再起動を検証し、その後ロールバックを保つ

修正を本当に証明するテストは二回目の再起動です、なぜなら最初に失敗したのはまさにその手順だからです。ピアがそれを生き延びること、そして生きた設定がまだディスク上のものと一致していることを確認してください:

sudo systemctl restart wg-quick@wg0
sudo wg show wg0 latest-handshakes
sudo grep -c '^\[Peer\]' /etc/wireguard/wg0.conf

再起動を二回実行します。一度のきれいな通過は運かもしれません:最初の再起動がまだ保存されていない実行時の変更を消費することがあるので、二回目が、最初の終了時にファイルと実行状態が一致していたことを教えてくれます。

二重の再起動を終えるまで、プロセスの最初からバックアップを保持し、その後で削除するか設定ディレクトリの外へ移動してください。本物のファイルの隣に残った wg0.conf.bak は wg-quick には無害で、次の人を混乱させ、結局は間違った方を編集させることになります。

関連記事