Tidak dapat terhubung ke situs HTTPS tertentu

12

Saya baru saja pindah ke apartemen baru dan dengan koneksi internet melalui router dan saya menemukan bahwa saya tidak dapat terhubung ke beberapa situs yang menggunakan SSL.

Misalnya mencoba terhubung ke 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 memberikan hasil yang sama.

Untuk beberapa situs berfungsi:

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

Saya menggunakan Ubuntu 12.04, dengan Windows 7 diinstal juga. Situs-situs ini bekerja pada Windows :(

Tidak yakin apakah informasi ini membantu tetapi saya berlari ifconfigdan mendapatkan yang berikut:

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)

Saya sudah menjalankan 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

Dan tanpa 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  * * *

tanpa 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

Ini adalah ISP Jepang dan meskipun saya terhubung dengan kabel ke modem / router saya perlu menambahkan nama pengguna dan kata sandi, tetapi dengan koneksi "Wired" Ubuntu saya tidak bisa menambahkan ini. Teman serumah saya mengatakan kepada saya untuk membuat koneksi OCN tetapi saya tidak yakin apakah itu nama jenis jaringan atau hanya perusahaan Jepang ... tetapi setelah melihat komputernya kami menemukan itu sebagai koneksi PPPoE. Setelah beberapa googling saya belajar bahwa untuk membuat koneksi PPPoE saya perlu membuat koneksi DSL dan saya bisa menambahkan kata sandi & nama pengguna untuk itu. Saya juga mengubah koneksi "Wired" untuk tidak terhubung secara otomatis.

Saya mendapatkan masalah yang sama jika saya menghubungkan ke modem secara langsung.

Saya sudah mencoba mengubah MTU DSL ke 500, 1500, 1492 dan 1482 tetapi tidak ada bedanya.

Juga karena suatu alasan Ubuntu tidak selalu mengambil koneksi, kadang-kadang saya harus me-restart agar terhubung.

12.04 ssl https

— pikiran
sumber

apakah situs-situs ini tidak hanya dibuka dengan curlatau tidak dibuka dengan browser lain juga?

— adempewolff

Mereka tidak membuka sama sekali, saya hanya mencoba mencari tahu di mana masalahnya ...

— mind.blank

@ mind.blank - Apa yang diberikan browser saat Anda mencoba terhubung? Jika Anda tidak mendapatkan apa pun dari jendela utama, coba instal Firebug (jika Anda menggunakan Firefox; jika Anda menggunakan Chrome, ia memiliki alat pengembang bawaan), buka, dan aktifkan konsol dan tab bersih dan lihat apakah ada kesalahan, lalu laporkan di sini.

— Shauna

Apakah Anda menggunakan router sebelum atau itu baru? Juga, Anda belum melakukan sesuatu yang konyol dan memutakhirkan paket ssl Anda atau apa pun dari instalasi default? Saya mengakses semua situs tersebut dengan baik (baik, setidaknya melalui proxy saya, China secara acak memblokir protokol ssl), jadi saya menduga masalahnya terletak pada router atau dengan paket yang ditingkatkan / diinstal.

— adempewolff

@Shauna Saya menggunakan Chrome dan katanya Error 7 (net::ERR_TIMED_OUT): The operation timed out. FireFox terus mencoba memuat tetapi tidak pernah berhasil (halaman tidak berubah). Konsol dan Jaringan tidak memberi saya apa pun ...

— mind.blank

11

Ini adalah pertanyaan lama, tetapi bagi mereka yang datang ke sini melalui Google, ini akan membantu. Masalahnya adalah fragmentasi pada SSL buruk, dan melanggar protokol. Jika Anda menggunakan PPPOE, MTU normal di router / modem DSL / Kabel Anda adalah 1492. Itu terlalu tinggi, dan akan menyebabkan fragmentasi. 1476 adalah angka ajaib yang akan bekerja dengan sebagian besar situs. Beberapa situs menggunakan implementasi SSL yang berbeda sehingga 1480 dapat berfungsi, atau bahkan 1488. Untuk kompatibilitas PALING, MTU di sisi WAN perangkat jaringan Anda (router, modem, dll) harus 1476.

— aliran menyesal
sumber

1

Saya tidak melihat bagaimana fragmentasi akan merusak SSL. Paket yang terfragmentasi akan dipasang kembali oleh router di IPv4. SSL terjadi di atas TCP, pada tingkat di mana Anda seharusnya tidak melihat ini. Saya pikir ini ada hubungannya dengan nilai-nilai MTU, tapi saya pikir penjelasan Anda tidak memenuhi syarat. Saya pikir itu ada hubungannya dengan pengaturan MTU yang tidak sinkron di kedua ujungnya, yang mengakibatkan kesalahan pemasangan kembali paket yang terfragmentasi. Angka ajaib mungkin berfungsi dalam kasus Anda, tetapi tidak untuk orang lain.

— gertvdijk

Bit DF (Dont Fragment) selalu ditetapkan pada lalu lintas SSL dengan desain - fragmentasi adalah lubang keamanan. Paket SSL terfragmentasi akan turun 99,9% dari waktu. MTU yang terlalu rendah pada lalu lintas PPoE akan menyebabkan fragmentasi.

— regretoverflow

Ini terjadi pada saya dengan situs web PayPal. Saya mencoba untuk menyelesaikan dengan MTU 1476 dan tidak berhasil, tetapi dengan 1480 bekerja. Terima kasih!

— main main

Saya menghabiskan jam 6 pagi - 2 sore mencoba menyelesaikannya sampai saya menemukan jawaban Anda. Sangat dihargai!

— WayBehind

1

Astaga! Ini memungkinkan saya untuk sudo yum install docker-enginesetelah menambahkan repo yum.dockerproject.org pada kotak CentOS 7: sudo ip link set mtu 1476 dev enp6s0untuk menurunkan MTU dari standarnya dari 1500 menjadi 1476. Telah menggaruk-garuk kepala saya selama sehari mencoba mencari tahu mengapa yum.dockerproject.org dapat diakses via https dari node lain di jaringan yang sama.

— jwd630

3

Berikut adalah beberapa hal untuk dicoba:

Periksa pengaturan kartu jaringan Anda. Tidak satu pun dari antarmuka et Anda yang menunjukkan alamat IPv4. Pastikan IPv4 Anda telah dihidupkan (Anda mungkin perlu membangun kembali koneksi Anda dengan router Anda untuk memperbarui IP). Jika itu tidak berhasil, coba matikan dukungan IPv6 dan lihat apakah itu membuat perbedaan. Lakukan ini dengan mengklik kanan ikon jaringan pada jam Anda (ketika pada koneksi Ethernet, itu adalah sepasang panah, satu mengarah ke atas, yang lainnya ke bawah) dan memilih "Edit Koneksi ...". Di tab "Pengaturan IPv4", pastikan itu diatur ke "Otomatis (DHCP)". Jika Anda ingin mematikan IPv6, buka tabnya dan atur ke "Ignore".
Periksa untuk melihat apakah Anda dapat terhubung ke situs menggunakan metode lain. Apa pingtanggapan untuk situs yang tidak dapat Anda hubungkan? Bagaimana dengan traceroute(Anda mungkin harus menginstal traceroute untuk menggunakannya, FYI)? Respons mereka mungkin membantu Anda memecahkan masalah. Jika mereka tidak bisa sampai ke server URL, maka itu mungkin masalah DNS (namun, jika mereka bisa sampai ke server URL, tetapi kemudian dibatalkan, itu mungkin berarti perintah-perintah itu diblokir).
Lewati router. Jika router dan modem Anda adalah dua mesin yang berbeda, coba menghubungkan komputer Anda langsung ke modem Anda dan melihat apakah itu mengubah apa pun.
Mulai ulang modem dan router Anda. Terkadang, mereka hanya payah.
Hidupkan Kembali komputer Anda. Terkadang, mereka hanya payah.
Coba komputer lain. Jika Anda memilikinya, apakah komputer lain berfungsi di tempat yang ini gagal? Jika tidak, maka mungkin ada sesuatu dengan komputer spesifik Anda.
Bersihkan cache komputer Anda, cookie, dll. Kadang-kadang, cookie sesi buruk, cache, dll dapat mengganggu menghubungkan ke situs (saya memiliki masalah ini dengan Google beberapa waktu lalu). Bersihkan dan mulai segar dan lihat apa yang Anda dapatkan.
Putuskan koneksi VPN apa pun. Protokol point-to-Point sering digunakan untuk VPN (antarmuka PPP), dan VPN dapat mengganggu koneksi ke situs. Pastikan Anda tidak terhubung dengan mengklik kanan ikon jaringan Anda pada jam Anda, menemukan entri "Koneksi VPN" dan memastikan tidak ada daftar yang dicentang (jika Anda tidak memiliki item menu "Koneksi VPN", maka Anda tidak perlu t punya satu set up). Jika ada yang diperiksa, maka Anda terhubung ke sana, lepaskan dari itu.

Ingat: Tidak semua yang Anda lakukan akan menghasilkan "pekerjaan atau kegagalan" sederhana, setiap perubahan dalam reaksi server terhadap permintaan Anda akan memberi tahu kami sesuatu. Jadi, jika Anda melakukan salah satu dari yang di atas dan mendapatkan pesan baru, jangan lupa untuk memperbarui pertanyaan Anda.

— Shauna
sumber

1) Maaf tidak yakin bagaimana melakukan kedua hal ini. cyberciti.biz/faq/setting-up-an-network-interfaces-file - tidak yakin alamat IP apa yang akan ditambahkan. 2) Saya telah menambahkan keduanya dalam pertanyaan awal. 3) Saya akan melihat apakah saya memiliki opsi itu besok (modem dll ada di kamar roomate). 4) Sama seperti di atas walaupun saya telah me-restart router setidaknya. 5) Mencoba beberapa kali. 6) Saya tidak punya komputer lain dengan ubuntu, koneksi ini berfungsi ketika saya beralih ke Windows. 7) Mencoba itu.

— mind.blank

@ mind.blank Anda tidak perlu melakukan hal semacam itu di tautan. Cukup klik kanan ikon jaringan pada jam dan pilih "Edit Koneksi ...". Klik pada koneksi dan pilih "Edit" dan pilih tab "Pengaturan IPv4" dan pastikan itu diatur ke "Otomatis (DHCP)". Lalu buka tab "Pengaturan IPv6" dan pastikan "Memerlukan pengalamatan IPv6 agar koneksi ini selesai" tidak dicentang. Simpan dan hubungkan kembali. Jika / ketika Anda ingin mematikan IPv6, maka kembali ke tab Pengaturan IPv6 dan ubah "Otomatis" menjadi "Abaikan".

— Shauna

Di Koneksi Jaringan> DSL> Edit, pengaturan IPv4 berada di "Otomatis (PPPoE)" dan tidak ada tab IPv6 ...

— mind.blank

2

Saya telah melihat perilaku ini dua kali dalam praktiknya dan saya menemukan solusi berikut.

Beberapa komputer di jaringan lokal berhasil mencoba serangan man-in-the-middle. Itu adalah ARP-spoofing gateway, sehingga mengarahkan semua lalu lintas untuk melewati mesin ini, memodifikasi permintaan dan hal-hal buruk lainnya. Mesin itu menjalankan Windows dan ternyata terinfeksi beberapa malware jahat. Segera setelah mesin ini terputus dari jaringan secara fisik, gejala menghilang.
Sebuah masalah MTU pada Anda atau yang lain gateway. Dalam gateway IPv4 bertanggung jawab untuk memecah-mecah dan merakit kembali paket IP di jaringan jika ukuran bingkai jaringan yang digunakan untuk mengarahkan lalu lintas tidak sama. Untuk koneksi DSL menggunakan PPPoE / PPPoA ukuran MTU biasanya lebih kecil dari 1500 byte di sisi LAN. Juga router di antara gagal dan Anda perlu mengaktifkan TCP MSS Clamping pada router Anda. Saya selalu perlu mengatur ini pada koneksi ISP saya sebelumnya, tetapi itu menyelesaikan lebih dari sekedar masalah yang berhubungan dengan SSL. Periksa apakah modem / router Anda memiliki opsi seperti itu. Anggap ini sebagai solusi.
Saya berada di jaringan mungkin menjalankan proxy transparan untuk juga melewati lalu lintas SSL, tetapi gagal di TLSv1 karena beberapa alasan. Permintaan yang sama berfungsi saat menggunakan koneksi VPN. menakutkan
Coba jalankan curldengan opsi --sslv3. Jika itu menyelesaikannya, maka itu busuk.

Hal-hal umum untuk dicoba:

Periksa apakah Anda menjalankan firmware terbaru pada modem / router Anda. Jika tidak, coba perbarui.
Abadikan lalu lintas menggunakan tcpdumpatau Whireshark dan dapatkan dianalisis (poskan di sini misalnya).
```
  # 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
```
Jika Anda mengalami kesalahan pemasangan kembali atau segmen sebelumnya hilang berulang kali, ini adalah tanda yang jelas tentang kehilangan paket yang disebabkan oleh ukuran MTU yang salah.
Namun, lalu lintas HTTPS dienkripsi dan sulit dianalisis dari lalu lintas jaringan dengan sendirinya.

Edit:

Dari tcpdump Anda akar masalah SSL Anda jelas: TCP Previous segment lost. Pemecahan masalah jaringan umum harus berlaku di sini, tetapi mungkin di luar ruang lingkup jaringan lokal Anda dan masalah dengan ISP Anda.

— gertvdijk
sumber

Saya sudah mencoba menjalankan ikal --sslv3dan masih tidak berhasil. Saya juga mencoba menangkap dump tetapi sepertinya tidak berfungsi? tcpdump: WARNING: eth0: no IPv4 address assigned 0 packets captured 6 packets received by filter 0 packets dropped by kernel- Saya tidak yakin bagaimana menetapkan IPv4 ... saya harus mencoba sisanya besok karena sudah larut dan otak saya tidak berfungsi dengan baik. Terima kasih atas bantuan Anda, semuanya, sejauh ini!

— mind.blank

@ mind.blank Bagi Anda itu adalah ppp0antarmuka dan bukan eth0yang membuat saya berpikir: Mengapa Anda perlu PPP untuk koneksi saat menggunakan router?

— gertvdijk

Koneksi "Wired" normal tidak mengambil apa pun. Saya sekarang telah menambahkan tcpdump di bagian bawah pertanyaan saya dengan beberapa detail lebih lanjut tentang mengapa saya menggunakan PPPoE. Juga jika Anda memerlukan informasi lebih lanjut dari dump tolong beri tahu saya.

— mind.blank

@ mind.blank Dump sangat berguna, tetapi tidak menunjuk ke solusi saja. Lihat jawaban saya yang diperbarui.

— gertvdijk

0

Hai, semua orang, ini ISMC dari Italia, baru-baru ini kami memiliki masalah yang serupa dengan Anda: semua mesin Linux kami tidak dapat terhubung lagi ke situs web https sementara Android atau Perangkat Windows tidak memiliki masalah. Masalahnya adalah ketidaksejajaran mtu antara router DSL kami yang memiliki panjang 1492 mtu dan Linux mtu default IS 1500. Faktanya mengeluarkan perintah ini sebagai root

ifconfig wlan0 mtu 1492 up

(dalam bahasa Inggris set ini Nilai mtu dari antarmuka internet - wlan0 dalam kasus saya - untuk 1492 panjang) telah menyingkirkan masalah, terima kasih! Semoga ini bisa membantu seseorang.

— marcovaleriof
sumber

-2

Terima kasih atas semua bantuan Anda, masalahnya akhirnya diperbaiki!

Saya mencoba membatasi MTU untuk melihat apakah itu akan membantu dan akhirnya menggunakan pppoeconfuntuk mengatur koneksi PPPoE karena membatasi MTU untuk saya. Saya kemudian menonaktifkan koneksi DSL yang sebelumnya saya gunakan.

Bagi siapa pun yang mengalami masalah serupa, Anda dapat mencoba solusi ini dengan mengetik sudo ppoeconfdan mengikuti instruksi. Kemudian Anda dapat terhubung dengan pon adsl-providerdan memutuskanpoff

— pikiran
sumber