☰

Windows 10 では rutracker.org に対して PPTP 経由で SSL は機能しませんが、L2TP では機能します。

tag-icon • tag-icon windows-10 ssl pptp
Windows 10 では rutracker.org に対して PPTP 経由で SSL は機能しませんが、L2TP では機能します。

Windows 10のラップトップを持っていますが、ブラウザが開けないという奇妙な問題がありますhttps://rutracker.org/

次のような状態になります (開発者ツール モードの場合): 長い間、ブラウザーはリモートに何かを送信したことを認識せず (たとえば、Chrome は「停止」していると報告します)、その後、明確な理由もなくリクエストが失敗としてリストされます。Firefox と Edge でも試しましたが、接続に失敗し、意味のあるデバッグも提供されないという同じ結果になりました。

cURL もインストールしました。結果は次のとおりです。

curl -k -vvv https://rutracker.org/forum/index.php
* Trying 195.82.146.214...
* TCP_NODELAY set
* Connected to rutracker.org (195.82.146.214) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):

すると、長時間ハングアップし、SSL_ERROR_SYSCALL のエラーが発生します。対照的に、Linux ではまったく異なります。

curl -k -vvv https://rutracker.org/forum/index.php
* Hostname was NOT found in DNS cache
*   Trying 195.82.146.214...
* Connected to rutracker.org (195.82.146.214) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
*        subject: CN=rutracker.org
*        start date: 2018-07-20 04:13:49 GMT
*        expire date: 2018-10-18 04:13:49 GMT
*        issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*        SSL certificate verify ok.
> GET /forum/index.php HTTP/1.1
> User-Agent: curl/7.38.0
> Host: rutracker.org
> Accept: */*
> 
< HTTP/1.1 200 OK

純粋な OpenSSL を使用し、Windows SSL 実装を完全に回避するブラウザ ビルドがあるのでしょうか? どうやらそれがここでの問題のようです。最近 Malwarebytes で確認しましたが、特に何も見つかりませんでした。

編集: PPTP VPN で接続している場合にのみ発生することがわかりました。L2TP に切り替えると、問題なく Web サイトを突然開くことができます。何が起こっているのでしょうか?

答え1

Windows の TLS ライブラリには何の問題もありません (実際、Linux 上の curl は OpenSSL/1.1.0i に対してコンパイルされた場合、同じように動作します)。単に、より少ない、より大きなメッセージ (レイテンシの削減) を使用する新しいハンドシェイク形式を使用しているだけです。一方、curl は、まだ「SSLv3 互換」モードを持つ古いライブラリを使用しています。

しかし、これは同じ問題を引き起こす可能性のある多くの要因のうちの 1 つにすぎません。本当の問題は次のとおりです。

  1. VPN サーバーでは、仮想「PPTP クライアント」ネットワーク インターフェイスの MTU は、VPN オーバーヘッドなどを考慮して、比較的低い値 (例: 1280 バイト) に設定されています。
  2. TLS ハンドシェイク中に、Rutracker サーバーはこの MTU よりも大きい IP パケットを送信します。
  3. VPN サーバーは、パケットが出力インターフェイスより大きいためパケットを転送できず、サポートされている MTU を示す ICMP「Too Large」エラー パケットを返します。
  4. Rutracker ウェブサーバー無視するICMP メッセージを受信して​​も、ルート キャッシュを適切に調整せず、同じ大きなパケットを送信し続けます。手順 2 からやり直してください。

この ICMP ベースの MTU ネゴシエーションは「Path MTU Discovery」と呼ばれ、送信者が受信者のアドバイスを無視する状況は「PMTU ブラックホール」として知られています。おそらく Rutracker の管理者は、ICMP を完全にブロックするとサイトが何らかの形で「より安全」になるということをどこかで聞いたのでしょう...

サンプルの VPN サーバーの観点から見ると、次のようになります (意図的に誤って構成された OpenVPN を使用)。大きなパケットが何度も拒否されていることに注意してください。

IP 31.220.xy48872 > 195.82.146.214.443: フラグ [S]、シーケンス 2337162999、win 29200、オプション [mss 1358、sackOK、TS 値 674971446 ecr 0、nop、wscale 7]、長さ 0
IP 195.82.146.214.443 > 31.220.xy48872: フラグ [S.]、seq 2391406816、ack 2337163000、win 14600、オプション [mss 1460、nop、wscale 8]、長さ 0
IP 31.220.xy48872 > 195.82.146.214.443: フラグ [.]、ack 1、win 229、長さ 0
IP 31.220.xy48872 > 195.82.146.214.443: フラグ [P.]、シーケンス 1:217、ack 1、win 229、長さ 216
IP 195.82.146.214.443 > 31.220.xy48872: フラグ [.]、ack 217、win 62、長さ 0
IP 195.82.146.214.443 > 31.220.xy48872: フラグ [.]、シーケンス 1:1359、ack 217、win 62、長さ 1358
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy に到達できません - フラグメント化が必要です (mtu 1280)、長さ 556
IP 195.82.146.214.443 > 31.220.xy48872: フラグ [P.]、シーケンス 1359:3242、ack 217、win 62、長さ 1883
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy に到達できません - フラグメント化が必要です (mtu 1280)、長さ 556
IP 195.82.146.214.443 > 31.220.xy48872: フラグ [.]、シーケンス 1:1359、ack 217、win 62、長さ 1358
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy に到達できません - フラグメント化が必要です (mtu 1280)、長さ 556
IP 195.82.146.214.443 > 31.220.xy48872: フラグ [.]、シーケンス 1:1359、ack 217、win 62、長さ 1358
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy に到達できません - フラグメント化が必要です (mtu 1280)、長さ 556
IP 195.82.146.214.443 > 31.220.xy48872: フラグ [.]、シーケンス 1:1359、ack 217、win 62、長さ 1358
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy に到達できません - フラグメント化が必要です (mtu 1280)、長さ 556
IP 195.82.146.214.443 > 31.220.xy48872: フラグ [.]、シーケンス 1:1359、ack 217、win 62、長さ 1358
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy に到達できません - フラグメント化が必要です (mtu 1280)、長さ 556

L2TP VPN が影響を受けない理由はいくつか考えられます。

  • トンネルにデフォルトの 1500 MTU を使用し、サイズが大きすぎるパケットを透過的に断片化することができます。
  • 検出された接続に対して TCP MSS クランプを実行できます。
  • 削減された MTU を VPN クライアント ソフトウェアに報告することで、OS は TCP 接続要求に適切な MSS を設定することを事前に認識できるようになります。

クライアントとしてのオプションは次のとおりです (OS のサポート内容によって異なります)。

  • PPTP VPN は一切使用しないでください。(MTU の問題ではなく、その点では PPTP が他の VPN タイプより優れているわけでも劣っているわけでもありません。むしろ、プロトコルのセキュリティ上の問題が原因なのです。MPPE 暗号化と MSCHAP 認証はどちらも非常に脆弱です。)
  • クライアント OS で VPN インターフェイスの MTU を下げます (例: 1400 または 1280)。たとえば、Linux ではこれが可能ですip link set ppp0 mtu <bytes>。それに応じて、システムはより低い TCP MSS 値を Rutracker サーバーに通知します。
  • クライアント OS で TCP MTU プローブを有効にします。たとえば、Linux には がありますsysctl net.ipv4.tcp_mtu_probing=1。これは、ICMP PMTUD が機能しない場合でも機能します。
  • VPNクライアントの設定またはVPN サーバーのファイアウォールで TCP MSS クランプを実行します (これはパス上の任意の場所で実行できます)。
  • Rutracker 管理者に、彼らが間違った決定を下したことを納得させようとします。

関連情報