☰

SSL не работает на Windows 10 против rutracker.org через PPTP, но работает с L2TP

tag-icon • tag-icon windows-10 ssl pptp
SSL не работает на Windows 10 против rutracker.org через PPTP, но работает с 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

С библиотекой TLS в Windows все в порядке (и, действительно, curl в Linux ведет себя так же, если скомпилирован с OpenSSL/1.1.0i) — она просто использует более новый формат рукопожатия, который пытается использовать меньше сообщений большего размера (что сокращает задержку), тогда как ваш curl использует старую библиотеку, которая все еще имеет режим «совместимости с SSLv3».

Но это лишь одна из многих вещей, которые могут вызвать ту же проблему. Настоящая проблема в следующем:

  1. На VPN-сервере виртуальный сетевой интерфейс «PPTP-клиентов» имеет относительно низкое значение MTU (например, 1280 байт) — для учета накладных расходов VPN и многого другого.
  2. Во время TLS-рукопожатия сервер Rutracker отправляет вам IP-пакет, размер которого превышает этот MTU.
  3. VPN-сервер не может переслать пакет, поскольку он больше выходного интерфейса, и возвращает пакет ошибки ICMP «Слишком большой», указывающий поддерживаемый MTU.
  4. Веб-сервер Rutrackerигнорируетсообщение ICMP не корректирует свой кэш маршрутов соответствующим образом и продолжает отправлять вам тот же большой пакет. Начните заново с шага 2.

Это согласование MTU на основе ICMP называется "Path MTU Discovery", а ситуация, когда отправитель игнорирует совет получателя, известна как "PMTU blackhole". Возможно, администраторы Rutracker где-то слышали, что полная блокировка ICMP делает сайт каким-то образом "более безопасным"...

Вот как это выглядит с точки зрения примера VPN-сервера (использующего намеренно неправильно настроенный OpenVPN) — обратите внимание, как большой пакет отклоняется снова и снова:

IP 31.220.xy48872 > 195.82.146.214.443: Флаги [S], seq 2337162999, win 29200, параметры [mss 1358,sackOK,TS val 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.], 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 не будет затронут по нескольким возможным причинам:

  • он может использовать MTU по умолчанию 1500 для туннеля и прозрачно фрагментировать пакеты слишком большого размера;
  • он может выполнять TCP MSS-фиксацию для соединений, которые он видит;
  • он может сообщить об уменьшении MTU программному обеспечению вашего VPN-клиента, чтобы ваша ОС заранее знала, что нужно указывать правильный MSS в запросах на TCP-подключение.

Как клиенту, вам доступны следующие варианты (в зависимости от того, что поддерживает ОС):

  • Не используйте VPN PPTP вообще. (Не из-за проблем с MTU — PPTP в этом отношении не лучше и не хуже других типов VPN — а скорее из-за проблем безопасности, которые есть у протокола. И шифрование MPPE, и аутентификация MSCHAP очень слабы.)
  • Уменьшите MTU интерфейса VPN (например, до 1400 или 1280) на клиентской ОС. Например, Linux позволяет это сделать ip link set ppp0 mtu <bytes>. Соответственно, ваша система будет рекламировать более низкое значение TCP MSS серверам Rutracker.
  • Включите проверку TCP MTU на клиентской ОС. Например, в Linux есть sysctl net.ipv4.tcp_mtu_probing=1. Это работает даже там, где ICMP PMTUD не работает.
  • Настройте VPN-клиентилибрандмауэр VPN-сервера для выполнения ограничения TCP MSS. (Это можно сделать в любом месте пути.)
  • Попробуйте убедить администраторов Rutracker, что они приняли неправильное решение.

Связанный контент