サービスエンドポイントを介してSQLデータベースに接続するためのプロキシとして機能するようにAzure VMを構成するにはどうすればよいですか？

Question

現在、Azureでは、VPNゲートウェイを介したサービスエンドポイントを介したSQLデータベースへのアクセスは許可されていません。この制限を回避するための私のアイデアは、Azure VMをプロキシとして機能するように設定して、SQLデータベースとのすべての通信がこのインスタンスを介して行われるようにすることです（SQLデータベースとの間のトラフィックはこのインスタンスを介して行われます。サービスエンドポイントを介してルーティングされます）。ただし、このソリューションを機能させることができず、ガイダンスを使用できます。

私の設定：

Azure環境へのVPN接続が確立されたAWS環境をセットアップしています。 Route53を使用してプライベートホストゾーンを設定し、SQLデータベースのドメイン名を対応するMicrosoft.SqlリージョナルエンドポイントのパブリックIPアドレスに解決します（これは、SQLデータベースのドメイン名がアクセス時に解決されるIPアドレスです。プロキシVMからのSQLデータベース）。ルートテーブルは、仮想プライベートゲートウェイを介してこのIPアドレスにトラフィックを転送するように構成されています。

Azure側では、ゲートウェイサブネットのルートテーブルを構成して、Microsoft.SqlリージョナルエンドポイントパブリックIPアドレス宛てのトラフィックをプロキシVM仮想アプライアンスであるかのように転送します。プロキシのネットワークインターフェイスVMは、IP転送を許可するように設定されています。プロキシのサブネットに接続されたルートテーブルVMは、宛先のトラフィックをルーティングするように構成されていますAWSVPCのプライベートCIDRがVPNゲートウェイを介して戻ってきます。

簡単にするために、AWS環境とAzure環境の両方のセキュリティグループは、両方の環境のプライベートIPアドレスとMicrosoft.SqlリージョナルエンドポイントパブリックIPアドレスの間のすべてのインバウンドおよびアウトバウンドトラフィックを許可するように設定されています。

現在機能しているもの：

AWS VPCのEC2インスタンスは、プライベートIPアドレスを使用してVPN経由でプロキシVMにpingおよびsshできます。プロキシVMはSQLデータベースにアクセスできますプライベートIPアドレスを使用してサービスエンドポイントを介して。

機能しないもの：

Microsoft.SqlリージョナルパブリックIPアドレス（プロキシに転送するように設定したアドレス）に接続しようとして、EC2インスタンスからプロキシVMに正常にpingまたはsshできませんVM）またはSQLデータベースのドメイン名（Route53でMicrosoft.SqlリージョナルパブリックIPアドレス用に設定したレコード）。プロキシVMでパケットキャプチャを実行すると、EC2インスタンスからのインバウンドトラフィックが表示されません。トラフィックは、VPCフローログで受け入れられたとおりに増加します。

これがSQLデータベースマネージドインスタンスの目的であることを理解していますが、そのサービスを使用するオプションはありません。

私は現在、iptablesを使用して転送を構成しておらず、プロキシVMで特別なホスト設定も行っていません。最初に、ネットワークトラフィックがパケットキャプチャに表示され、次にプロキシに正常に接続できることを確認したかったためですVMインスタンス。

さらに、Azureのサービスエンドポイントの制限を回避するためのこのタイプのソリューションは可能ですか？もっと簡単な方法はありますか？

ありがとう、そして最高の願い。

Michael - sqlbot · Answer

私のルートテーブルは、仮想プライベートゲートウェイを介してこのIPアドレスにトラフィックを転送するように構成されています。

この特定のアプローチが機能する可能性はないと思います。なぜなら...

ゲートウェイサブネットのルートテーブルを、Microsoft.SqlリージョナルエンドポイントパブリックIPアドレス宛てのトラフィックをプロキシに転送するように構成していますVM仮想アプライアンスであるかのように。

このルートテーブルは、そのサブネットから発信されたトラフィックに適用され、トラフィックの発信元ではありません。

ネットワークが認識する送信元アドレスと宛先アドレスは個々のVMのアドレスである必要があるため、このトラフィックをルーティングするだけでなく、2台のマシン間でトンネリングする必要があります。これはトンネルの機能の一部です。一般的かつ過度に単純化すると、トンネルはアドレスaとbのホストとの間のトラフィックを、アドレスxとyのホストとの外部パケット内でラップするため、中間ネットワークとゲートウェイは不要です。「実際の」送信元と宛先を理解します。プラットフォームの制限により、このトラフィックを、送信元と宛先がそのままのカプセル化されていないIPトラフィックとして単純にルーティングおよび転送することはおそらく不可能です。（または、適切なトンネルがない場合は、NATまたは両端のインスタンスのトラフィックをダブルNATする必要があります。）

OpenvpnやHAProxyなど、さまざまなレイヤーで動作するトンネルソリューションは多数ありますが、最も単純なのは（少なくとも概念実証の目的で）SSHトンネルです。

EC2インスタンスから、データベースがTCPポート1433を使用していると仮定：

$ ssh -L 1433:private-ip-of-db:1433 -i keyfile.pem username@ip-of-Azure-vm

このSSH接続が開いていると、EC2インスタンスのTCPポート1434）をリッスンするソケットもあり、接続EC2インスタンスのプライベートIPへのポートは開いているSSH接続を介してトンネリングされ、データベースにリレーされます。データベースは接続のソースIPをAzure VMのIPとして認識します...したがって、セキュリティ設定ではそれに応じてトラフィックを許可する必要がありますが、許可しないでください。説明したパブリックIPアドレスを使用します。EC2インスタンスのIPを使用し、EC2セキュリティグループを介してアクセスを制御し、Azure VMデータベースへのアクセスを許可する必要があります。データベースにアクセスするすべての観点から、EC2インスタンスはSQLServerのように見えます。

SQL Serverは、上記で示したものよりも多くのポートまたは異なるポートを必要とする1つ以上の落とし穴を提供する場合がありますが、ここでの一般的な考え方は確かです。この戦略は、RDP（TCPポート3389）やMySQLなどの他のプロトコルに使用しました。（TCPポート3306）しかし、MSSQLで試したことを思い出さないでください。