VPN インターフェースが firewalld ゾーンから離れ続ける理由

tun0 を正しいゾーンに追加するとアプリケーションは動き始め、次の再接続で修正は消え去ります。同じコマンドをもう一度実行すると効くので、firewalld が忘れたように見えます。忘れたのではなく、そのインターフェースにより強い主張を持つ何かが割り当て直したのです。

ゾーンはインターフェースが作り直されるまで残ります

インターフェースへの firewalld ゾーンの割り当てはバインディングであり、バインディングは今存在するインターフェースオブジェクトに結び付いています。デバイスを破棄して作り直す VPN クライアントは新しいオブジェクトを生み、新しいものは割り当てを行うコンポーネントの言うところから始まります。症状がパケットごとではなく再接続のたびに繰り返すのはそのためです。

同じ理屈が再起動時の挙動も説明します——実行時のバインディングは再起動を生き延びず、永続的なバインディングは firewalld が自分のものと見なすデバイスにしか適用されません。

何かを変える前に、どのコンポーネントがゾーンを割り当てているのかを突き止めてください。

何かを変える前に三つのことを読んでください

インターフェースが現在持つゾーン、そのインターフェースを伴うアクティブなゾーン、意図するゾーンの永続的なインターフェース一覧を記録します。その問い合わせは変更前、再接続後、再起動後に実行します。三つの結果を比べれば、バインディングが置き換えられているのか、無視されているのか、単に遅れて適用されているのかが分かります。永続的な一覧がすでにデバイスを挙げているのに実行時のゾーンが食い違うなら、何かが編集を上書きしています。

各段階で実際のデバイス名も記録してください——今日 tun0 に着地するトンネルが明日は tun1 に着地するかもしれないからです。

一般的な名前への保存済みバインディングは同一性の確認ではなく、二分会の記録が一時間の当て推量を省きます。

NetworkManager が接続を所有している場合

NetworkManager が VPN 接続を管理しているなら、そのプロファイルがゾーンを保持し、接続が有効になったときに firewalld へ渡します。同じデバイスに対する firewalld の永続的なインターフェースバインディングは、所有者が NetworkManager なので無視されることがあります。ゾーンは接続側で設定し、無関係な物理接続や一時的なレコードではなく VPN プロファイルを編集していることを確認してください。

そのプロパティを変更すると、アクティブな接続に即座に影響することがあります。

管理経路を確保し、適用する前に宛先ゾーンのポリシーを読んでください。ifcfg ファイルの ZONE フィールドの編集が正しいのは、そのファイルがまだ設定の供給元である場合だけです。

firewalld がバインディングを所有している場合

意図的に安定したインターフェース名を持つ独立したトンネルには、永続的なインターフェース変更が適切な道具です。配備が使う再読み込みやライフサイクルを通じて適用し、そのあと実行時の状態を調べてください——永続側だけの編集は、何が有効かではなく意図を記述するものだからです。両者は再読み込みにかかる時間だけ食い違うことがあります。

インターフェース名が動的なら、名前を先に取るトンネルと競争するのではなく、接続のライフサイクルを通じて割り当てを維持してください。

インターフェースを trusted に放り込むのは、アプリケーションを動かすためだけの理由であってはなりません。

再読み込み、再接続、再起動を試してください

変更は三つすべてを生き延びたときに初めて完了します。

まず再読み込みしてください——実行時だけの編集が消えるのはそこです。次にトンネルを再接続してください——置き換えられたインターフェースがバインディングを失うのはそこです。次に再起動してください——所有者の食い違いが最後に現れるのはそこです。各段階でゾーンを記録し、書き留めた意図と比べ、どの段階が違いを生んだのかを記してください。

ゾーンが正しいのにアプリケーションがまだ失敗するなら、問題はメンバーシップではなく、ゾーンの規則か送信元に基づく分類にあります。接続とインターフェースに関する firewalld の文書が、所有権がどう働くべきかの参照先です。

所有者、値、期待する結果を runbook に書き込めば、次の再割り当ては説明できるものになります。