プロキシの使用を強制すべきLinuxのパケット経路はどれか
ネットワークプロキシの強制制御は、統制すべきパケット経路に置くべきであり、ゲートウェイへの接続だけをフィルタリングしてはならない。
Linuxゲートウェイはプロキシプロセスを実行しつつ、その脇を通る通信もルーティングできる。両者は同じパケット経路ではない。
| 接続 | 関連するローカルな役割 |
|---|---|
| クライアントがゲートウェイ上のプロキシに到達する | ローカルホスト宛ての通信 |
| クライアントがゲートウェイ経由で別のホストに到達する | 転送される通信 |
| プロキシがウェブサイトへの接続を開く | ローカルプロセスが生成する通信 |
Netfilterは入力・転送・出力の経路を区別する。ゲートウェイ自身のプロキシリスナーへのアクセスを統制するルールは、そのマシンを通るすべてのルーティング接続を自動的に制限するものではない。
何を強制するかを定義する
クライアントが承認済みプロキシを使わなければならないなら、ポリシーは意図したリスナーを許可するだけでなく、代替の外向き経路にも対処する必要がある。なじみのあるプロキシポートを使うという理由だけで任意のリモートサービスへの接続を許可することは、自分のプロキシエンドポイントだけを許可することと同じではない。
プロキシ自身の外向きアクセスは別に保つ。Squidの場合、外向き許可を適用する前にローカルソケットの所有権とLANユーザー識別を区別する。プロキシからの有用な外向き接続をすべて拒否すると、必要な経路が利用できなくなる。管理通信、名前解決、対応する非ウェブ操作も、展開ポリシーで意図的な扱いを必要とする。
プロトコルの範囲が重要である。TCPルールはQUICを含むUDP通信をそれ自体では記述しない。通信の傍受はまた別の設計であり、明示的なHTTPSプロキシはウェブサイトのセッションを復号せずにCONNECTを提供できる。
ルールセットを編集する前に、意図する接続を整理する。ブラウザの設定は参加するクライアントの経路を選ぶ。ネットワーク側の強制は、どの別経路が成功し得るかを決める。どちらもプロキシへのログイン成功だけから推測すべきではない。