次の方法で共有

Virtual WAN で Private Link を使用する

  • [アーティクル]

Azure Private Link は、プライベート エンドポイントを公開することで、プライベート IP アドレスの接続を使用して Azure のサービスとしてのプラットフォームのオファリングを接続できるテクノロジです。 Azure Virtual WAN では、任意の仮想ハブに接続された仮想ネットワークの 1 つにプライベート エンドポイントをデプロイできます。 このプライベート リンクにより、同じ Virtual WAN に接続されている他の仮想ネットワークまたはブランチに接続できます。

開始する前に

この記事の手順では、1 つ以上のハブがある Virtual WAN がデプロイされ、Virtual WAN に少なくとも 2 つの仮想ネットワークが接続されていること想定しています。

新しい仮想 WAN と新しいハブを作成するには、次の記事の手順に従います。

Azure のプライベート エンドポイント接続はステートフルです。 プライベート エンドポイントへの接続が Virtual WAN 経由で確立されると、トラフィックはさまざまな Virtual WAN コンポーネント (仮想ハブ ルーター、ExpressRoute ゲートウェイ、VPN Gateway、Azure Firewall、NVA など) を経由する 1 つ以上のトラフィック ホップを介してルーティングされます。 トラフィックに対する正確なホップは、Virtual WAN ルーティング構成に基づきます。 バックグラウンドでは、Azure のソフトウェアによるネットワーク制御レイヤーが、1 つの 5 タプル フローに関連するすべてのパケットを、さまざまな Virtual WAN コンポーネントにサービスを提供するいずれかのバックエンド インスタンスに送信します。 非対称的にルーティングされたトラフィック (たとえば、異なるバックエンド インスタンスにルーティングされた 1 つの 5 タプル フローに対応するトラフィック) はサポートされておらず、Azure プラットフォームによって破棄されます。

Virtual WAN インフラストラクチャのメンテナンス イベント中、バックエンド インスタンスは 1 つずつ再起動されます。これにより、フローを処理するインスタンスが一時的に使用できなくなるため、プライベート エンドポイントに対する断続的な接続の問題が発生する可能性があります。 Azure Firewall または仮想ハブ ルーターがスケールアウトする際にも同様の問題が発生する可能性があります。同じトラフィック フローを、現在フローを処理しているインスタンスとは異なる新しいバックエンド インスタンスに負荷分散できます。

Private Link またはプライベート エンドポイント トラフィックに対するメンテナンスおよびスケールアウト イベントの影響を軽減するには、次のベスト プラクティスを検討してください。

  • オンプレミス アプリケーションの TCP タイムアウト値を 15 から 30 秒の間で構成します。 TCP タイムアウト値を小さくすると、アプリケーション トラフィックはメンテナンスおよびスケールアウト イベントからより迅速に回復できるようになります。 または、さまざまなアプリケーション タイムアウト値をテストして、要件に基づいて適切なタイムアウトを決定します。
  • Virtual WAN コンポーネントを事前にスケーリングしてトラフィック バーストを処理し、自動スケーリング イベントが発生しないようにします。 仮想ハブ ルーターの場合、ハブ ルーターに最小ルーティング インフラストラクチャ ユニットを設定することで、トラフィック バースト時にスケーリングが発生しないようにできます。

最後に、VPN または ExpressRoute を使用して Azure とオンプレミス間のオンプレミス接続を使用している場合は、オンプレミス デバイスが、プライベート エンドポイント トラフィックに対応する 5 タプルごとに、次ホップと同じ VPN トンネルまたは同じ Microsoft Enterprise Edge ルーターを使用するように構成されていることを確認します。

プライベート リンク エンドポイントを作成する

プライベート リンク エンドポイントは、さまざまなサービスに対して作成できます。 この例では、Azure SQL Database を使用します。 Azure SQL Database のプライベート エンドポイントを作成する方法の詳細については、「クイックスタート:Azure portal を使用してプライベート エンドポイントを作成する」を参照してください。 次の図は、Azure SQL Database のネットワーク構成を示しています。

プライベート リンクの作成

Azure SQL Database を作成した後、プライベート エンドポイントを参照してプライベート エンドポイントの IP アドレスを確認することができます。

プライベート エンドポイント

作成したプライベート エンドポイントをクリックすると、そのプライベート IP アドレスと、その完全修飾ドメイン名 (FQDN) が表示されます。 プライベート エンドポイントの IP アドレスは、VNet の範囲内 (10.1.3.0/24) にあるはずです。

SQL エンドポイント

同じ VNet からの接続を確認する

この例では、MS SQL ツールがインストールされている Linux 仮想マシンから Azure SQL Database への接続性を検証します。 最初の手順では、DNS 解決が機能することと、Azure SQL Database の完全修飾ドメイン名が、プライベート エンドポイントのデプロイ先と同じ VNet 内のプライベート IP アドレス (10.1.3.0/24) に解決されていることを確認します。

nslookup wantest.database.windows.net

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
wantest.database.windows.net    canonical name = wantest.privatelink.database.windows.net.
Name:   wantest.privatelink.database.windows.net
Address: 10.1.3.228

前の出力でわかるように、FQDN wantest.database.windows.net は wantest.privatelink.database.windows.net にマップされ、プライベート エンドポイントと共に作成されたプライベート DNS ゾーンは、プライベート IP アドレス 10.1.3.228 に解決されます。 プライベート DNS ゾーンを見ていくと、プライベート IP アドレスにマップされたプライベート エンドポイントに A レコードがあることが確認できます。

DNS ゾーン

正しい DNS 解決を確認した後、データベースへの接続を試みることができます。

query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"

10.1.3.75

ご覧のとおり、ここでは SQL Server によってクライアントから認識される発信元 IP アドレスを返す特別な SQL クエリを使用しています。 この場合、サーバーでは、クライアントはそのプライベート IP (10.1.3.75) で認識されます。つまり、トラフィックは VNet からプライベート エンドポイントに直行します。

このガイドの例を使用するには、Azure SQL Database で定義されている資格情報と一致するように username と password の変数を設定します。

別の VNet からの接続

Azure Virtual WAN 内の 1 つの VNet がプライベート エンドポイントに接続できるようになったので、Virtual WAN に接続されている他のすべての Vnet とブランチも、それにアクセスできるようになりました。 Azure Virtual WAN でサポートされているモデルのいずれかを介して接続性を提供する必要があります。例としては、Any-to-any シナリオや Shared Services VNet シナリオなどの 2 つがあります。

VNet またはブランチからプライベート エンドポイントがデプロイされている VNet への接続が完了したら、DNS 解決を構成する必要があります。

  • VNet からプライベート エンドポイントに接続する場合は、Azure SQL Database で作成したプライベート ゾーンと同じものを使用できます。
  • ブランチ (サイト間 VPN、ポイント対サイト VPN、または ExpressRoute) からプライベート エンドポイントに接続する場合は、オンプレミスの DNS 解決を使用する必要があります。

この例では、別の VNet から接続しています。 まず、プライベート DNS ゾーンを新しい VNet に接続して、そのワークロードで Azure SQL Database の完全修飾ドメイン名をプライベート IP アドレスに解決できるようにします。 これを行うには、次のようにプライベート DNS ゾーンを新しい VNet にリンクします。

DNS リンク

これで、接続された VNet 内の仮想マシンは、Azure SQL Database の FQDN をプライベート リンクのプライベート IP アドレスに正しく解決されるはずです。

nslookup wantest.database.windows.net

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
wantest.database.windows.net    canonical name = wantest.privatelink.database.windows.net.
Name:   wantest.privatelink.database.windows.net
Address: 10.1.3.228

この VNet (10.1.1.0/24) が、プライベート エンドポイントが構成されている元の VNet (10.1.3.0/24) に接続していることを再確認するには、VNet 内の任意の仮想マシンで有効なルート テーブルを確認します。

有効なルート

ご覧のように、Azure Virtual WAN の Virtual Network ゲートウェイによって挿入された VNet 10.1.3.0/24 をポイントするルートがあります。 これで、ようやくデータベースへの接続をテストできるようになりました。

query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"

10.1.1.75

この例では、Virtual WAN に接続されているいずれかの Vnet にプライベート エンドポイントを作成することで、Virtual WAN 内の残りの Vnet とブランチに接続できることを見てきました。

次のステップ

Virtual WAN の詳細については、FAQ を参照してください。