☰

SSL 無法在 Windows 10 上透過 PPTP 與 rutracker.org 搭配使用，但可以與 L2TP 搭配使用

tag-icon • tag-icon windows-10 ssl pptp
SSL 無法在 Windows 10 上透過 PPTP 與 rutracker.org 搭配使用，但可以與 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 時，我可以突然毫無問題地打開網站。這裡發生了什麼事？

答案1

Windows 的TLS 函式庫沒有任何問題（事實上，Linux 上的curl 在針對OpenSSL/1.1.0i 編譯時的行為方式相同）——它只是使用更新的握手格式，嘗試使用更少、更大的訊息（減少延遲），而你的curl使用一個舊的庫，它仍然具有“SSLv3兼容”模式。

但這只是眾多可能引發同樣問題的因素之一。真正的問題是：

  1. 在 VPN 伺服器上，虛擬「PPTP 用戶端」網路介面將其 MTU 設定為相對較低的值（例如 1280 位元組），以考慮 VPN 開銷等。
  2. 在 TLS 握手期間，Rutracker 伺服器會向您傳送大於此 MTU 的 IP 封包。
  3. 由於封包大於輸出接口，VPN 伺服器無法轉送封包，並傳回 ICMP「太大」錯誤封包，指示支援的 MTU。
  4. Rutracker 網路伺服器忽略ICMP 訊息，不會相應地調整其路由緩存，並繼續向您發送相同的大數據包。從步驟 2 開始。

這種基於 ICMP 的 MTU 協商稱為“路徑 MTU 發現”，而發送方忽略接收方建議的情況稱為“PMTU 黑洞”。也許 Rutracker 的管理員在某處聽說完全阻止 ICMP 會使該網站在某種程度上「更安全」...

以下是從 VPN 伺服器範例的角度來看的情況（使用故意錯誤配置的 OpenVPN）——注意大封包是如何一次又一次被拒絕的：

IP 31.220.xy48872 > 195.82.146.214.443：標誌[S]，seq 2337162999，win 29200，選項[mss 1358，sackOK，TS val 674971446 escale，
IP 195.82.146.214.443 > 31.220.xy48872：標誌[S.]，seq 2391406816，ack 2337163000，win 14600，選項[mss 1460，nop，長度
IP 31.220.xy48872 > 195.82.146.214.443：標誌[.]，ack 1，win 229，長度0
IP 31.220.xy48872 > 195.82.146.214.443：標誌[P.]，seq 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：標誌[.]，seq 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.]，seq 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：標誌[.]，seq 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：標誌[.]，seq 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：標誌[.]，seq 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：標誌[.]，seq 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 用戶端軟體，以便您的作業系統預先知道將正確的 MSS 放入其 TCP 連線請求中。

作為客戶端，您的選擇是（取決於作業系統支援的內容）：

  • 根本不要使用 PPTP VPN。 （不是由於 MTU 問題 – PPTP 在這方面並不比其他 VPN 類型更好或更差 – 而是由於該協議存在的安全性問題。MPPE 加密和 MSCHAP 身份驗證都非常弱。）
  • 降低客戶端作業系統上VPN 介面的MTU（例如至1400 或1280）。例如，Linux 允許您執行ip link set ppp0 mtu <bytes>.您的系統將會相應地向 Rutracker 伺服器通告較低的 TCP MSS 值。
  • 在客戶端作業系統上啟用 TCP MTU 探測。例如，Linux 有sysctl net.ipv4.tcp_mtu_probing=1.即使 ICMP PMTUD 不起作用，這也能起作用。
  • 設定 VPN 用戶端或者VPN 伺服器的防火牆執行 TCP MSS 箝位。 （這可以在路徑上的任何地方完成。）
  • 試著讓 Rutracker 管理員相信他們做了錯誤的決定。

相關內容