1

Windows Azure で仮想ネットワークをセットアップし、それを使用して (カスタム) SQL Server 仮想マシンでパブリック エンドポイントを開かないようにしようとしています。ただし、クラウド サービスの URL を介して Web アプリケーションにアクセスしようとすると、SQL Server が時間内に応答しないというネットワーク関連のエラーが継続的に発生します。

Windows Azure の事前構成された仮想マシンの 1 つではなく、カスタム作成された独自の VM に接続する方法を示すチュートリアルをネットで探しましたが、ほとんど役に立ちませんでした。私が見つけたすべての提案を試しました。

Windows Azure SDK SP1 がインストールされた Visual Studio 2010 を使用して、Windows 7 で作業しています。
これは、私が無駄にしようとしたことの詳細です。

私は持っている:

  • で仮想ネットワークを作成しました
    • 独自のアフィニティ グループ
    • 単一のサブネット
  • それに仮想マシンを追加しました
    • VNet 用に作成したアフィニティ グループと同じアフィニティ グループに配置するようにします。
  • インストールされた SQL Server
  • このチュートリアルに従って構成された SQL Server
  • データベースを追加し、データベースにアクセスできることを確認したログイン
  • 両方:
    1. 既存の Asp.NET Web サイトを Web アプリに変換し、Azure 展開パッケージを追加しました。従ったチュートリアルについては、こちらを参照してください。
      • これを使用r-click->Publish to Azure/Publishして、SQL VM を使用して VNet に既にデプロイした既存のクラウド サービスを使用するように構成し、それが VM と同じサブネットにあることを確認しました。
      • また、このアプリケーションは、ポート 1433 でパブリック エンドポイントを開き、パブリック IP アドレスを使用して接続することにより、仮想ネットワークの外部 (まだ Azure 内) にデプロイされた同様の VM に接続したことにも注意してください。
    2. このチュートリアル (最初に言及したもの)に従って構成された新しい Azure Cloud Service プロジェクトで、変換された Web アプリのコードを使用しました。
      • 私は両方の公開を試みました:
        • r-click->Publish to Azure/Publish
        • r-click->PackageAzureポータルにアップロードする
      • どちらの場合も両方に
        • VNet (およびサブネット) 内の既存のクラウド サービス
        • VNet (およびサブネット) で作成された新しいクラウド サービスと、作成中にパッケージをアップロードするか、開始したらすぐにサービスに公開します。
  • 確認したすべてのクラウド サービスと仮想マシンが VNet 内にあり、同じサブネット内にあることを再確認しました。

    • 私のクラウド サービスは通常、内部 IP 10.4.2.5 にあり、VM は 10.4.2.4 にあります。私の接続文字列は、最初に言及したチュートリアルと同じですが、適切な認証と VM の内部 IP が指定されているだけです。接続文字列は次のとおりです。

      <add name="SQLServerinWAConnection"
      connectionString="Data Source=tcp:SQLVMInternalIPAddress;Initial Catalog=MyTableName;User ID=loginName;Password=thepassword;Encrypt=true;Trusted_Connection=false;TrustServerCertificate=true"
      providerName="System.Data.SqlClient" />
      
      • 私も指定してみましたTrusted_Connection=true

何を試しても、このアプリケーションをその VM 上の SQL Server インスタンスに接続することはできません。ポート 1433 で VM にパブリック エンドポイントを追加し、そのパブリック IP とプライベート IP を使用してみましたが、役に立ちませんでした。それが私のフォールバックだったので、今私は深刻な損失を被っています。

関係がある場合とない場合があるいくつかの実装の詳細:

  • SQL Server インスタンスには、既定ではなく名前が付けられているため、SQL Server Management Studio のオブジェクト エクスプローラーでは単に 'SQLServerVM' ではなく、'SQLServerVM\SQLServerDB' と表示されます。
  • 任意の IP 範囲と任意のユーザーに対して、VM のファイアウォールでポート 1433 を開いています。

リクエストに応じて、追加の詳細を追加します (私が行ったことを理解するためにチュートリアル全体を読みたくない場合)。

Web ロールまたは Web サイトが仮想ネットワーク内の仮想マシンに接続できるようにするために実行する必要があることを示すチェックリストが利用できる可能性はありませんか? これにより、トラブルシューティングが大幅に簡素化されます。

どんな提案でも大歓迎です。一日の終わりまでにこれを機能させたいと思います。

4

1 に答える 1

1

私の場合、クライアントが名前付きデータベース インスタンスを使用して VM に SQL Server をインストールしたため、接続する必要のあるインスタンスをホストするサービスの TCP ポートが正しく設定されていませんでした。そのため、SQL Server インスタンスの名前が付けられたという私の詳細は非常に重要でした。

Web ロール (クラウド サービス) が同じ仮想ネットワーク内の仮想マシンに接続していない理由がわからない場合は、上記の質問のすべてを確認することに加えて、次の設定を確認してください。

  1. 仮想マシン (RDP) にログインします。
  2. SQL Server 構成マネージャーを開く
  3. 左側のパネルで[ SQL Server ネットワーク構成] を展開します。
  4. 左側のパネルで[ {SQL インスタンス名} のプロトコル] をクリックします。
  5. 右側のパネルで[ TCP/IP ]を右クリックし、[プロパティ... ] に移動します。
  6. 「Enabled」が「Yes」に設定されていることを再確認します。
  7. [ IP アドレス] タブに切り替えます。
  8. この時点で、「TCP ポート」は、「IPALL」または他のものでない場合、少なくともドメイン IP (私の場合は「IP2」セクションの 10.4.2.4) に対して 1433 である必要があることがわかります。
    • すべての「IP{X}」セクションの「TCP ポート」設定の値が異なる場合があることに注意してください。

この SQL Server インスタンスが 1433 (または構成しようとしている他のポート) でリッスンしていない場合:

  1. 「IPALL」に移動し、 「TCP ポート」を 1433に変更します(または任意のポート、1433 が送信先のデフォルトです)。
    • これにより、そのポートで、どこからでもこのサーバーに送信されるアドレスをリッスンできるようになります。
    • おそらくこれを行うためのよりクリーンな方法があることに注意してください。

これにより、構成したポート (1433) 用にパブリック エンドポイントを開くことなく、VM の内部 IP アドレスのみを使用して、その VNet 内のすべてのクラウド サービスから SQL Server インスタンスにアクセスできました。
念のため、実際の接続文字列は次のとおりです。

<add name="ApplicationServices"
    connectionString="Data Source=tcp:{VM Internal IP}\{InstanceName},{port};Initial Catalog={Table};User ID={username};Password={passwd};Encrypt=true;Trusted_Connection=false;TrustServerCertificate=true" providerName="System.Data.SqlClient"/>

必ず置き換えてください:

  • {VM Internal IP}内部IPアドレスで
  • {InstanceName}を SQL Server インスタンスの名前に\置き換えるか、既定のインスタンスを使用している場合は、前の部分を省略してください。
  • {port}1433、またはその Sql Server インスタンス用に VM で開いているポートのいずれかである必要があります。
  • {Table}デフォルトで使用するデータベーステーブルで
  • {username}また{passwd}、SQL Server ユーザー用のものもあります。ここでは SQL Server 認証を使用していることに注意してください。

また、これによりサーバーがインターネットに開放されなかったことも注目に値します (予想どおり)。これは、外部からアクセスできないため、この方法で VNet 内でセキュリティが確保されたままです。

うまくいけば、これは将来誰かを助けるでしょう。

于 2013-10-01T20:33:04.550 に答える