Nie można połączyć się z niektórymi witrynami HTTPS

Właśnie przeprowadziłem się do nowego mieszkania z połączeniem internetowym za pośrednictwem routera i stwierdzam, że nie mogę połączyć się z wieloma stronami korzystającymi z SSL.

Na przykład próba połączenia z 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 daje taki sam wynik.

W przypadku niektórych witryn działa:

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/
  .
  .
  .

Używam Ubuntu 12.04, z zainstalowanym systemem Windows 7. Te witryny działają w systemie Windows :(

Nie jestem pewien, czy te informacje pomogą, ale uruchomiłem ifconfigi otrzymałem następujące informacje:

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)

Uruchomiłem 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

I bez 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  * * *

bez 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  * * *

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

To jest japoński ISP i chociaż łączę się kablem z modemem / routerem, muszę dodać nazwę użytkownika i hasło, ale przy połączeniu przewodowym Ubuntu nie mogłem ich dodać. Moja współlokatorka powiedziała mi, żebym utworzył połączenie OCN, ale nie jestem pewien, czy to nazwa rodzaju sieci, czy tylko japońskiej firmy ... ale po obejrzeniu jej komputera odkryliśmy, że jest to połączenie PPPoE. Po pewnym googlowaniu dowiedziałem się, że aby utworzyć połączenie PPPoE, muszę utworzyć połączenie DSL i że mogę dodać do niego hasło i nazwę użytkownika. Zmieniłem również połączenie „Przewodowe”, aby nie łączyć się automatycznie.

Ten sam problem pojawia się, jeśli podłączę się bezpośrednio do modemu.

Próbowałem zmienić MTU DSL na 500, 1500, 1492 i 1482, ale to nie miało znaczenia.

Również z jakiegoś powodu Ubuntu nie zawsze odbiera połączenie, czasami muszę go zrestartować, aby się połączyć.

To stare pytanie, ale dla osób przybywających za pośrednictwem Google to pomoże. Problem polega na tym, że fragmentacja protokołu SSL jest zła i psuje protokół. Jeśli używasz PPPOE, normalny MTU w routerze / DSL / modemie kablowym wynosi 1492. Jest to zbyt wysoki i spowoduje fragmentację. 1476 to magiczna liczba, która będzie działać z większością witryn. Niektóre witryny używają różnych implementacji SSL, więc 1480 może działać, a nawet 1488. Aby zapewnić zgodność z MOST, MTU po stronie WAN urządzenia sieciowego (routera, modemu itp.) Powinno wynosić 1476.

Oto kilka rzeczy do wypróbowania:

1. Sprawdź ustawienia karty sieciowej. Żaden z interfejsów Et nie wyświetla adresów IPv4. Upewnij się, że masz włączony IPv4 (może być konieczne ponowne ustanowienie połączenia z routerem w celu odnowienia adresu IP). Jeśli to nie zadziała, spróbuj wyłączyć obsługę IPv6 i sprawdź, czy to robi różnicę. Zrób to, klikając prawym przyciskiem myszy ikonę sieci przy zegarze (w przypadku połączenia Ethernet jest to para strzałek, jedna skierowana w górę, a druga w dół) i wybierając „Edytuj połączenia ...”. Na karcie „Ustawienia IPv4” upewnij się, że jest ustawiony na „Automatyczny (DHCP)”. Jeśli chcesz wyłączyć IPv6, przejdź do zakładki i ustaw „Ignoruj”.

2. Sprawdź, czy możesz połączyć się z witrynami przy użyciu innych metod. Z czym pingodpowiada witryny, z którymi nie można się połączyć? Co powiesz na traceroute(może być konieczne zainstalowanie traceroute, aby go użyć, FYI)? Ich odpowiedzi mogą pomóc w rozwiązaniu problemu. Jeśli nie mogą dostać się na serwery URL, może to być problem z DNS (jeśli jednak mogą dostać się na serwery URL, ale zostaną upuszczeni, może to oznaczać, że te polecenia są zablokowane).

3. Obejdź router. Jeśli router i modem to dwie różne maszyny, spróbuj podłączyć komputer bezpośrednio do modemu i sprawdź, czy to coś zmieni.

4. Uruchom ponownie modem i router. Czasami po prostu są do bani.

5. Zrestartuj swój komputer. Czasami po prostu są do bani.

6. Wypróbuj inny komputer. Jeśli masz taki komputer, czy inny komputer działa tam, gdzie nie działa? Jeśli nie, to może być coś z twoim komputerem.

7. Wyczyść pamięć podręczną komputera, pliki cookie itp. Czasami niepoprawne pliki cookie sesji, pamięć podręczna itp. Mogą zakłócać połączenie z witryną (jakiś czas temu miałem problem z Google). Wyczyść je i zacznij od nowa i zobacz, co dostajesz.

8. Odłącz wszelkie połączenia VPN. Protokół Point-to-Point jest często używany w sieci VPN (interfejs PPP), a sieci VPN mogą zakłócać połączenie z witrynami. Upewnij się, że nie jesteś połączony, klikając prawym przyciskiem myszy ikonę sieci obok zegara, znajdując pozycję „Połączenia VPN” i upewniając się, że żadne wpisy nie są zaznaczone (jeśli nie masz pozycji menu „Połączenia VPN”, nie „ mieć jeden skonfigurowany). Jeśli są zaznaczone, oznacza to, że jesteś z nim połączony, odłącz się od niego.

Pamiętaj: Nie wszystko, co robisz, spowoduje proste „działanie lub niepowodzenie”, każda zmiana reakcji serwera na twoje żądanie coś nam powie. Jeśli więc wykonasz którąkolwiek z powyższych czynności i otrzymasz nową wiadomość, nie zapomnij zaktualizować pytania.

Dwukrotnie widziałem to zachowanie w praktyce, dla którego znalazłem następujące rozwiązania.

• Niektóre komputery w sieci lokalnej próbowały z powodzeniem przeprowadzić atak typu man-in-the-middle. To ARP fałszował bramę, przekierowując cały ruch, aby przejść przez tę maszynę, modyfikując żądania i inne nieprzyjemne rzeczy. Na komputerze działał system Windows i wykryto, że jest zainfekowany złośliwym złośliwym oprogramowaniem. Gdy tylko urządzenie zostało fizycznie odłączone od sieci, objawy zniknęły.
• Problemem MTU na swojej lub innej bramy. W IPv4 bramy są odpowiedzialne za fragmentację i ponowne składanie pakietów IP w sieci, jeśli rozmiar ramki sieci, dla której kieruje ruch, nie jest taki sam. W przypadku połączeń DSL przy użyciu PPPoE / PPPoA rozmiar MTU jest zwykle mniejszy niż 1500 bajtów po stronie LAN. Również routery pomiędzy awariami i musisz włączyć Clamping TCP MSS na routerze. I zawsze potrzebne, aby ustawić to w związku z moim poprzednim ISP, ale to było coś więcej niż tylko rozwiązywanie problemów związanych z SSL. Sprawdź, czy modem / router ma taką opcję. Uznaj to za obejście.
• Byłem w sieci, prawdopodobnie z przezroczystym serwerem proxy, który również przesyła ruch SSL, ale z jakiegoś powodu zawiodłem w TLSv1. To samo żądanie działało podczas korzystania z połączenia VPN. straszne
  Spróbuj uruchomić curlz opcją --sslv3. Jeśli to rozwiązuje, to śmierdzi.

Ogólne rzeczy do wypróbowania:

• Sprawdź, czy korzystasz z najnowszego oprogramowania układowego modemu / routera. Jeśli nie, spróbuj zaktualizować.

• Przechwyć ruch za pomocą tcpdumplub Whireshark i poddaj go analizie (na przykład opublikuj tutaj).

    # 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
  

  Jeśli często występują błędy przy ponownym montażu lub utracony poprzedni segment , jest to wyraźny znak utraty pakietu spowodowanej niewłaściwym rozmiarem MTU.
  Jednak ruch HTTPS jest szyfrowany i sam w sobie jest trudny do analizy.

Edytować:

Z tcpdump korzeniem problemu SSL jest jasne: TCP Previous segment lost. Powinny tu obowiązywać ogólne rozwiązywanie problemów z siecią, ale może ona wykraczać poza zasięg sieci lokalnej i stanowić problem z dostawcą usług internetowych.

Cześć wszystkim, to jest marcovaleriof z Włoch, ostatnio mieliśmy problem podobny do waszego: cała nasza maszyna Linux nie mogła się już połączyć z dowolną witryną https, podczas gdy Android lub urządzenie z systemem Windows nie miało problemu. Problem polegał na tym, że mtu nie dostosowało się do naszego routera DSL o długości 1492 mtu i domyślnego mtu dla Linuxa, który jest 1500. W rzeczywistości faktem jest wydanie polecenia jako root

ifconfig wlan0 mtu 1492 up

(w języku angielskim ten zestaw Wartość mtu interfejsu netto - wlan0 w moim przypadku - do długości 1492) pozbyła się problemu, dziękuję! Mam nadzieję, że to może komuś pomóc.

Dzięki za wszelką pomoc problem został w końcu rozwiązany!

Próbowałem ograniczyć MTU, aby zobaczyć, czy to pomoże, i skończyło się pppoeconfna skonfigurowaniu połączenia PPPoE, ponieważ dla mnie ogranicza MTU. Następnie wyłączyłem wcześniej używane połączenie DSL.

Dla każdego, kto ma podobny problem, możesz wypróbować to rozwiązanie, wpisując sudo ppoeconfi postępując zgodnie z instrukcjami. Następnie możesz się połączyć pon adsl-provideri rozłączyć zpoff