web-dev-qa-db-ja.com

Visual Studio 2015-企業プロキシの背後でサインインできない、NuGetを使用するなど

認証を必要とする企業のプロキシサーバーの背後にいます。 Visual Studio 2015を使用すると、サインイン、NuGetの使用、拡張機能の参照などができません。インターネットにアクセスするためにプロキシを経由する必要があるすべてのもの。これは、以前のバージョンのVisual Studioでは問題ではありません。

NuGet connection error

中間プロキシとして機能し、企業プロキシに対して認証を行うFiddlerを実行すると、すべてが機能します。または、ラップトップを公共のインターネット（企業のプロキシの背後ではない）で入手すれば、すべてが機能します。

C：\ Program Files（x86）\ Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe.configを here のように変更しようとしました。私はもう試した

<defaultProxy enabled="true" useDefaultCredentials="true">
   <proxy bypassonlocal="True" proxyaddress="http://<yourproxy:port#>"/>
</defaultProxy>

そして

<defaultProxy enabled="true" useDefaultCredentials="true">
   <proxy usesystemdefault="true"/>
</defaultProxy>

...しかし役に立たない。他の誰かがこの問題に遭遇しましたか？

UPDATE：以下にDimitriが述べたように、NuGetは正しく動作するようになりました。それでも機能しないのは、サインイン画面と、スタートページの[おすすめ動画]フィードだけです。私はMicrosoftアカウント担当者と連絡を取り合っており、さらにトラブルシューティングを行うためにMicrosoftにメモリダンプを送信しています。

UPDATE：NuGetは再び動作を停止しました。 Fiddlerが機能する理由は FiddlerがTLS 1.0接続を強制するため であると判断しました。主な問題は、当社の企業プロキシであるBlueCoatがTLS 1.2接続を許可しておらず、Visual StudioがIE/ChromeのようにTLS 1.1または1.0に適切にフォールバックしてはならないことです。この情報を武器に、ネットワーク/セキュリティチームに行き、どこかに行こうと試みます。

proxynugetvisual-studio-2015
18
wags1999

.Net 4.6（およびVisual Studio 2015）には、System.Net.ServicePointManager.SecurityProtocol以前のバージョンのフレームワークより。デフォルトには、TLS 1.0に加えて、TLS 1.2およびTLS 1.1が含まれるようになりました。そのため、これは以前のバージョンのVisual Studioでは決して問題になりませんでした。

私たちの場合、問題は、TLS 1.2 ECDHE-ECDSA暗号をサポートしていない企業のBlueCoatプロキシにあります。長期的な解決策は、BlueCoatをこの新しい暗号をサポートするバージョンに更新することです。しかし、短期的には、Windowsが異なる暗号スイートを使用しようとする順序を指定することができたため、BlueCoatが理解できる暗号を使用します。

  1. ローカルグループポリシーエディター（gpedit.msc）を開く
  2. [コンピューターの構成]-> [管理用テンプレート]-> [ネットワーク]-> [SSL構成設定]を展開します。
  3. SSL Cipher Suite Order設定を開きます。
  4. 設定を「有効」に設定してから、SSL暗号スイートの順序を次のように設定します。

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_RC4_128_MD5,SSL_CK_RC4_128_WITH_MD5

（コピーして貼り付けた後、リストにスペースがないことを確認してください）

  1. [OK]をクリックして、コンピューターを再起動します。

デフォルトからの唯一の変更点は、TLS_ECDHE_RSA_WITH_AES_CBC_SHA_P256を先頭に移動することです。これにより、TLS 1.2では、より高い強度のECDSA暗号が最初にネゴシエートされません。同様の問題が発生している場合は、ネットワーク/セキュリティチームと協力して、優先する必要がある暗号を判断する必要があります。

14
wags1999

NUGET設定でこのアドレスを使用します

http://packages.nuget.org/v1/FeedService.svc/

このアドレスはHTTPプロトコルであり、正常に機能します。

14
Antonio Sgrignoli

fiddler4を使用してプロキシとして機能させる（およびhttpsトラフィックを復号化する）と、この問題を回避できます Fiddlerを使用してVisual Studio 2013のリクエストを傍受する（プロキシファイアウォール）

5
vip32

多くのユーザー（私を含む）に同じ問題があります： https://social.msdn.Microsoft.com/Forums/en-US/06e580a4-fede-43cf-b285-3d3d66fb1b9a/cant-sign-into-vs- 2015？forum = vssetup

更新：nugetの新しいバージョンで=> nuget接続が機能するようになりました。

2
Dimitri