ホットスポットのファイアウォールがリース前に DHCP を遮断する

新しいスマートフォンがホットスポットに接続しても、アドレスが表示されず、いつまでも取得できません。アクセスポイントは正常で、DHCP デーモンも動作しており、書いたファイアウォールルールはアドレス計画と整合しているように見えます。しかし実際にそのルールが要求しているのは、クライアントが自分で要求しているアドレスをすでに持っていることです。最初の DHCP パケットにはアドレスがまったくないため、ルールは決して発動しません。

クライアントの接続を観察する

クライアント側から 一つの関連付けを追います。無線が関連付けを行い、クライアントが DHCP ディスカバリを送り、サーバーがオファーを返し、クライアントがリクエストを送り、サーバーが確認応答を返し、その後に初めてクライアントは他の用途に使えるアドレスを持ちます。

その最終確認より前のすべては、クライアントが通常の通信にゲートウェイを使えない間に起こります。サブネットのルールが忘れているのは、まさにこの時間帯です。

最初のパケットに実際に含まれるもの

RFC 2131 は、アドレスを取得する前のクライアントの DHCP ブロードキャストが送信元アドレスをゼロにすると定めています。クライアントからサーバーへのメッセージは UDP ポート 67 に、サーバーからクライアントへのメッセージは UDP ポート 68 に送られます。したがってディスカバリは 0.0.0.0 を送信元として届き、クライアントサブネット内の送信元を要求するルールとは単純に一致しません。

これはクライアント側の設定ミスではありません。プロトコルが設計どおりに動作しているのであり、それが可能な唯一の時間帯でそうなっているのです。

実際に処理するのはどの経路か

アクセスポイント自身がリースを配る場合、これはローカルなサービスのやり取りであり、IP でフィルタするローカル経路では入力と出力のポリシーに関わります。VPN を通して転送されるクライアント通信は別の判断であり、その通信の NAT はさらに別です。この三つを混同することが、狭い例外を広い例外に変える道です。

パケットがどこで処理されるかは、デーモンと使用しているファイアウォールの系統によって変わります。生ソケットの実装、ブリッジ構成、より前段のフィルタフックでは、まったく別の場所で移動させたり遮断したりすることがあります。ルールを追加する前に、デーモンのインターフェース結合と有効なフックを確認してください。

フォーラムからコピーした一般的な入力・出力のレシピは、あなたの実装が同じようにそれらのチェーンを通る証拠にはなりません。

応答は常にブロードキャストとは限らない

ブロードキャスト応答だけを許可する例外も誤りです。DHCP 応答の宛先はクライアントの状態とメッセージのフィールドに依存し、プロトコルはブロードキャストとユニキャストの両方の場合を定めています。サーバーがこれから割り当てるアドレスへユニキャストで応答する場合、ブロードキャスト限定のルールは作業を完了させる手順を遮断します。設定されたサーバーが実際に行うやり取りに合わせてルールを書いてください。

後日のリース更新は別の状態で同じやり取りを繰り返すので、最初の接続だけでなく更新のための余地も残してください。

狭く修正し、その後に残りを確認する

既存のポリシーはそのままにし、欠けている DHCP の許可を見つけて、クライアント側インターフェース、プロトコル、二つのポートに限定します。要求がサービスに届くことを証明し、次にサービスが応答することを証明します。これは二つの別の観察であり、完全なフィルタリングの背後でサービスやプールの設定が誤っていることもあります。

テーブルをフラッシュすることは DHCP の設定手順ではありません。iptables では flush は選択したチェーンやテーブルからルールを削除し、NAT テーブルをフラッシュしても変換ルールは作成されません。広い ACCEPT ポリシーを設定するとリースとは無関係な保護が失われるため、どちらも再利用可能なホットスポットの修正には含まれません。

クライアントがリースを保持したら、DNS、転送、VPN の出口を別々の作業として確認します。リースが確立するのはローカルのアドレス指定だけで、それ以上ではありません。