トンネルは上がり、ログは接続済みと告げているのに、あるアプリケーションは何にも到達できない。Linuxクライアントでは、これは通常、ディストリビューションのファイアウォールがVPNクライアントの管理していない経路をフィルタしていることを意味する。二つの管理機構が同時に有効になり、それぞれがインターフェース、ゾーン、トラフィックの方向について独自の考えを持つことがある。何かを編集する前に所有者を特定する方が、何かが動くまでルールを試すより速い。

管理機構とバックエンドを見つける

インストールされているものではなく、実際に読み込まれているものから始める。ディストリビューションはfirewalld、ufw、素のnftablesサービスを同梱でき、実行中のルールセットを所有するのはそのうち一つだけである。パッケージは平然と共存し、誤ったフロントエンドから入力したルールはカーネルに届かない。有効なサービスを読み、次にそれが生成したルールセットを読む。

バックエンドはフロントエンドと同じくらい重要である。firewalldの導入はバージョンと設定に応じてnftablesまたは旧iptablesバックエンドを動かし、両者は異なる検査出力を生む。システムをどの手順書と比べる前に、ディストリビューション、バージョン、バックエンドをチケットに書く。

方向とインターフェースを一致させる

クライアントの外向き要求、内向きの待ち受け、転送パケットはそれぞれ別のフックを通り、片方のルールは他方を覆わない。ローカルLANを許可するゾーンには、トンネルインターフェースやVPNアドレスプールが含まれないことが多い。トンネルインターフェースは通常デフォルトゾーンに着地し、そのゾーンは物理アダプターのゾーンより厳しいことがよくある。この不一致が、LANでは閲覧でき、トンネルが上がった瞬間に止まる理由である。

ルールを選ぶ前に、どちらの方向が失敗したかを尋ねる。外向きに接続できないアプリケーションには出力経路が必要であり、内向きのサービスにはトンネルインターフェース上の入力経路が必要である。誤ったチェーンにルールを足すと、適用されたように見えて何もしない変更が生まれる。

ルールの所有者の足並みをそろえる

VPNクライアントのフック、コンテナランタイム、ディストリビューションのサービスはいずれもネットワークを変更できるが、互いに調整しない。手入力したルールは次の再読み込みで消え、管理機構のチェーンに差し込んだルールは意図しない順序で評価されることがある。管理機構の永続設定を使い、書いたファイルではなく結果のルールセットを検査する。一つのサービスに届かないからといってファイアウォール全体を切るのは、小さな問題を大きな問題と交換することになる。

狭いカウンタは拒否されたフローを見つける安価な方法である。一つの宛先と一つのポートに限定したログ用ルールは、他の誰かの通信を捕捉せずに、破棄がローカルで起きているかを示す。調査が終わったらログ用ルールを外すのは、ポリシーではなく診断だからであり、firewalldのゾーンのドキュメントでは、インターフェースとサービスがどう組み合わされるかを説明している。

ロックダウンを失わずに修正を確認する

記録したバックエンドに合ったコマンドを使い、それを所有する管理機構で適用状態を検査する。以下の一覧はfirewalldが担当していると仮定しているが、すべてを実行するのではなく、nftablesやufwの相当するものに置き換える。一つのセッションでツールを混ぜると、マシンが相反する二つのルールセットを抱えることになる。

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

最初のコマンドはゾーンとそれに割り当てられたインターフェースを列挙し、トンネルが実際どこに着地したかを示す。二番目はあるゾーンのルールとサービスを出力するので、VPNインターフェースがそもそも覆われているかが分かる。nftablesの一覧は使用中のバックエンドの根拠であり、設定ファイルにしか存在しないルールはそこに現れない。三つの出力を追加したルールと比べれば、不一致はたいてい自ら名乗り出る。

次に元の要求と、必要とする失敗時の挙動を繰り返す。同じ変更でクライアントのロックダウンが外れたなら、新しく動くサイトだけでは足りないので、保護されていない経路も試す。管理機構、バックエンド、インターフェース、ルールの目的を記録するのは、二つ目の管理機構を復活させるパッケージ更新が、そうでなければ混乱全体を再構築してしまうからだ。

関連記事