DirectAccessに特化した
最初の部分では、このソリューションの技術的基盤について検討し始めました。 この基盤は、IPv6、IPsec over IPv6、名前解決ポリシーテーブル（NRPT）で構成されていることを思い出させてください。 DirectAccessが基になるプロトコルとしてIPv6を使用する理由について説明しました。 これは、ロシアのインターネットを含むIPv4の明確な優位性の時代に、DirectAccessの使用が不可能になったことを意味していますか？ いや トランジットテクノロジーのおかげで、DirectAccessはIPv4環境で快適に使用できます。
IPv6トランジットテクノロジーDirectAccessを使用する場合、IPv6情報は、インターネット上のDAクライアントから境界ゾーンのDAサーバーを介して企業ネットワーク上の任意のサーバー（またはクライアント）に転送されます。 つまり、このような情報チャネルの3人の参加者全員がIPv6をサポートすると想定されています。 DAクライアントおよびDAサーバーの場合、IPv6サポートが厳密に必要です。 したがって、輸送技術は次の3つの状況で役立ちます。
-DAクライアントとDAサーバー間のインターネットセグメントがIPv6をサポートしない場合。
-DAサーバーとトラフィックの送信先サーバー間の企業ネットワークセグメントがIPv6をサポートしていない場合。
-宛先サーバー自体がIPv6をサポートしていない場合。
リストされた順序で3つのケースすべてを検討します。
DAクライアントとDAサーバー間のトランジットDAクライアントがインターネットに接続されると、DAサーバーとのIPv6トンネルを介したIPsecの確立を試みます。 このようなトンネルを直接構築する方法は、IPクライアントがインターネットプロバイダーから受け取る構成によって異なります。 理想的な、したがって、最も可能性の低いケースでは、DAクライアントはIPv6アドレスを受け取ります。 つまり、DAクライアントは幸運にもIPv6インターネット上にあり、そのパケットは単純にDAサーバーにルーティングされていました。
より現実的なオプションは、DAクライアントがプロバイダーからパブリックIPv4アドレスを受け取ることです。 この場合、クライアントは6to4トランジットテクノロジー（RFC 3056）を使用します。 このテクノロジーのおかげで、2002：WWXX：YYZZ :: / 48という形式のIPv6アドレスがクライアント上に作成され、2002年から始まり（プレフィックス2002は6to4トランジットテクノロジーがあることを示す）、WWXX：YYZZフィールドにパブリックIPv4アドレスを含みます（図1を参照）：
図 1
このようにして形成されたIPv6パケットは、IPv4パケットにパッケージ化され、IPv4インターネット経由でルーティングされます。
さらに現実的なオプションは、DAクライアントがプロバイダーからプライベートIPv4アドレス（192.168.200.111など）を受信することです。 この場合、別の輸送技術-Teredo（RFC 4380）が関係しています。 Teredoの目標は、ソースIPv6パケットがIPv4環境だけでなくNATも通過するようにすることです。 この点で、Teredoの動作原理は6to4よりもやや複雑であり、生成されるIPv6アドレスの構造は次の形式になります。
図 2
すべてのTeredoアドレスは2001プレフィックスで始まり、Obscured External PortフィールドとObscured External Addressフィールドには、それぞれNATが使用する外部UDPポートと外部IPアドレスが含まれています。 明示的にではなく、事前に定義された番号を使用したXOR操作の結果として含まれているもののみを明確にします。 生成されたパケットはUDPパケットにパッケージ化され、UDPパケットはIPv4パケットにパッケージ化されます。 これで、NATを介して情報を送信する準備がすべて整いました。 6to4およびTeredoトランジットテクノロジー、および後述のISATAPテクノロジーの詳細については、
こちらをご覧ください 。
DAクライアントがプロバイダーから特定のIPv4アドレスを受信する場合、別の非常に可能なオプションがありますが、同時に、外部世界との通信は80および443 TCPポートでのみ許可されます。 この場合、RFC標準ではなくなったプロトコルが役立ち、Windows 7およびWindows Server 2008 R2でのみサポートされます。 このプロトコルはIP-HTTPSと呼ばれ、その名前が示すように、HTTPS over IPv4を使用したIPv6パケットの転送を可能にします。 このプロトコルは、上記の中継技術の使用が成功しない場合にのみ使用されることを強調します。
そして最後に、ポート80のみが許可されている場合、サプライズ、DirectAccessは機能せず、外部の企業リソースへのアクセスは不可能になります。 誰が考えたでしょう。 :)
DAサーバーと宛先サーバー間のトランジットさて、IPv6パケットはDAサーバーに到達しました。 DAサーバーは、その設定に従って、IPv6パケットをさらに企業ネットワークにリダイレクトし、暗号化の有無にかかわらず宛先サーバーにリダイレクトします。 ここで疑問が生じます。組織のネットワーク環境はIPv6をサポートしていますか？ 具体的には、アクティブな通信機器（主にルーター）はIPv6で動作できますか？
宛先サーバーがIPv6をサポートしているが、通信機器をサポートしていない状況を考えます。 次に、ISATAP（サイト内自動トンネルアドレス指定プロトコル、RFC 4214）という別のトランジットテクノロジーが助けになります。 ISATAPを使用する場合、組織で受け入れられている任意の方法でホストに少なくとも1つのIPv4アドレスが割り当てられていると想定されます。 それ以外の場合、ホストが一般的にネットワーク上の他のマシンと対話する方法。 次に、ホストIPv6アドレスが自動的に生成され、IPv6アドレスの最後の32ビットがIPv4アドレスに対応します。 たとえば、異なるセグメントの2つのホストが相互作用を開始する場合、それらのアドレスは次のようになります（表1を参照）。
フィールド値
IPv6送信元アドレスFE80 :: 5EFE：10.40.1.29
IPv6宛先アドレスFE80 :: 5EFE：192.168.41.30
IPv4送信元アドレス10.40.1.29
IPv4宛先アドレス192.168.41.30
表1
したがって、DAサーバーがIPv4ルーターを介してIPv6パケットを送信する必要がある場合、DAサーバーはDNSを使用してこの情報に基づいて受信者のIPv4アドレスを見つけ、ISATAPタイプのIPv6パケットを生成し、通常のIPv4パケットにパックして受信者に転送します。 後者は情報を逆の順序でアンパックし、元のIPv6パケットを受信します。ヘッダーから、パケットは実際にこのホスト向けであり、さらに処理できることがわかります。
NAT-PT注意すべき最後のオプションは、宛先サーバーが原則として、IPv6での作業方法を知らない場合です。 ちなみに、Windowsについて話す場合、ファミリのオペレーティングシステムでのIPv6サポートはWindows XPから実装されていることに注意してください。たとえば、Windows 2000の場合はどうでしょうか。 そして、DirectAccessを使用して外部からこのようなマシンにアクセスしたいのです。 この場合、NAT-PT仕様（RFC 2766）をサポートするデバイスが必要です。 NAT-PTは、IPv6アドレスをIPv4アドレスに変換する役割を果たします。これにより、この場合のDAクライアントはIPv4のみのホストにアクセスできます。 NAT-PTは、Windows 7またはWindows Server 2008 R2ではサポートされていません。 ただし、このメカニズムのサポートは、Forefront Unified Access Gateway（UAG）製品に実装されています。 Windows Server 2008 R2にインストールされ、DAサーバーとして構成されたUAGは、NAT-PTなどの高度なDirectAccess機能を提供します。 UAGのレビューは、この議論の範囲外です。 さらに、NAT-PTの実装は、Microsoftを含め、他の製品にも見られます。
トランジットトピックを要約すると、管理者から、さらにはユーザーからも、これらすべてのテクノロジの特別な個別の構成は必要ないことに注意することが重要です。 DAサーバーをセットアップするときに、ウィザードでトランジットを構成するために必要なすべてのこと。 DAクライアントでは、6to4、Teredo、IP-HTTPS、ISATAPのサポートが自動的に有効になり、必要に応じて適用されます。
IPsec over IPv6IPsecは、DirectAccessソリューションの参加者間のトラフィックを保護するための基盤です。 IPバージョン4の場合、IPsec仕様はIPプロトコル自体よりもずっと後に登場しました。 これは、特に、IPsec over IPv4のさまざまな実装の出現につながり、時には相互に完全に互換性がありません。 IPsec for IPv6は、新しいIPプロトコルと同時に設計されました。 IPsecヘッダーのサポートは、IPv6スタックを実装するための前提条件です。 これにより、さまざまなサプライヤのソリューションの最大の互換性の前提条件が作成されました。 一方、これは、IPv6を使用するときにIPsecを使用する必要があるという意味ではありません。 しかし、IPv6に基づくDirectAccessの場合、IPsecの使用は、送信されるトラフィックを保護する最も論理的な方法です。
4番目のバージョンと同様に、IPv6のIPsecは、認証ヘッダー（AH）とカプセル化セキュリティペイロード（ESP）の2つのセキュリティオプションをサポートしています。 最初のバージョンでは、実際、各パケットはデジタル署名されており、これによりデータの認証が保証され、送信中の完全性が保証されます。 ただし、パケットデータは暗号化せずにクリアテキストで送信されます。 2番目のオプションとその他すべてでは、パケットデータも暗号化されるため、送信される情報の機密性が保証されます。 これらのオプションの組み合わせにより、DirectAccessを展開するときのいわゆるアクセスモデルが定義されます。
最初のモデルは、フルイントラネットアクセス（エンドツーエッジ）と呼ばれます。 このモデルでは、暗号化されたトラフィックは、IPsecを介してDAクライアントからDAサーバーに送信されます。 DAサーバーはトラフィックを解読し、パケットを平文で内部ネットワークに送信します。 実際には、これは、DAサーバーに到達した後、DAクライアントがさらに内部ネットワーク全体にアクセスする可能性があることを意味します。 ほとんどの場合、このロジックはVPNソリューションで使用されます。
選択されたサーバーアクセス（修正されたエンドツーエッジ）モデルでは、トラフィックは引き続きDAサーバーに対してのみ暗号化されます。 内部ネットワークでは、認証（AH）のみが使用されます。 このアプローチでは、特定のDAクライアントのみが企業ネットワーク上の特定のサーバーおよびアプリケーションにアクセスできます（図3を参照）。
図 3
Vista over IPsec over IPv6が完全に実装されていないOSでは、この図で、DAクライアントがこのモデルを介して到達できるサーバーはWindows Server 2008以降としてマークされていることに注意してください。
最後に、エンドツーエンドモデル（図4）では、パケットはDAクライアントで暗号化され、宛先サーバーで既に復号化されています。 DAサーバーは、単にこのトラフィックを自分自身で転送します。
図 4
このアプローチは、最高レベルの保護を提供します。
最終的に、特定のIPsec設定はグループポリシーで定義され、いつでも変更できます。 したがって、IPsec設定を操作することにより、特定の状況に最適なハイブリッドモデルを使用できます。 これは、DirectAccessベースのソリューションに追加された柔軟性です。
名前解決ポリシーテーブルDirectAccessの最後の技術的基盤は、名前解決ポリシーテーブル（NRPT）、またはこのテーブルとDNSシステムを使用して名前を解決する方法です。 DAクライアントがインターネット上にある場合、どの名前が内部であり、したがって、企業DNSサーバーによって解決され、どのクライアントがインターネット上のどのDNSサーバーを解決する必要があるかを理解する必要があります。
そのため、NRPTテーブルを使用すると、ネットワークインターフェイスではなく、一部の名前空間に対してDNSサーバーを設定できます。 企業ネットワークの外部にいるたびに、名前（srv1.contoso.comなど）を解決するとき、DAクライアントは最初にこの名前またはその一部のNRPTに行があるかどうかをチェックします。 存在する場合、この名前を解決するために、クライアントは、指定された名前空間の対応するNRPT行に示されているDNSサーバーに接続します（図5を参照）。 そうでない場合、コールはネットワークインターフェイス設定で指定されたDNSサーバー、つまりDNSプロバイダーで発生します。
図 5
さらに、いわゆる免除ポリシーがあります。 これらのポリシーで指定された名前は、常に外部インターネットDNSサーバーによってのみ解決されます。
ただし、このような「非標準」のNRPTを使用した名前解決の変形は、DAクライアントがインターネット上にあることを「理解」している場合にのみ適用されることを再度強調することが重要です。 それが内部グリッドにある場合、なぜそのような庭をフェンスで囲んでください。 したがって、DAクライアントの場所を決定するためのアルゴリズムがあります。 このアルゴリズム、およびインフラストラクチャ要件とDAサーバー自体の設定については、DirectAccessの3番目の最終投稿で説明します。