私のセットアップには、別のインスタンス上のAzure SQL DatabaseV12サーバーに接続されたServer2012を実行しているMicrosoftAzure VMインスタンスが含まれます。
サーバーにSSTPVPNを設定しましたが、機能します。それに接続するクライアントは、サーバーゲートウェイを使用しません。これは、その目的がネットワーク共有をホストすることであり、トラフィックをプロキシすることではないためです。データベースサーバーは、VPNサーバー以外からの接続を拒否するように設定されています。
VPNを介してデータベースにアクセスできるようにしたいのですが、VPNサーバーからデータベースへのトラフィックのルーティングに問題があります。具体的には、_192.168.26.1
_でデータベースにアクセスできるようにします。ポート1433を開き、TCPポートフォワードを追加しました:
_netsh add v4tov4 listenaddress=192.168.26.1 listenport=1433 connectaddress=<database hostname> connectport=1433
_
クライアントマシンで_192.168.26.1
_を介してデータベースに接続しようとすると、VPNサーバーのnetstat
に次のように表示されます。
_> netstat -an | findstr 1433
TCP 10.0.0.4:51056 <database ip>:1433 TIME_WAIT
TCP 192.168.26.1:1433 0.0.0.0:0 LISTENING
_
同様に、クライアント(Windows 10マシン)のnetstat
は、_192.168.26.1:1433
_への簡単な接続を示しています。
このことから、データベースへの接続はがVPNを介して行われていると思われますが、_192.168.26.1
_プロキシを介してデータベースに接続しようとすると、SSMSは言います:
クライアントのIPアドレスはサーバーにアクセスできません。 Azureアカウントにサインインし、新しいファイアウォールルールを作成してアクセスを有効にします。
指示に従うと、AzureはクライアントIPを許可されたファイアウォールルールに追加したいと思うようになります。しかし、VPNを介して接続するべきではありませんか? netstat
はそう言っているようですが、なぜクライアントIPを追加するように求められるのですか?
SQL資格情報には、サーバー名として_192.168.26.1
_を使用し、ログインとして_<username>@<database hostname>
_を使用します。これは、VPNサーバー上のリモートデスクトップ接続から機能します。
どうしたの?
V12より前のAzureSQL Databaseは、ゲートウェイマシンを使用して、クライアントとデータベース間の接続をプロキシしていました。 V12以降、ゲートウェイは最初の接続のみをプロキシし、クライアントとデータベースの間にピアツーピア接続を確立します。このリダイレクトの詳細については、 ここ を参照してください。
ピアツーピア接続はプロキシの外部で確立され、ファイアウォールに到達するため、この動作は接続のポート転送ではうまく機能しません。ありがたいことに、Powershellに依存していますが、 オフにすることができます 。
クライアントのIPアドレスはサーバーにアクセスできません。 Azureアカウントにサインインし、新しいファイアウォールルールを作成してアクセスを有効にします。
VPNサーバーのパブリックIPアドレスがAzureSQLデータベースにアクセスできるようにする必要があります。プライベートIPアドレスを許可することはできません。
Netstatの出力によると、VPNサーバーには2つのNICがあり、AzureSQLデータベースに接続するパブリックアドレスを許可する必要があります。