web-dev-qa-db-ja.com

IPv6 AAAAレコードに関連する遅延を防ぐ方法は？

Windowsサーバーは、IPv6 AAAAレコードをWindows DNSサーバーに登録しています。ただし、ネットワークでIPv6ルーティングを有効にしていないため、これによりストール動作が頻繁に発生します。

Microsoft RDPは最悪の犯罪者です。 DNSにAAAAレコードがあるサーバーに接続する場合、リモートデスクトップクライアントは最初にIPv6を試し、接続がタイムアウトするまでIPv4にフォールバックしません。パワーユーザーは、IPアドレスに直接接続することでこれを回避できます。 ping -4 hostname.fooを使用したIPv4アドレスの解決は、常に即座に機能します。

この遅延を回避するにはどうすればよいですか？

  • クライアントでIPv6を無効にしますか？
  • サーバーでIPv6を無効にしますか？
  • ユーザーファクシミリDNSリカーサでIPv6レコードをマスクしますか？
  • Microsoft DNSサーバーでのIPv6 AAAAレコードの登録を禁止しますか？
    • それは不可能だと思います。

この時点で、DNSゾーンからすべてのAAAAレコードを削除するスクリプトを作成することを検討しています。より良い方法を見つけるのを手伝ってください。

UPDATE：DNS解決は問題ではない問題です。 @joeqwertyが彼の回答で指摘しているように、DNSレコードは即座に返されます。 AとAAAAの両方のレコードをすぐに利用できます。問題は、一部のクライアント（mstsc.exe）がIPv6を介して優先的に接続を試み、IPv4にフォールバックするのにしばらく時間がかかることです。

これはルーティングの問題のようです。 pingコマンドは、宛先アドレスがルーティングできないため、「一般的なエラー」エラーメッセージを生成します。

C:\Windows\system32>ping myhost.mydomain
Pinging myhost.mydomain [2002:1234:1234::1234:1234] with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.
Ping statistics for 2002:1234:1234::1234:1234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

この動作のパケットキャプチャを取得できません。この（失敗した）pingコマンドを実行しても、Microsoftネットワークモニターにパケットは生成されません。同様に、AAAAレコードを持つホストにmstsc.exeを使用して接続しようとすると、IPv4にフォールバックするまでトラフィックは発生しません。

UPDATE：ホストはすべて、パブリックにルーティング可能なIPv4アドレスを使用しています。この問題は、壊れた6to4構成に起因する可能性があると思います。 6to4は、パブリックIPアドレスとRFC1918アドレスを持つホストで異なる動作をします。

UPDATE：私のネットワークには、6to4で何か怪しいものがあります。 Windowsクライアントで6to4を無効にすると、接続が即座に解決されます。

netsh int ipv6 6to4 set state disabled

しかし、@ joeqwertyが言うように、これは問題を隠すだけです。私のネットワーク上のIPv6通信が完全に機能しない理由を見つけようとしています。

domain-name-systemwindows-server-2008-r2ipv6
11
Nic

6to4と呼ばれるIPv6移行テクノロジは、このような問題を引き起こす 悪名高い です。いくつかの要因が働いています。個々に害はありませんが、組み合わせた効果により、エンドユーザーは接続の遅延を経験することができます。

可能にする要因とその軽減に関する考えのリストを以下に示します。

Windowsはデフォルトで6to4を有効にします

ホストがWindowsの最新バージョン（Vista以降）を実行している場合、パブリックにルーティング可能なIPv4アドレスが利用可能になると、Windowsは日和見的に6to4トンネリングを有効にします。これは、サーバーとクライアントの両方に当てはまります。

システムが6to4を使用しているかどうかを確認するには、ipconfigを実行し、6to4プレフィックス2002:で始まるIPv6アドレスを探します。こんな感じになります。

C:\> ipconfig
Tunnel adapter 6TO4 Adapter:
IPv6 Address. . . . . . . . . . . : 2002:1111:2222::1111:2222
  • エンドポイントがActive Directoryに接続されている場合は、グループポリシーを使用して、6to4やTeredoなどの移行プロトコルを無効にすることができます。これは KB929852 で十分に文書化されています。 （これをクライアントまたはサーバーに適用するだけで十分ですが、この手順を実行している場合は、両方のクライアントおよびサーバー。）
  • 少数のホストしか管理していない場合は、ケースバイケースで6to4を無効にできます。これは、IPv6を完全に無効にするよりもはるかに優れています。 netsh int ipv6 6to4 set state disabled
  • 別のクライアントオペレーティングシステムを使用します。たとえば、Mac OS Xではデフォルトで6to4が有効になっていません。

公的にルーティング可能なIPv4アドレスが使用されている

6to4は、パブリックにルーティング可能なIPv4アドレスを持つホストでのみ機能するため、この問題がNATファイアウォールの背後にあるホストに影響を与えることはありません。

  • クライアントやサーバーをNATファイアウォールの背後に移動して、RFC1918アドレス指定の使用を開始できます。ただし、場合によっては、公開ルーティング可能なアドレスが実際に優先されます。ネットワーク全体のアドレス指定を変更することも、非現実的な選択。

6to4がネットワーク上で正しく機能していない

エニーキャストモードで6to4をトラブルシューティングすることは悪名高いほど困難です。 IETFに正式な要求があったため、 6to4を履歴として再分類する必要があります であるのは非常に厄介です。この著者の意見では、6to4は推奨されていません。

簡単に言うと、6to4は、6in4と呼ばれるプロトコル（IPプロトコル= 41）を使用してIPv6パケットをIPv4パケットにカプセル化することで機能します。 IPv4パケットは、インターネット上のどこかで動作している6to4リレーに到達することを期待して、エニーキャストアドレス192.88.99.1に送信されます。運が良ければ、地理的に近いかもしれません。

実際には、一部の6to4リレーが正しく設定されておらず、多くのネットワークでは6in4トラフィックがファイアウォールを通過することさえできません。通常、これはファイアウォールがすべての送信トラフィックを許可しているが、IPプロトコル41パケットがファイアウォールを通過することを明示的に許可していない場合に発生します。 （トラブルシューティングのための関連するRFCに注意してください。）この障害（「インバウンドブラックホール」）やその他の多くは RFC 634 で説明されています。

  • ネットワーク内部のホストから送信されたときにIPプロトコル41（TCPリセット）を伴う）を大声で拒否するようにファイアウォールを設定します。これにより、「フェイルファスト」動作が発生し、これは 制限されたテスト環境で機能することが示されています です。
  • ISPまたはファーストホップトランジットプロバイダーに、動作する6to4リレーを設定するよう依頼してください。これが正しく行われると、エンドユーザーに最高のエクスペリエンスを提供します。パブリックにルーティング可能なIPv4アドレスを持つエンドユーザーは、IPv6インターネットに参加できます。

動的DNS登録

典型的なActive Directory環境では、すべてのコンピューターが自身のアドレスをDNSサーバーに登録することが許可されています。ホストがマルチホームの場合、6to4トンネルからでも、すべてのアドレスが登録されます。

ほとんどのインターネットサービスは動的DNSを使用しないため、この問題は通常、クライアントとサーバーがすべて同じネットワークの「内部」にある企業サイトに限定されます。

  • 動的DNS更新を無効にすることを選択できます。次に、AAAAリソースレコードをゾーンファイルに配置しない場合、それらは提供されません。ただし、動的DNSは多くの場合、内部DNSサーバーに適しています。 （これを行う場合は、すでに存在している可能性のあるAAAAレコードも必ず削除してください。）
  • AAAAリソースレコードに対する回答を提供しないようにDNSサーバーを設定します。ただし、IPv6の実装を開始するときに本当に問題が発生するため、これは行わないでください。 （誰かがフリー/オープンソースのDNSファイアウォールを知っていますか？）

クライアントアプリケーションが正常に失敗しない

MicrosoftのRDPクライアントは、IPv6ルーティングの問題を適切に処理しないクライアントアプリケーションの一例です。ほとんどのWebブラウザーは、このようなIPv6エッジケースの処理に優れているため、この動作を示す傾向はありません。

  • 別のクライアントを使用してみてください。多分あなたは幸運になるでしょう。
9
Nic

この質問はかなり興味深いものであり、私はこの振る舞いを見たことがないことを認めざるを得ません。それをよりよく理解するためにいじくり回して、別のW2K8R2サーバーから自分のW2K8R2 RDSサーバーの1つをクエリするnslookupのスニペットを取り、同じテストサーバーから同じRDSサーバーへのRDPセッションのスニペットもキャプチャしました。 NslookupはIPv6レコードを返す際に遅延を示さず、nslookupはテストサーバーがIPv6レコードを照会する前にIPv4レコードを照会することを示しました。キャプチャの時間差は、どちらのクエリでも（私が確認できる）目に見える遅延はありません。

enter image description here

enter image description here

[〜＃〜]編集[〜＃〜]

今、あなたは何かに行きます。

Microsoft 6To4アダプタのトラフィックをキャプチャしていることを確認してください。キャプチャしていない場合、IPv6は表示されません。

enter image description here

これが、RDSサーバーのnslookupの結果です。 IPv6アドレスを書き留めます。

enter image description here

これが私のキャプチャのスニペットです：

enter image description here

最後に、接続を示すnetstatのスニペットを次に示します。

enter image description here

明らかに、あなたが確認したように、DNS解決は問題ではありません。問題は、RDP接続がIPv4よりもIPv6を優先することです（これはWindowsのデフォルトです-WindowsはIPv4よりもIPv6を優先します）。IPv6が適切に機能していないため、IPv6からフォールバックするときに（前述のように）遅延が発生しています。 IPv4。 IPv6よりもIPv4を優先するようにクライアントを構成することでこれを修正できますが、それは単に問題を隠すだけだと思います。より良い解決策は、IPv6が機能していない理由を突き止め、それを修正することです。私はIPv6について十分な知識がありませんが、DNSから返されるIPv6レコードは、RDSホストが存在するサブネットでのみ有効な「ローカル」アドレスであり、クライアントが別のサブネットにあるため、 tそれらのIPv6アドレスに到達します。

10
joeqwerty

この状況ではあまり役に立ちませんが、同様のジレンマに直面している実装者には、ipv4およびipv6への接続手法を指定する "Happy Eyeballs" （RFC 6555）と呼ばれる実装手法があります。同時に、最初に接続する方を選択します。

2
joe miller

ここに私の解決策がありました。デフォルトでは、WindowsはIPv6ルートにIPv4ルートより高い優先順位を与えます。 IPv6プレフィックスポリシーを編集する場合、この動作を変更して、IPv6ではなくIPv4を使用するようにできます。

ネットワーク内のすべてのシステムが同じようにセットアップされていることを確認するために、マシンの構築または改造後のソフトウェアのインストール中に実行される.batスクリプトに次のコマンドを入れました。

netsh int ipv6 isatap set state disabled
netsh int ipv6 6to4 set state disabled
netsh interface Teredo set state disable

netsh interface ipv6 delete prefixpolicy ::1/128
netsh interface ipv6 delete prefixpolicy ::/0
netsh interface ipv6 delete prefixpolicy 2002::/16
netsh interface ipv6 delete prefixpolicy ::/96
netsh interface ipv6 delete prefixpolicy ::ffff:0:0/96
netsh interface ipv6 delete prefixpolicy 2001::/32

netsh interface ipv6 add prefixpolicy ::1/128 50 0
netsh interface ipv6 add prefixpolicy ::ffff:0:0/96 40 1
netsh interface ipv6 add prefixpolicy ::/0 30 2
netsh interface ipv6 add prefixpolicy 2002::/16 20 3
netsh interface ipv6 add prefixpolicy ::/96 10 4
netsh interface ipv6 add prefixpolicy 2001::/32 5 5

これが何をするかを説明するには：

最初の3行は、組み込みのトンネリングインターフェイスを無効にします。これらのインターフェイスはほとんどのネットワークで冗長であるためです。マシンに独自のIPv6アドレスを与えない場合は、これらの3行を使用しないほうがよいでしょう。私の場合、DHCPv6サーバーと、トンネル接続にIPv6を割り当てる関連インフラストラクチャがあります。

コマンドの2番目のブロックは、既存のIPv6ルーティングプレフィックスポリシーをすべて削除します。

3番目のブロックは、IPv6プレフィックスポリシーを再作成しますが、優先順位の異なるセットを使用します。同様に、IPv4に対応するプレフィックスはIPv6よりも優先され、アプリケーションがIPv6の使用を指定しない限り、マシンはIPv4を使用することになります。

このソリューションは機能的なデュアルスタック機能を保持しますが、IPv4を使用することを優先すると、システム上のプログラムから指示されない限り、IPv6が不完全、信頼性が低い、またはパフォーマンスが低いサイトでは、IPv6の使用が避けられます。

私の意見では、オペレーティングシステムにIPv4よりもIPv6を使用させると、実際には採用が妨げられます。移行期間中、ホストがIPv6接続を持っているとホストが判断したが、実際には完全に機能する接続がなく、ソフトウェアの誤動作と大きな遅延が発生する場合があります。私が知っている多くの人々は、完全な接続を確立する前に、最初に壊れた方法でIPv6を展開するISPの回避策として、ルーターでIPv6を完全に無効にしました。これらの人々は、ルーターを再構成するまで、IPv6なしでそのままにしておくことを忘れるだけです。

0
OdinYggd