Windowsルーティングとリモートアクセスでリモートアクセス用にL2TPVPNサービスをセットアップするときに、接続しているクライアントでオプションを設定する際に奇妙な問題が発生しました。 DHCPを介してRRASのL2TPクライアントにこれらの設定を提供する方法( MS doc )-L2TPクライアントはDHCPInformパケットを送信し、DHCPオプション(DNS検索サフィックスのオプション15)からの設定を適用します、および分割トンネルルートのオプション121)。
Cisco ASAなどのほとんどのL2TPクライアントVPNエンドポイントでは、L2TPサービスはDNSとルーティング設定を構成してDHCP応答を作成しますが、RRASでは、RRASに組み込まれているDHCPリレー、またはローカルサブネット上のDHCPサーバーを使用しますが、これらのオプションはRADIUS属性やRRAS設定などではなく、DHCPで設定する必要があります(DHCPInformの動作とその必要性の詳細については、 このクレイジーなスレッド)に従ってください。 サーバー障害の常連のカップルの間)
Mac(またはiOS)クライアントは、新しく構成されたWindows Server 2016 VPNサーバーでこれらのオプションを正常に取得できず、代わりにVPNサーバーからDHCPを取得しようとする試みをタイムアウトすることがわかりました(/var/log/ppp.log
以降詳細ログをオンにする):
...
Fri Dec 1 12:09:18 2017 : sent [IP data <src addr 192.0.2.8> <dst addr 255.255.255.255> <BOOTP Request> <type INFORM> <client id 0x08000000010000> <parameters = 0x6 0x2c 0x2b 0x1 0xf9 0xf>]
Fri Dec 1 12:09:21 2017 : sent [IP data <src addr 192.0.2.8> <dst addr 255.255.255.255> <BOOTP Request> <type INFORM> <client id 0x08000000010000> <parameters = 0x6 0x2c 0x2b 0x1 0xf9 0xf>]
Fri Dec 1 12:09:24 2017 : No DHCP server replied
これが発生するときにRRASサーバーを監視すると、DHCPリレーはこれらのパケットを参照しているように見えますが、奇妙なことに、破棄されたものとして報告します(丸で囲んだ列の数字は両方ともクライアントが送信されているDHCP要求をログに記録するとすぐにインクリメントします):
RRASログノブを最大に上げた後、Windowsイベントログが破棄の理由を明らかにすることを期待しました( これらすべてのイベントのドキュメントが存在するため )が、これらのどれもイベントのログ記録が開始されました。最後に、RRASトレースログをオンにした後、C:\Windows\system32\tracing\IPBOOTP.LOG
は、MacのDHCPパケットが受け入れられなかった理由に関するヒントを最終的に提供しました。
[9712] 12:09:10: dropping REQUEST with secs-since-boot 0 on interface 42 (192.0.2.8)
RRAS DHCPリレーがその役割を果たし、これらのVPNクライアントのDHCPパケットをDHCPサーバーに送信しないのはなぜですか?
結局のところ、DHCPリレーエージェントのデフォルトは、一部のL2TPクライアントでは機能しません。
RRASでDHCPリレー用のインターフェイス(VPNクライアントが移動する「内部」インターフェイス上)を設定すると、デフォルトのオプションは次のようになります。
気取らないように見えますが、この問題全体の原因は「ブートしきい値」設定です。 documentation はとても役に立ちます!
DHCPメッセージを転送する前にリレーエージェントが待機する秒数。矢印をクリックして、新しい設定を選択することもできます。デフォルト値は4秒です。
このオプションは、ローカルDHCPサーバーが最初に応答するようにしたいが、ローカルDHCPサーバーが応答しない場合は、メッセージをリモートDHCPサーバーに転送する場合に役立ちます。
明らかに、そのオプションは、ネットワーク内で実際のDHCPリレーを実行している場合にのみ関係するように聞こえます。 VPNオプションにDHCPリレーを使用するための Microsoftのガイドの最も冗長な でさえ、ブートしきい値設定に注意を払う必要があることに言及していません。
しかし、ログは嘘をつきません、そしてdropping REQUEST with secs-since-boot 0
DHCPリレーエージェント自体に障害があることを明確に示しているように見えました。そのエラーは私にLichtensteinの親切な管理者からの ブログ投稿 を指摘しました、そしてそれは最終的に私に何が起こっているかを示しました。
「ブートしきい値」DHCPリレーオプションは、ドキュメントが示すように遅延ではありません-これはハードパケットフィルターであり、すべてのDHCPパケットをしきい値。これを0より大きい値に設定すると、VPNクライアント(「内部」インターフェイス上)にDHCPリレーを使用する場合は意味がなく、ドキュメント。
DHCPリレーの起動しきい値を0に設定した後、Mac L2TPクライアントはDHCPオプション15(DNSサフィックス)および121(分割トンネルルート)から設定を正常に取得します。