Không thể kết nối với các trang web HTTPS nhất định

Tôi mới chuyển đến một căn hộ mới và có kết nối internet qua bộ định tuyến và tôi thấy rằng tôi không thể kết nối với khá nhiều trang web sử dụng SSL.

Ví dụ: cố gắng kết nối với PayPal:

curl -v https://paypal.com
* About to connect() to paypal.com port 443 (#0)
*   Trying 66.211.169.3... connected
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to paypal.com:443 
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to paypal.com:443 

curl -v -ssl https://paypal.com cho cùng một đầu ra.

Đối với một số trang web, nó hoạt động:

curl -v https://www.google.com
* About to connect() to www.google.com port 443 (#0)
*   Trying 74.125.235.112... connected
* 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 ECDHE-RSA-RC4-SHA
* Server certificate:
*    subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=www.google.com
*    start date: 2011-10-26 00:00:00 GMT
*    expire date: 2013-09-30 23:59:59 GMT
*    common name: www.google.com (matched)
*    issuer: C=ZA; O=Thawte Consulting (Pty) Ltd.; CN=Thawte SGC CA
*    SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: www.google.com
> Accept: */*
> 
< HTTP/1.1 302 Found
< Location: https://www.google.co.jp/
  .
  .
  .

Tôi đang sử dụng Ubuntu 12.04, với Windows 7 cũng được cài đặt. Các trang này hoạt động trên Windows :(

Không chắc chắn nếu thông tin này có ích nhưng tôi đã chạy ifconfigvà nhận được những điều sau đây:

eth0      Link encap:Ethernet  HWaddr 1c:c1:de:bc:e2:4f  
          inet6 addr: 2408:c3:7fff:991:686b:8d18:81b3:8dd1/64 Scope:Global
          inet6 addr: 2408:c3:7fff:991:1ec1:deff:febc:e24f/64 Scope:Global
          inet6 addr: fe80::1ec1:deff:febc:e24f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:87075 errors:0 dropped:0 overruns:0 frame:0
          TX packets:54522 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:78167937 (78.1 MB)  TX bytes:10016891 (10.0 MB)
          Interrupt:46 Base address:0x4000 

eth1      Link encap:Ethernet  HWaddr ac:81:12:0d:93:80  
          inet6 addr: fe80::ae81:12ff:fe0d:9380/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:498
          TX packets:0 errors:26 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:17 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:630 errors:0 dropped:0 overruns:0 frame:0
          TX packets:630 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:39592 (39.5 KB)  TX bytes:39592 (39.5 KB)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:180.57.228.200  P-t-P:118.23.8.175  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:39631 errors:0 dropped:0 overruns:0 frame:0
          TX packets:22391 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:43462054 (43.4 MB)  TX bytes:2834628 (2.8 MB)

Tôi đã chạy PING:

ping www.paypal.com
PING e6166.b.akamaiedge.net (184.31.66.234) 56(84) bytes of data.
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=1 ttl=54 time=15.3 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=2 ttl=54 time=15.0 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=3 ttl=54 time=15.2 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=4 ttl=54 time=17.2 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=5 ttl=54 time=16.6 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=6 ttl=54 time=16.7 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=7 ttl=54 time=14.8 ms
^C
--- e6166.b.akamaiedge.net ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6009ms
rtt min/avg/max/mdev = 14.878/15.890/17.214/0.901 ms

Và không có www:

ping paypal.com
PING paypal.com (66.211.169.66) 56(84) bytes of data.
^C
--- paypal.com ping statistics ---
303 packets transmitted, 0 received, 100% packet loss, time 302265ms

TRACEROUTE:

traceroute www.paypal.com
traceroute to www.paypal.com (184.31.66.234), 30 hops max, 60 byte packets
 1  118.23.8.175 (118.23.8.175)  8.424 ms  8.404 ms  8.540 ms
 2  118.23.10.121 (118.23.10.121)  8.212 ms  8.189 ms  8.162 ms
 3  122.1.164.213 (122.1.164.213)  9.405 ms  11.359 ms  13.469 ms
 4  60.37.55.165 (60.37.55.165)  8.049 ms  8.072 ms  8.040 ms
 5  118.23.168.89 (118.23.168.89)  8.574 ms  8.549 ms  8.558 ms
 6  210.163.230.238 (210.163.230.238)  8.667 ms  7.605 ms  7.545 ms
 7  xe-4-0-0.a21.osakjp01.jp.ra.gin.ntt.net (61.213.169.218)  18.255 ms  18.232 ms xe-3-0-0.a21.osakjp01.jp.ra.gin.ntt.net (61.213.162.206)  19.042 ms
 8  * * *
 9  * * *
   .
   .
   .
29  * * *
30  * * *

không có www:

traceroute paypal.com
traceroute to paypal.com (66.211.169.66), 30 hops max, 60 byte packets
 1  118.23.8.175 (118.23.8.175)  5.607 ms  5.674 ms  5.875 ms
 2  118.23.10.121 (118.23.10.121)  5.468 ms  5.453 ms  5.576 ms
 3  122.1.164.213 (122.1.164.213)  7.595 ms  10.062 ms  11.660 ms
 4  60.37.55.165 (60.37.55.165)  5.684 ms  5.660 ms  5.635 ms
 5  60.37.27.90 (60.37.27.90)  5.960 ms  5.924 ms  5.898 ms
 6  ae-11.r20.tokyjp01.jp.bb.gin.ntt.net (129.250.12.197)  86.468 ms  30.960 ms  30.899 ms
 7  as-1.r20.sttlwa01.us.bb.gin.ntt.net (129.250.4.189)  161.185 ms  144.343 ms  132.410 ms
 8  ae-1.r05.sttlwa01.us.bb.gin.ntt.net (129.250.5.47)  139.008 ms  127.377 ms  139.050 ms
 9  xe-0.sprint.sttlwa01.us.bb.gin.ntt.net (129.250.9.190)  116.006 ms  104.306 ms  115.954 ms
10  144.232.1.153 (144.232.1.153)  141.046 ms  129.870 ms  140.991 ms
11  sl-crs2-sj-0-5-2-0.sprintlink.net (144.232.18.204)  131.271 ms  131.248 ms  142.544 ms
12  sl-st31-sj-0-15-0-0.sprintlink.net (144.232.8.151)  129.543 ms  141.575 ms  141.066 ms
13  * * *
14  * * *
    .
    .
    .
29  * * *
30  * * *

Các tcpdump:

1   0.000000    114.178.88.59   66.211.169.66   TCP 76  37374 > https [SYN] Seq=0 Win=14520 Len=0 MSS=1452 SACK_PERM=1 TSval=68855 TSecr=0 WS=64
2   0.136291    66.211.169.66   114.178.88.59   TCP 80  https > 37374 [SYN, ACK] Seq=0 Ack=1 Win=4356 Len=0 MSS=1460 WS=1 TSval=3608913175 TSecr=68855 SACK_PERM=1
3   0.136322    114.178.88.59   66.211.169.66   TCP 68  37374 > https [ACK] Seq=1 Ack=1 Win=14528 Len=0 TSval=68889 TSecr=3608913175
4   0.137409    114.178.88.59   66.211.169.66   SSL 309 Client Hello
5   0.274446    66.211.169.66   114.178.88.59   SSL 95  [TCP Previous segment lost] Continuation Data
6   0.274469    114.178.88.59   66.211.169.66   TCP 80  [TCP Dup ACK 4#1] 37374 > https [ACK] Seq=242 Ack=1 Win=14528 Len=0 TSval=68923 TSecr=3608913175 SLE=2881 SRE=2908
7   7.117833    91.189.89.76    114.178.88.59   TLSv1   142 Application Data, Application Data
8   7.118823    114.178.88.59   91.189.89.76    TLSv1   216 Application Data, Application Data, Application Data, Application Data
9   7.393725    91.189.89.76    114.178.88.59   TCP 68  https > 41264 [ACK] Seq=75 Ack=149 Win=146 Len=0 TSval=875420654 TSecr=70634
10  60.301444   66.211.169.66   114.178.88.59   TCP 56  https > 37374 [RST, ACK] Seq=2908 Ack=242 Win=4597 Len=0

Đây là một ISP của Nhật Bản và mặc dù tôi đang kết nối với cáp đến modem / bộ định tuyến, tôi cần thêm tên người dùng và mật khẩu, nhưng với kết nối "Có dây" của Ubuntu, tôi không thể thêm chúng. Bạn cùng phòng của tôi đã bảo tôi tạo kết nối OCN nhưng tôi không chắc đó là tên của một loại mạng hay chỉ là công ty Nhật Bản ... nhưng sau khi nhìn vào máy tính của cô ấy, chúng tôi thấy đó là kết nối PPPoE. Sau một vài lần googling tôi đã học được rằng để tạo kết nối PPPoE, tôi sẽ cần tạo kết nối DSL và tôi có thể thêm mật khẩu & tên người dùng vào đó. Tôi cũng đã thay đổi kết nối "Có dây" thành không kết nối tự động.

Tôi gặp vấn đề tương tự nếu tôi kết nối trực tiếp với modem.

Tôi đã thử thay đổi DSL MTU thành 500, 1500, 1492 và 1482 nhưng nó không tạo ra sự khác biệt.

Ngoài ra, vì một số lý do, Ubuntu không phải lúc nào cũng nhận kết nối, đôi khi tôi phải khởi động lại để kết nối.

Đây là một câu hỏi cũ, nhưng đối với những người đến đây thông qua Google, điều này sẽ giúp ích. Vấn đề là phân mảnh trên SSL là xấu và phá vỡ giao thức. Nếu bạn đang sử dụng PPPOE, MTU bình thường trong modem bộ định tuyến / DSL / Cáp của bạn là 1492. Đó là quá cao và sẽ gây ra sự phân mảnh. 1476 là con số kỳ diệu sẽ hoạt động với hầu hết các trang web. Một số trang web sử dụng các triển khai SSL khác nhau để 1480 có thể hoạt động hoặc thậm chí là 1488. Để tương thích MOST, MTU ở phía mạng WAN của thiết bị mạng của bạn (bộ định tuyến, modem, v.v.) phải là 1476.

Dưới đây là một vài điều cần thử:

1. Kiểm tra cài đặt card mạng của bạn. Cả hai giao diện eth của bạn đều không hiển thị địa chỉ IPv4. Đảm bảo rằng bạn đã bật IPv4 (bạn có thể cần phải thiết lập lại kết nối với bộ định tuyến của mình để làm mới IP). Nếu điều đó không hiệu quả, hãy thử tắt hỗ trợ IPv6 và xem điều đó có tạo ra sự khác biệt không. Thực hiện việc này bằng cách nhấp chuột phải vào biểu tượng mạng bằng đồng hồ của bạn (khi trên kết nối Ethernet, đó là một cặp mũi tên, một mũi tên hướng lên, mũi kia hướng xuống) và chọn "Chỉnh sửa kết nối ...". Trong tab "Cài đặt IPv4", đảm bảo nó được đặt thành "Tự động (DHCP)". Nếu bạn muốn tắt IPv6, hãy chuyển đến tab của nó và đặt thành "Bỏ qua".

2. Kiểm tra xem bạn có thể kết nối với các trang web bằng các phương pháp khác không. Điều gì pingphản hồi với các trang web bạn không thể kết nối? Làm thế nào về một traceroute(bạn có thể phải cài đặt traceroute để sử dụng nó, FYI)? Phản hồi của họ có thể giúp bạn khắc phục sự cố. Nếu họ không thể truy cập vào máy chủ của URL, thì đó có thể là sự cố DNS (tuy nhiên, nếu họ có thể truy cập vào máy chủ của URL, nhưng sau đó bị hủy, điều đó có nghĩa là các lệnh đó bị chặn).

3. Bỏ qua bộ định tuyến. Nếu bộ định tuyến và modem của bạn là hai máy khác nhau, hãy thử nối trực tiếp máy tính của bạn với modem và xem điều đó có thay đổi gì không.

4. Khởi động lại modem và bộ định tuyến của bạn. Đôi khi, họ chỉ mút tay.

5. Khởi động lại máy tính của bạn. Đôi khi, họ chỉ mút tay.

6. Hãy thử một máy tính khác. Nếu bạn có một cái, máy tính khác có hoạt động không khi cái này bị lỗi? Nếu không, nó có thể là một cái gì đó với máy tính cụ thể của bạn.

7. Xóa bộ nhớ cache, cookie của máy tính, v.v. Đôi khi, cookie phiên xấu, bộ đệm, v.v. có thể cản trở việc kết nối với một trang web (tôi đã gặp vấn đề này với Google một thời gian trước). Xóa chúng ra và bắt đầu mới và xem những gì bạn nhận được.

8. Ngắt kết nối mọi kết nối VPN. Giao thức điểm-điểm thường được sử dụng cho VPN (giao diện PPP) và VPN có thể cản trở việc kết nối với các trang web. Đảm bảo bạn không kết nối bằng cách nhấp chuột phải vào biểu tượng mạng bằng đồng hồ của bạn, tìm mục nhập "Kết nối VPN" và đảm bảo không có danh sách nào được kiểm tra (nếu bạn không có mục trình đơn "Kết nối VPN", thì bạn không ' t có một thiết lập). Nếu có bất kỳ kiểm tra nào, thì bạn đã kết nối với nó, ngắt kết nối với nó.

Hãy nhớ rằng: Không phải mọi thứ bạn làm sẽ dẫn đến một "công việc hay thất bại" đơn giản, bất kỳ thay đổi nào trong phản ứng của máy chủ đối với yêu cầu của bạn sẽ cho chúng tôi biết điều gì đó. Vì vậy, nếu bạn thực hiện bất kỳ thao tác nào ở trên và nhận được tin nhắn mới, đừng quên cập nhật câu hỏi của bạn.

Tôi đã thấy hành vi này hai lần trong thực tế mà tôi đã tìm thấy các giải pháp sau đây.

• Một số máy tính trong mạng cục bộ đã thực hiện thành công một cuộc tấn công trung gian. Đó là ARP giả mạo cổng, do đó chuyển hướng tất cả lưu lượng truy cập để đi qua máy này, sửa đổi yêu cầu và những thứ khó chịu khác. Máy đang chạy Windows và bị nhiễm một số phần mềm độc hại khó chịu. Ngay khi máy này bị ngắt kết nối mạng, các triệu chứng đã biến mất.
• Một vấn đề MTU trên cổng của bạn hoặc khác. Trong các cổng IPv4 chịu trách nhiệm phân mảnh và lắp ráp lại các gói IP trên mạng nếu kích thước khung của các mạng mà lưu lượng định tuyến của nó không giống nhau. Đối với các kết nối DSL sử dụng PPPoE / PPPoA, kích thước MTU thường nhỏ hơn 1500 byte ở phía LAN. Ngoài ra các bộ định tuyến ở giữa không thành công và bạn cần bật TCP MSS Kẹp trên bộ định tuyến của mình. Tôi luôn cần thiết lập điều này trên kết nối của ISP trước đây của mình, nhưng nó đã giải quyết được nhiều vấn đề hơn là chỉ liên quan đến SSL. Kiểm tra xem modem / bộ định tuyến của bạn có tùy chọn như vậy không. Hãy coi đây là một cách giải quyết.
• Tôi đã ở trong một mạng có thể đang chạy một proxy trong suốt để vượt qua lưu lượng SSL, nhưng vì một số lý do không thành công tại TLSv1. Yêu cầu tương tự hoạt động khi sử dụng kết nối VPN. đáng sợ
  Hãy thử chạy curlvới tùy chọn --sslv3. Nếu điều đó giải quyết nó, thì nó bốc mùi.

Những thứ chung để thử:

• Kiểm tra xem bạn có đang chạy chương trình cơ sở mới nhất trên modem / bộ định tuyến không. Nếu không, hãy thử nâng cấp.

• Nắm bắt lưu lượng truy cập bằng cách sử dụng tcpdumphoặc Whireshark và phân tích nó (ví dụ đăng nó ở đây).

    # 1. start the dump
  $ sudo tcpdump -w httpstrafficdump.pcap -i eth0 -s 0 port 443
    # 2. open a new terminal window and do your HTTPS request there (curl/browser)
    # 3. end tcpdump (Ctrl+C)
    # 4. open the file in wireshark
  $ wireshark httpstrafficdump.pcap
  

  Nếu bạn đang gặp phải lỗi Đánh giá lại hoặc phân đoạn trước bị mất liên tục, đây là một dấu hiệu rõ ràng về việc mất gói do kích thước MTU sai.
  Tuy nhiên, lưu lượng HTTPS được mã hóa và khó phân tích từ lưu lượng mạng.

Biên tập:

Từ tcpdump của bạn, gốc rễ của vấn đề SSL của bạn là rõ ràng : TCP Previous segment lost. Xử lý sự cố mạng chung nên được áp dụng ở đây, nhưng nó có thể nằm ngoài phạm vi của mạng cục bộ của bạn và có vấn đề với ISP của bạn.

Xin chào mọi người, đây là marcaleriof từ Ý, gần đây chúng tôi có một vấn đề tương tự như của bạn: tất cả máy Linux của chúng tôi không thể kết nối với bất kỳ trang web https nào trong khi Android hoặc Thiết bị Windows không gặp sự cố. Vấn đề là sự mất cân bằng mtu giữa bộ định tuyến DSL của chúng tôi có chiều dài 1492 mtu và mtu Linux mặc định là 1500. Vì thực tế việc ban hành lệnh này là root

ifconfig wlan0 mtu 1492 up

(bằng tiếng Anh bộ này Giá trị mtu ​​của giao diện mạng - wlan0 trong trường hợp của tôi - đến chiều dài 1492) đã thoát khỏi vấn đề, cảm ơn bạn! Hy vọng điều này có thể giúp ai đó.

Cảm ơn tất cả sự giúp đỡ của bạn, vấn đề cuối cùng đã được khắc phục!

Tôi đã cố gắng giới hạn MTU để xem liệu nó có giúp ích hay không và cuối cùng sử dụng pppoeconfđể thiết lập kết nối PPPoE vì nó giới hạn MTU cho tôi. Sau đó tôi đã vô hiệu hóa kết nối DSL mà tôi đã sử dụng trước đó.

Đối với bất kỳ ai gặp vấn đề tương tự, bạn có thể thử giải pháp này bằng cách nhập sudo ppoeconfvà làm theo hướng dẫn. Sau đó, bạn có thể kết nối pon adsl-providervà ngắt kết nối vớipoff