VPNブリッジのスクリプトが今もbrctlを呼ぶ理由と意味

トンネルクライアントは導入済みで、プロファイルも有効なのに、補助スクリプトはbrctlというコマンドで失敗します。VPNパッケージを再インストールしても直りません。足りないプログラムはトンネルの一部ではなく、ローカルのブリッジスクリプトの一部だからです。そのスクリプトは、現在のシステムが既定ではもう提供しないツールを要求しています。二つの問題が関係して見えるのは、スクリプトが接続時に動くからにすぎません。

補助プログラムの欠落はトンネルの障害ではない

まず正確な呼び出しとその環境を確認します。対話シェルにあるコマンドが、サービスの制限された検索パスには無いことがあるため、「見つからない」というエラーは二つの別の意味を持ち得ます。サービスのユーザーとして command -v brctl を実行し、スクリプトを起動するユニットを読みます systemctl cat openvpn-bridge-helper または同等のコマンドで確認してください。エラー文は通常、欠けているバイナリ名を示しており、その名前が解決すべき依存関係です。

トンネルクライアントの再インストールで得られるのはトンネルであり、ブリッジ用のユーティリティではありません。両者は別々の保守担当者が管理する別のパッケージです。

brctlがしていたこと、そして廃止された理由

このツールはLinuxのEthernetブリッジを作成・管理していました。addbr がブリッジを作り、addif がポートを接続しました。Debianのマニュアルはこれを廃止扱いとし、より広く対応するiproute2のブリッジツールを指し示しています。廃止はどこからも削除されたという意味ではなく、新しいツールがあるからといってスクリプト内の文字どおりのbrctl呼び出しが成功するわけでもありません。

つまり問いはbrctlが良いかどうかではありません。スクリプトが今も保守されているか、そしてディストリビューションがどのパッケージを提供しているか（あれば）です。

正直な選択肢は二つ、保守か移行か

保守とは、ディストリビューションのサポート対象パッケージから文書化された依存関係を導入し、スクリプトの出所、想定バージョン、実行経路を確認することです。それで欠けた実行ファイルは満たせますが、それだけです。スクリプトのブリッジ名、アドレス計画、後片付けの挙動は検証されないままです。移行とは、サポート対象のネットワーク構成に向けて想定された操作を書き直すことです。ブリッジ作成、ポート接続、ホストのアドレス設定、リンク有効化は四つの別々の変更であり、brctlから別のユーティリティへのシェルエイリアスは翻訳ではありません。

iproute2の同等品は短いものです。ip link add name br-vpn type bridge がブリッジを作り、ip link set tap0 master br-vpn がポートを接続します。

どちらの選択肢を選んだのか、スクリプトの所有者が誰なのかを書き留めてください。両方のツールを呼ぶ中途半端な補助スクリプトは、どちらか一方より悪い結果になります。

どちらを選ぶ前にブリッジの設計を見直す

Ethernetブリッジは、Ethernet伝送とTAPのピアを必要とする設計に向いています。ブリッジのユーティリティを導入しても、ルーティングされたTUN接続がブリッジになるわけではなく、サポート対象のルーティングプロファイルを無関係なスクリプトに合わせて曲げるべきでもありません。プロファイルがルーティングするなら、なぜブリッジ補助スクリプトが動くのかを突き止めてください。

実際のブリッジに触れる前に、管理経路を確保し、ネットワーク構成の唯一の所有者を特定してください。

依存関係を直したら、次に現れるエラーを読んでください。ローカルのブリッジ設定、遠隔認証、その結果を通る許可された通信は三つの別々の結果であり、brctlに関係していたのはそのうち一つだけです。