ソケットのアクティブ化と WireGuard の循環依存関係

ソケットのアクティブ化と WireGuard の循環依存関係

systemd で実行できる興味深いことの 1 つは、「ソケットのアクティベーション」機能を使用することです。systemd 自体がリッスン用に何らかのソケットを開き、それを inetd スタイルでプログラムに渡します。そして、はい、「inetd スタイル」と言うことで、それが新しいものには程遠いことはわかります。明らかに。これは、それを使って他に何ができるかについてです。

私の場合のように
前の話
systemd に関しては、「拒否」ルールと「許可」ルールを追加して、何を行っているかに別の次元のフィルタリングをもたらすことができます。これは、このソケットのアクティブ化の一部である .socket ファイルに当てはまります。特定のインターフェイスに強制的にバインドすることもできます。

[Socket]
ListenStream=443
IPAddressDeny=any
IPAddressAllow=192.0.2.0/24
BindToDevice=wg0

これにより、TCP ポート 443 をリッスンし、相手側が特定の /24 にない限り、トラフィックをドロップする bpf 詐欺を実行するソケットが得られます。次に、それをロックダウンして、全世界をリッスンするのではなく、この wg0 インターフェイス (この場合は WireGuard を意味します) にバインドします。

これに通常の IP を加えたもの[6]テーブル ルールを使用すると、物事がかなり厳密に定義されます。それが私が気に入っている方法です。

私は過去 1 年間これを大々的に行いましたが、そのような魔法をインストールした後、問題のボックスを再起動することはありませんでした。そして今週初めに、そのシステムの「個性」を新しいハードウェアに移行しました。そのため、あちこちで起動と再起動が必要になり、毎回再起動に 2 分近くかかっていたのは奇妙ではありませんでしたか?一体どういうことでしょう？

systemd ジャーナルを詳しく調べると、「wg」関連の一部が登場していないことがわかり、確かに依存関係のサイクルのように見えました。 A は B に依存し、B は C に依存し、B は D に依存し、また B は A に依存しますか?最終的にタイムアウトが発生しなければ、起動することはなかったでしょう。

残りのボックスが起動し、あの小さな頭のない怪物に乗り込んで問題に取り組むことができたので、このタイムアウトには感謝しています。

問題は基本的に次のようなものです。systemd 環境で .socket を設定している場合、デフォルトでは起動時のシーケンス/順序付けに関していくつかの依存関係が検出され、そのうちの 1 つが「sockets.target」です。 foo.socket には基本的に「Before=sockets.target」があり、これは、sockets.target は起動して実行するまで成功しないことを意味します。

しかし、foo.socket に WireGuard を指す BindToDevice がある場合はどうなるでしょうか?これで、今後の wg0 への依存関係ができました。少なくとも Debian には依存関係があります。これは興味深いことです。なぜなら、(「wg-quick@wg0」など) は、basic.target を実行することを望んでおり、basic.target を実行する必要があるからです。次に、socket.target が最初に発生することを望みます。

foo.socket は待機します。 wg は基本的に待機します。 ソケットは待機します。 foo.socket は待機します。そこにはサイクルがあります。

この混乱から抜け出すことは、サイクルを断ち切ることを意味します。その方法は、次のように .socket ファイルからデフォルトの依存関係を削除することです。

[Unit]
DefaultDependencies=no

その後、.socket に適切な WantedBy、Wants、Before または After 宣言を設定して、それがコール グラフのどこかに確実にアタッチされるようにするのはあなたの責任です。

ここにたどり着くまでに、再起動、ジャーナル分析、悪口、そして全般的に不平不満を言うのに多くの時間がかかったということを言っておかなければなりません。このような混乱に陥った場合は、「systemd-analyze dump」 ” は通常、あなたの友人です。これは、同様に重要であるものの、.socket ファイルや .service ファイルには表示されない *暗黙的な* 依存関係を指摘してくれるからです。その後、それを紙にスケッチし、さらに悪口を言います。 、ループしなくなるように調整します。

ブート中にこの種の問題に遭遇する前に、この種の問題を発見する良い方法はないようです。確かに、足元に直接大砲を向ける前に足を止めるようなものではありません。どうやら、「systemd-analyze verify」 ” は、少なくともサイクルがあることを警告しますが、どのようにしてそこに到達し、それに対して何をすべきかを理解するのは完全にあなた次第です。また、検証ステップを実行したことを覚えていない場合は、明らかにうまくいきません。あなたを助けるために、私はこの投稿を書いているときに今そのことを知りました。私が抱えていた問題には遅すぎました。

確かに機能は気に入っていますが、その複雑さが大きな課題になる可能性があります。