☰

SSL은 PPTP를 통해 rutracker.org에 대해 Windows 10에서 작동하지 않지만 L2TP에서는 작동합니다.

tag-icon • tag-icon windows-10 ssl pptp
SSL은 PPTP를 통해 rutracker.org에 대해 Windows 10에서 작동하지 않지만 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의 컬은 OpenSSL/1.1.0i에 대해 컴파일할 때와 동일한 방식으로 작동합니다). 이는 단순히 더 적고 더 큰 메시지를 사용하려고 시도하는 최신 핸드셰이크 형식을 사용하는 반면(대기 시간 감소) 귀하의 컬은 여전히 ​​"SSLv3 호환" 모드를 갖고 있는 오래된 라이브러리를 사용하고 있습니다.

그러나 이는 동일한 문제를 유발할 수 있는 많은 것 중 하나일 뿐입니다. 진짜 문제는 다음과 같습니다.

  1. VPN 서버에서 가상 "PPTP 클라이언트" 네트워크 인터페이스의 MTU는 VPN 오버헤드를 고려하여 상대적으로 낮은 값(예: 1280바이트)으로 설정됩니다.
  2. TLS 핸드셰이크 중에 Rutracker 서버는 이 MTU보다 큰 IP 패킷을 보냅니다.
  3. VPN 서버는 패킷이 출력 인터페이스보다 크기 때문에 패킷을 전달할 수 없으며 지원되는 MTU를 나타내는 ICMP "너무 큼" 오류 패킷을 반환합니다.
  4. Rutracker 웹서버무시하다ICMP 메시지는 그에 따라 경로 캐시를 조정하지 않고 계속해서 동일한 대규모 패킷을 보냅니다. 2단계부터 다시 시작하세요.

이러한 ICMP 기반 MTU 협상을 "Path MTU Discovery"라고 하며, 송신자가 수신자의 조언을 무시하는 상황을 "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 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은 여러 가지 이유로 인해 영향을 받지 않습니다.

  • 터널에 기본 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 관리자가 잘못된 결정을 내렸다고 설득해 보세요.

관련 정보