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

12

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

12.04 ssl https

— mind.blank
źródło

czy te strony nie otwierają curlsię tylko za pomocą innych przeglądarek?

— adempewolff,

W ogóle się nie otwierają, tylko próbowałem dowiedzieć się, gdzie jest problem ...

— mind.blank

@ mind.blank - Co daje przeglądarka, gdy próbujesz się połączyć? Jeśli nic nie dostajesz z głównego okna, spróbuj zainstalować Firebug (jeśli używasz Firefox; jeśli używasz Chrome, ma wbudowane narzędzia programistyczne), otwórz go i aktywuj konsolę i karty sieciowe i sprawdź, czy są wszelkie błędy, a następnie zgłoś je tutaj.

— Shauna

Czy korzystałeś już z routera, czy jest nowy? Ponadto, nie zrobiłeś nic głupiego i nie zaktualizowałeś swoich pakietów ssl ani niczego z domyślnej instalacji? Dostęp do wszystkich tych stron jest dobry (cóż, przynajmniej przez mój serwer proxy Chiny losowo blokują protokół ssl w przeciwnym razie), więc zgaduję, że problem leży po stronie routera lub uaktualnionego / zainstalowanego pakietu.

— adempewolff,

@Shauna Używam Chrome i to mówi Error 7 (net::ERR_TIMED_OUT): The operation timed out. FireFox po prostu próbuje się załadować, ale nigdy tego nie robi (strona się nie zmienia). Konsola i sieć nic mi nie dają ...

— mind.blank

11

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.

— regretoverflow
źródło

1

Nie widzę, jak fragmentacja złamie SSL. Pofragmentowane pakiety zostaną ponownie złożone przez routery w IPv4. SSL odbywa się na TCP, na poziomie, na którym nie powinieneś tego zauważać. Myślę, że ma to związek z wartościami MTU, ale nie sądzę, by twoje wyjaśnienie się kwalifikowało. Myślę, że ma to związek z ustawieniami MTU, które nie są zsynchronizowane na obu końcach, co powoduje nieprawidłowe składanie pofragmentowanych pakietów. Magiczna liczba może działać w twoim przypadku, ale nie dla innych.

— gertvdijk

Bit DF (Dont Fragment) jest zawsze ustawiony na ruch SSL zgodnie z projektem - fragmentacja jest luką w zabezpieczeniach. Rozdrobniony pakiet SSL zostanie upuszczony w 99,9% przypadków. Zbyt niska MTU dla ruchu PPoE spowoduje fragmentację.

— regretoverflow

Tak stało się ze stroną PayPal. Próbowałem się zadowolić z MTU 1476 i nie działałem, ale z 1480 pracował. Dziękuję Ci!

— zabawny

Próbowałem rozwiązać ten problem, dopóki nie znalazłem twojej odpowiedzi. Bardzo mile widziane!

— WayBehind,

1

święta krowa! Umożliwiło mi to sudo yum install docker-enginepo dodaniu repozytorium yum.dockerproject.org na pudełku CentOS 7: sudo ip link set mtu 1476 dev enp6s0obniżenie MTU z domyślnej wartości 1500 do 1476. Drapałem się po głowie, próbując dowiedzieć się, dlaczego yum.dockerproject.org jest dostępny przez https z innych węzłów w tej samej sieci.

— jwd630,

3

Oto kilka rzeczy do wypróbowania:

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”.
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).
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.
Uruchom ponownie modem i router. Czasami po prostu są do bani.
Zrestartuj swój komputer. Czasami po prostu są do bani.
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.
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.
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.

— Shauna
źródło

1) Niestety nie jestem pewien, jak zrobić obie te rzeczy. cyberciti.biz/faq/setting-up-an-network-interfaces-file - nie wiem, jakie adresy IP dodać. 2) Dodałem oba z oryginalnego pytania. 3) Zobaczę, czy jutro mam tę opcję (modem itp. Jest w pokoju współlokatora). 4) To samo co powyżej, chociaż zrestartowałem router przynajmniej. 5) Próbowałem kilka razy. 6) Nie mam innej kompilacji z Ubuntu, połączenia te działają jednak po przejściu na Windows. 7) Próbowałem tego.

— mind.blank 17.09.12

@ mind.blank Nie musisz nic robić w linku. Po prostu kliknij prawym przyciskiem myszy ikonę sieci i wybierz „Edytuj połączenia ...”. Kliknij połączenie i wybierz „Edytuj”, wybierz kartę „Ustawienia IPv4” i upewnij się, że jest ustawione na „Automatyczny (DHCP)”. Następnie przejdź do zakładki „Ustawienia IPv6” i upewnij się, że „Wymagaj adresowania IPv6 do zakończenia tego połączenia” nie jest zaznaczone. Zapisz i połącz ponownie. Jeśli / kiedy chcesz wyłączyć IPv6, wróć do karty Ustawienia IPv6 i zmień opcję „Automatyczny” na „Ignoruj”.

— Shauna

W Połączenia sieciowe> DSL> Edycja, ustawienia IPv4 są

— ustawione

2

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.

— gertvdijk
źródło

Próbowałem uruchomić curl z --sslv3i nadal nie działa. Próbowałem także przechwycić zrzut, ale wydaje się, że nie działa? tcpdump: WARNING: eth0: no IPv4 address assigned 0 packets captured 6 packets received by filter 0 packets dropped by kernel- Nie jestem pewien, jak przypisać IPv4 ... będę musiał wypróbować resztę jutro, ponieważ robi się późno i mój mózg nie działa dobrze. Dziękujemy za pomoc wszystkim do tej pory!

— mind.blank 17.09.12

@ mind.blank Dla ciebie jest to ppp0interfejs zamiast tego, eth0który każe mi myśleć: Dlaczego potrzebujesz PPP do połączenia podczas korzystania z routera?

— gertvdijk

Normalne połączenie „przewodowe” niczego nie odebrało. Dodałem teraz tcpdump na dole mojego pytania z kilkoma szczegółami na temat tego, dlaczego używam PPPoE. Również jeśli potrzebujesz więcej informacji ze zrzutu, proszę powiedz mi.

— mind.blank

@ mind.blank Zrzut jest bardzo przydatny, ale nie wskazuje na rozwiązanie. Zobacz moją zaktualizowaną odpowiedź.

— gertvdijk

0

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.

— marcovaleriof
źródło

-2

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

— mind.blank
źródło