RRAS DHCP：新しいアドレスか、それとも構成オプションだけか

キャプチャ内の DHCPACK を、VPN クライアントが DHCP からアドレスを受け取った証拠として読むのは誤りだ。通常それが証明するのは、何らかの DHCP メッセージに応答があったという一点にすぎない。Windows RRAS は自前の静的プールからセッションのアドレスを配ることができ、その間も DHCP は接続済みクライアントにオプションを供給している。どちらの仕事が起きていたのかは、要求の種類を見れば分かる。

同じメッセージ種別を共有する二つの仕事

DHCP は二つの別の仕事を担い、そのどちらも同じメッセージ種別を使う。一つはアドレスとリースの割り当てである。もう一つは、すでにアドレスを持つホストに構成を届けることで、RFC 2131 はこれを DHCPINFORM と呼ぶ。後者の応答はオプションを運び、リース時間は運ばない。

つまり ACK は応答の証拠であって、割り当ての証拠ではない。どの問いが立てられたかは、その直前のメッセージが決める。まず要求の行を読み、残りのトレースはたいてい自らを説明してくれる。

RRAS はどこからアドレスを得るのか

RRAS は構成済みの IPv4 割り当て方法、すなわち DHCP サーバーか静的アドレスプールのいずれかを通じて、VPN アドレスの決定を握っている。プールが静的であれば、割り当てを行うのはそのプールであり、別の DHCP サーバー上の予約はそのセッションでは何の決定権も持たない。二つの仕組みは、一方が他方を制御することなく同じネットワーク上で共存できる。

Get-Command -Module RemoteAccess *IPAddress*

アドレスを調べる前に、実際に効いている割り当て方法を確認する。静的プールであれば、DHCP スコープは見るべき場所ではない。上のコマンドは実行中のバージョンで利用できるコマンドレットを一覧にするので、設定を見つけるにはそれで足りる。

ユーザークラスが証明できることと、できないこと

DHCP のユーザークラスはクライアントが送る文字列であり、認証されたグループ所属ではない。クライアントがある文字列を送り、サーバーがそれに基づくポリシーを照合したとしても、そのラベルが証明するのは文字列が届いたことだけだ。RFC 3004 は、このオプションがクラスへの権利を認証するものではないと明言している。

VPN のユーザー名、セキュリティグループの識別子、あるいはノート PC の Ethernet アドレスが、その要求の中に使える形で現れるとは期待しないでほしい。これらは認証とディレクトリの事実であり、DHCP の要求はどちらも運ばない。要件が許可された人を区別することなら、身元が実際に存在する VPN ポリシー側で強制する。この分離こそが、二つの仕組みが独立したままである理由である。

ACK ではなく証拠を比べる

パケットを一つ読むのではなく、証拠の鎖を組み立てる。セッションが受け取ったアドレス、要求のメッセージ種別とフィールド、サーバーが返したオプション、そしてその後のクライアントの実効構成を記録する。各環はそれぞれ別の問いに答えており、欠けている環こそ本当の障害が居座る場所であることが多い。

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

アドレスが RRAS のプールから来たのであれば、DHCP の予約は何も説明しない。オプションが届いたのにクライアントが無視したのなら、サーバーは務めを果たしており、次の立ち寄り先はクライアントの構成である。この二つの結果を明示的に比べれば、ACK は曖昧ではなくなる。二つのトレース、すなわち割り当て方法ごとに一つずつあれば、どんな文書よりも速く決着がつく。