ไม่สามารถเชื่อมต่อกับบางเว็บไซต์ HTTPS

12

ฉันเพิ่งย้ายไปอพาร์ทเมนต์ใหม่และด้วยการเชื่อมต่ออินเทอร์เน็ตผ่านเราเตอร์และฉันพบว่าฉันไม่สามารถเชื่อมต่อกับบางไซต์ที่ใช้ SSL

ตัวอย่างเช่นพยายามเชื่อมต่อกับ 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 ให้เอาต์พุตเดียวกัน

สำหรับบางเว็บไซต์ใช้งานได้:

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

ฉันใช้ Ubuntu 12.04 โดยติดตั้ง Windows 7 ด้วย เว็บไซต์เหล่านี้ทำงานบน Windows :(

ไม่แน่ใจว่าข้อมูลนี้ช่วย แต่ฉันวิ่งifconfigและได้รับต่อไปนี้:

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)

ฉันใช้ 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

และไม่มี 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  * * *

ไม่มี 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

นี่คือ ISP ของญี่ปุ่นและแม้ว่าฉันจะเชื่อมต่อด้วยสายเคเบิลไปยังโมเด็ม / เราเตอร์ฉันต้องเพิ่มชื่อผู้ใช้และรหัสผ่าน แต่ด้วยการเชื่อมต่อ "สาย" ของ Ubuntu ฉันไม่สามารถเพิ่มสิ่งเหล่านี้ได้ เพื่อนบ้านของฉันบอกให้ฉันสร้างการเชื่อมต่อ OCN แต่ฉันไม่แน่ใจว่าเป็นชื่อของเครือข่ายประเภทหนึ่งหรือเพียงแค่ บริษัท ญี่ปุ่น ... แต่หลังจากดูที่คอมพิวเตอร์ของเธอเราพบว่ามันเป็นการเชื่อมต่อ PPPoE หลังจาก googling ฉันได้เรียนรู้ว่าการสร้างการเชื่อมต่อ PPPoE ฉันจะต้องสร้างการเชื่อมต่อ DSL และฉันสามารถเพิ่มรหัสผ่าน & ชื่อผู้ใช้ลงในมันได้ ฉันเปลี่ยนการเชื่อมต่อแบบใช้สายเป็นไม่เชื่อมต่อโดยอัตโนมัติ

ฉันได้รับปัญหาเดียวกันหากเชื่อมต่อกับโมเด็มโดยตรง

ฉันได้ลองเปลี่ยน DSL MTU เป็น 500, 1500, 1492 และ 1482 แต่ก็ไม่ได้สร้างความแตกต่าง

ด้วยเหตุผลบางอย่างที่ Ubuntu ไม่ได้รับการเชื่อมต่อเสมอบางครั้งฉันต้องเริ่มต้นใหม่เพื่อเชื่อมต่อ

12.04  ssl  https 
— mind.blank
แหล่งที่มา
เว็บไซต์เหล่านี้ไม่เพียงเปิดcurlหรือไม่เปิดด้วยเบราว์เซอร์อื่นด้วยหรือไม่
— adempewolff
พวกเขาไม่ได้เปิดเลยฉันแค่พยายามหาว่าปัญหาอยู่ที่ไหน ...
— mind.blank
@ mind.blank - เบราว์เซอร์ให้อะไรคุณเมื่อคุณพยายามเชื่อมต่อ หากคุณไม่ได้รับสิ่งใดจากหน้าต่างหลักให้ลองติดตั้ง Firebug (หากคุณใช้ Firefox หากคุณใช้ Chrome จะมีเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ในตัว) เปิดและเปิดใช้งานคอนโซลและแท็บเน็ตและดูว่ามีหรือไม่ ข้อผิดพลาดใด ๆ จากนั้นรายงานที่นี่
— Shauna
คุณเคยใช้เราเตอร์มาก่อนหรือเป็นของใหม่ นอกจากนี้คุณยังไม่ได้ทำอะไรโง่ ๆ และอัพเกรดแพ็คเกจ SSL ของคุณหรืออะไรจากการติดตั้งเริ่มต้น? ฉันเข้าใช้งานเว็บไซต์เหล่านี้ได้ดี (อย่างน้อยก็ผ่านพร็อกซีของฉันอย่างน้อยจีนจะบล็อกโปรโตคอล ssl เป็นอย่างอื่น) ดังนั้นฉันจึงคาดเดาว่าปัญหาเกิดขึ้นกับเราเตอร์หรือแพ็กเกจที่ติดตั้ง / อัพเกรด
— adempewolff
@Shauna ฉันใช้ Chrome Error 7 (net::ERR_TIMED_OUT): The operation timed outและก็บอกว่า FireFox พยายามโหลด แต่ไม่เคยทำ (หน้าจะไม่เปลี่ยนแปลง) คอนโซลและเครือข่ายไม่ได้ให้อะไรฉัน ...
— mind.blank

คำตอบ:

11

นี่เป็นคำถามเก่า แต่สำหรับผู้ที่มาที่นี่ผ่านทาง Google สิ่งนี้จะช่วยได้ ปัญหาคือการกระจายตัวของ SSL ไม่ดีและแบ่งโปรโตคอล หากคุณใช้ PPPOE MTU ปกติในเราเตอร์ / DSL / เคเบิลโมเด็มของคุณคือ 1492 นั่นสูงเกินไปและจะทำให้เกิดการแตกแฟรกเมนต์ 1476 เป็นหมายเลขเวทย์มนตร์ที่สามารถใช้ได้กับเว็บไซต์ส่วนใหญ่ บางไซต์ใช้การใช้งาน SSL ที่แตกต่างกันดังนั้น 1480 อาจใช้งานได้หรืออาจเป็น 1488 สำหรับความเข้ากันได้มากที่สุด MTU บนฝั่ง WAN ของอุปกรณ์เครือข่ายของคุณ (เราเตอร์โมเด็ม ฯลฯ ) ควรเป็น 1476

— regretoverflow
แหล่งที่มา
1
ฉันไม่เห็นว่าการแตกแฟรกเมนต์จะทำลาย SSL อย่างไร แพ็คเก็ตที่แยกส่วนจะประกอบขึ้นใหม่โดยเราเตอร์ใน IPv4 SSL เกิดขึ้นบน TCP ในระดับที่คุณไม่ควรสังเกต ฉันคิดว่าสิ่งนี้เกี่ยวข้องกับค่า MTU แต่ฉันไม่คิดว่าคำอธิบายของคุณมีคุณสมบัติเหมาะสม ฉันคิดว่ามันเกี่ยวกับการตั้งค่า MTU ที่ไม่ซิงค์กันทั้งสองด้านส่งผลให้เกิดการรวมกลุ่มซ้ำของแพ็กเก็ตที่ผิดพลาด หมายเลขเวทย์มนตร์อาจทำงานได้ในกรณีของคุณ แต่ไม่ใช่สำหรับคนอื่น
— gertvdijk
บิต DF (Dont Fragment) จะถูกตั้งค่าเสมอในทราฟฟิก SSL โดยการออกแบบ - การแตกแฟรกเมนต์เป็นช่องโหว่ความปลอดภัย แพ็คเก็ต SSL แบบแยกส่วนจะได้รับลดลง 99.9% ของเวลา MTU ที่ต่ำเกินไปในการรับส่งข้อมูล PPoE จะทำให้เกิดการแตกแฟรกเมนต์
— เสียใจไหล
สิ่งนี้เกิดขึ้นกับฉันด้วยเว็บไซต์ PayPal ฉันพยายามที่จะตั้งถิ่นฐานกับ MTU 1476 และไม่ทำงาน แต่มี 1480 ทำงาน ขอขอบคุณ!
— ขี้เล่น
ฉันใช้เวลา 6 โมงเช้าถึงสองทุ่มพยายามแก้ปัญหานี้จนกว่าฉันจะพบคำตอบของคุณ ชื่นชมมาก!
— WayBehind
1
วัวศักดิ์สิทธิ์! สิ่งนี้ทำให้ฉันsudo yum install docker-engineเพิ่มหลังจากที่เพิ่ม yum.dockerproject.org ในกล่อง CentOS 7: sudo ip link set mtu 1476 dev enp6s0เพื่อลด MTU จากค่าเริ่มต้นที่ 1,500 ถึง 1476 ได้รับการเกาหัวของฉันเป็นเวลาหนึ่งวันเพื่อหาเหตุผลว่าทำไม yum.dockerproject.org เข้าถึงได้ ผ่าน https จากโหนดอื่น ๆ ในเครือข่ายเดียวกัน
— jwd630
3

ต่อไปนี้เป็นสิ่งที่ควรลอง:

  1. ตรวจสอบการตั้งค่าการ์ดเครือข่ายของคุณ ทั้งอินเตอร์เฟส eth ของคุณไม่แสดงที่อยู่ IPv4 ตรวจสอบให้แน่ใจว่าคุณเปิดใช้งาน IPv4 (คุณอาจต้องทำการเชื่อมต่อกับเราเตอร์ของคุณใหม่เพื่อต่ออายุ IP) หากวิธีนี้ไม่ได้ผลให้ลองปิดการสนับสนุน IPv6 และดูว่าสิ่งนั้นสร้างความแตกต่างหรือไม่ ทำได้โดยคลิกขวาที่ไอคอนเครือข่ายตามนาฬิกาของคุณ (เมื่อเชื่อมต่ออีเธอร์เน็ตจะมีลูกศรคู่หนึ่งชี้ขึ้นหนึ่งลงอีก) และเลือก "แก้ไขการเชื่อมต่อ ... " ในแท็บ "การตั้งค่า IPv4" ตรวจสอบให้แน่ใจว่าได้ตั้งค่าเป็น "อัตโนมัติ (DHCP)" หากคุณต้องการปิด IPv6 ไปที่แท็บและตั้งเป็น "ไม่สนใจ"

  2. ตรวจสอบเพื่อดูว่าคุณสามารถเชื่อมต่อกับไซต์โดยใช้วิธีการอื่นได้หรือไม่ สิ่งที่pingตอบสนองด้วยสำหรับเว็บไซต์ที่คุณไม่สามารถเชื่อมต่อได้ วิธีการเกี่ยวกับtraceroute(คุณอาจต้องติดตั้ง traceroute เพื่อใช้งาน FYI) คำตอบของพวกเขาอาจช่วยให้คุณแก้ไขปัญหาได้ หากพวกเขาไม่สามารถไปยังเซิร์ฟเวอร์ของ URL แสดงว่าอาจเป็นปัญหา DNS (อย่างไรก็ตามหากพวกเขาสามารถไปยังเซิร์ฟเวอร์ของ URL แต่ถูกทิ้งไปก็อาจหมายถึงคำสั่งเหล่านั้นถูกบล็อก)

  3. บายพาสเราเตอร์ หากเราเตอร์และโมเด็มของคุณเป็นเครื่องที่แตกต่างกันสองเครื่องให้ลองเชื่อมต่อคอมพิวเตอร์ของคุณเข้ากับโมเด็มโดยตรงและดูว่ามันเปลี่ยนแปลงอะไรหรือไม่

  4. รีสตาร์ทโมเด็มและเราเตอร์ของคุณ บางครั้งพวกเขาก็ดูด

  5. รีสตาร์ทคอมพิวเตอร์ของคุณ บางครั้งพวกเขาก็ดูด

  6. ลองใช้คอมพิวเตอร์เครื่องอื่น หากคุณมีคอมพิวเตอร์เครื่องอื่นจะทำงานที่เครื่องนี้ไม่ทำงานหรือไม่ ถ้าไม่เช่นนั้นคอมพิวเตอร์ของคุณอาจมีบางอย่าง

  7. ล้างแคชคอมพิวเตอร์คุกกี้ของคุณในบางครั้งคุกกี้เซสชันที่ไม่ดีแคช ฯลฯ อาจรบกวนการเชื่อมต่อกับไซต์ (ฉันมีปัญหากับ Google มาระยะหนึ่งแล้ว) ล้างพวกเขาออกและเริ่มต้นใหม่และดูสิ่งที่คุณได้รับ

  8. ตัดการเชื่อมต่อ VPN ใด ๆ โปรโตคอลแบบจุดต่อจุดมักใช้สำหรับ VPN (อินเตอร์เฟส PPP) และ VPN สามารถรบกวนการเชื่อมต่อกับไซต์ ตรวจสอบให้แน่ใจว่าคุณไม่ได้เชื่อมต่อด้วยการคลิกขวาที่ไอคอนเครือข่ายของคุณตามเวลาของคุณค้นหารายการ "การเชื่อมต่อ VPN" และตรวจสอบให้แน่ใจว่าไม่มีการตรวจสอบรายชื่อ (ถ้าคุณไม่มีรายการเมนู "การเชื่อมต่อ VPN" ไม่มีการตั้งค่าหนึ่ง) หากมีการตรวจสอบใด ๆ แสดงว่าคุณเชื่อมต่อแล้วยกเลิกการเชื่อมต่อ

โปรดจำไว้ว่า:ไม่ใช่ทุกสิ่งที่คุณทำจะส่งผลให้ "ทำงานหรือล้มเหลว" อย่างง่ายการเปลี่ยนแปลงใด ๆในการตอบสนองของเซิร์ฟเวอร์ต่อคำขอของคุณจะบอกอะไรเรา ดังนั้นหากคุณทำสิ่งใด ๆ ข้างต้นและได้รับข้อความใหม่อย่าลืมอัปเดตคำถามของคุณ

— ชอว์นา
แหล่งที่มา
1) ขออภัยไม่แน่ใจว่าจะทำสิ่งเหล่านี้ได้อย่างไร cyberciti.biz/faq/setting-up-an-network-interfaces-file - ไม่แน่ใจว่าจะเพิ่มที่อยู่ IP ใด 2) ฉันได้เพิ่มทั้งคู่ในคำถามเดิม 3) ฉันจะดูว่าฉันมีตัวเลือกนั้นพรุ่งนี้ (โมเด็ม ฯลฯ อยู่ในห้องของเพื่อนร่วมห้อง) 4) เหมือนข้างบนแม้ว่าฉันจะรีสตาร์ทเราเตอร์อย่างน้อย 5) พยายามสักครั้ง 6) ฉันไม่มีคอมพ์อื่น ๆ ที่มี Ubuntu, การเชื่อมต่อเหล่านี้ทำงานได้ แต่เมื่อฉันเปลี่ยนเป็น Windows 7) พยายามอย่างนั้น
— mind.blank
@ mind.blank คุณไม่จำเป็นต้องทำอะไรเลยในลิงค์ เพียงคลิกขวาที่ไอคอนเครือข่ายโดยนาฬิกาและเลือก "แก้ไขการเชื่อมต่อ ... " คลิกที่การเชื่อมต่อและเลือก "แก้ไข" และเลือกแท็บ "การตั้งค่า IPv4" และตรวจสอบให้แน่ใจว่าได้ตั้งค่าเป็น "อัตโนมัติ (DHCP)" จากนั้นไปที่แท็บ "การตั้งค่า IPv6" และตรวจสอบให้แน่ใจว่าได้ยกเลิกการทำเครื่องหมาย "ต้องใช้ที่อยู่ IPv6 เพื่อให้การเชื่อมต่อนี้เสร็จสมบูรณ์" บันทึกและเชื่อมต่อใหม่ หาก / เมื่อคุณต้องการปิด IPv6 ให้กลับมาที่แท็บการตั้งค่า IPv6 และเปลี่ยน "อัตโนมัติ" เป็น "ไม่สนใจ"
— Shauna
ในการเชื่อมต่อเครือข่าย> DSL> แก้ไขการตั้งค่า IPv4 นั้นเป็น "อัตโนมัติ (PPPoE)" และไม่มีแท็บ IPv6 ...
— mind.blank
2

ฉันได้เห็นพฤติกรรมนี้สองครั้งในทางปฏิบัติซึ่งฉันได้พบวิธีแก้ไขปัญหาต่อไปนี้

  • คอมพิวเตอร์บางเครื่องในเครือข่ายท้องถิ่นพยายามโจมตีคนที่อยู่ตรงกลางได้สำเร็จ มันเป็น ARP การปลอมแปลงเกตเวย์ดังนั้นการเปลี่ยนเส้นทางการรับส่งข้อมูลทั้งหมดเพื่อให้ผ่านเครื่องนี้การปรับเปลี่ยนคำขอและสิ่งที่น่ารังเกียจอื่น ๆ เครื่องใช้ Windows และพบว่าติดมัลแวร์ที่น่ารังเกียจ ทันทีที่เครื่องนี้ถูกตัดการเชื่อมต่อจากเครือข่ายร่างกายอาการหายไป
  • ปัญหา MTUบนเกตเวย์ของคุณหรืออื่น ในเกตเวย์ IPv4 มีหน้าที่รับผิดชอบในการแยกส่วนและประกอบแพ็กเก็ต IP บนเครือข่ายอีกครั้งหากขนาดเฟรมของเครือข่ายที่มีการรับส่งข้อมูลเส้นทางนั้นไม่เหมือนกัน สำหรับการเชื่อมต่อ DSL โดยใช้ PPPoE / PPPoA ขนาด MTU มักจะเล็กกว่า 1500 ไบต์ที่ด้าน LAN นอกจากนี้เราเตอร์ในระหว่างล้มเหลวและคุณต้องเปิดใช้งานTCP MSS Clampingบนเราเตอร์ของคุณ ฉันจำเป็นต้องตั้งค่านี้เสมอในการเชื่อมต่อกับ ISP ก่อนหน้าของฉัน แต่มันก็แก้ไขปัญหาที่เกี่ยวข้องกับ SSL มากกว่า ตรวจสอบว่าโมเด็ม / เราเตอร์ของคุณมีตัวเลือกดังกล่าวหรือไม่ คิดว่านี่เป็นวิธีแก้ปัญหา
  • ฉันอยู่ในเครือข่ายอาจเรียกใช้พร็อกซีแบบโปร่งใสเพื่อส่งทราฟฟิก SSL แต่ล้มเหลวที่ TLSv1 ด้วยเหตุผลบางอย่าง คำขอเดียวกันนี้ทำงานเมื่อใช้การเชื่อมต่อ VPN น่ากลัว
    ลองใช้กับตัวเลือกcurl --sslv3ถ้านั่นแก้ปัญหาได้แล้วมันก็จะเหม็น

สิ่งทั่วไปที่ควรลอง:

  • ตรวจสอบว่าคุณใช้เฟิร์มแวร์ล่าสุดบนโมเด็ม / เราเตอร์ของคุณหรือไม่ ถ้าไม่ลองอัพเกรด

  • จับภาพการจราจรโดยใช้tcpdumpหรือ Whireshark และทำการวิเคราะห์ (โพสต์ไว้ที่นี่เป็นต้น)

      # 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

    หากคุณได้รับข้อผิดพลาดในการรวบรวมซ้ำหรือส่วนก่อนหน้าหายไปซ้ำ ๆ นี่เป็นสัญญาณที่ชัดเจนเกี่ยวกับการสูญเสียแพ็กเก็ตที่เกิดจากขนาด MTU ผิด
    อย่างไรก็ตามการรับส่งข้อมูล HTTPS ถูกเข้ารหัสและยากที่จะวิเคราะห์จากการรับส่งข้อมูลเครือข่ายด้วยตัวเอง

แก้ไข:

จาก tcpdump ของคุณรากของปัญหา SSL TCP Previous segment lostของคุณมีความชัดเจน: ควรใช้การแก้ไขปัญหาเครือข่ายทั่วไปที่นี่ แต่อาจอยู่นอกขอบเขตเครือข่ายท้องถิ่นของคุณและปัญหากับ ISP ของคุณ

— gertvdijk
แหล่งที่มา
ฉันลองใช้ curl --sslv3แล้ว แต่ก็ยังใช้งานไม่ได้ นอกจากนี้ฉันพยายามจับดัมพ์ แต่ดูเหมือนจะไม่ทำงานใช่ไหม tcpdump: WARNING: eth0: no IPv4 address assigned 0 packets captured 6 packets received by filter 0 packets dropped by kernel- ฉันไม่แน่ใจว่าจะกำหนด IPv4 ได้อย่างไรฉันจะต้องลองใช้ที่เหลือในวันพรุ่งนี้เพราะมันจะสายและสมองของฉันทำงานได้ไม่ดี ขอบคุณสำหรับความช่วยเหลือของคุณทุกคน!
— mind.blank
@ mind.blank สำหรับคุณมันเป็นppp0ส่วนต่อประสานแทนที่จะeth0ทำให้ฉันคิดว่า: ทำไมคุณต้องใช้ PPP สำหรับการเชื่อมต่อเมื่อใช้เราเตอร์?
— gertvdijk
การเชื่อมต่อแบบใช้สาย "แบบปกติ" ไม่ช่วยอะไรเลย ตอนนี้ฉันได้เพิ่ม tcpdump ที่ด้านล่างของคำถามของฉันพร้อมรายละเอียดเพิ่มเติมเกี่ยวกับสาเหตุที่ฉันใช้ PPPoE นอกจากนี้หากคุณต้องการข้อมูลเพิ่มเติมจากการถ่ายโอนข้อมูลโปรดบอกฉัน
— mind.blank
@ mind.blank การถ่ายโอนข้อมูลมีประโยชน์มาก แต่ไม่ได้ชี้ไปที่โซลูชันเลย ดูคำตอบที่อัปเดตของฉัน
— gertvdijk
0

สวัสดีทุกคนนี่คือ marcovaleriof จากอิตาลีเมื่อเร็ว ๆ นี้เรามีปัญหาคล้ายกับของคุณ: เครื่อง Linux ทั้งหมดของเราไม่สามารถเชื่อมต่อกับเว็บไซต์ https ได้อีกต่อไปในขณะที่ Android หรืออุปกรณ์ Windows ไม่มีปัญหา ปัญหาคือการไม่ลงรอยกัน mtu ระหว่างเราเตอร์ DSL ของเราซึ่งมีความยาว 1492 mtu และ Linux mtu เริ่มต้นที่ 1500 ซึ่งเป็นข้อเท็จจริงของการออกคำสั่งนี้ในฐานะที่เป็นราก

ifconfig wlan0 mtu 1492 up

(ในภาษาอังกฤษชุดนี้ค่า mtu ของอินเทอร์เฟซสุทธิ - wlan0 ในกรณีของฉัน - ความยาว 1492) ได้กำจัดปัญหาขอบคุณ! หวังว่านี่จะช่วยคนได้

— marcovaleriof
แหล่งที่มา
-2

ขอบคุณสำหรับความช่วยเหลือของคุณปัญหาได้รับการแก้ไขในที่สุด!

ฉันพยายาม จำกัด MTU เพื่อดูว่าจะช่วยและสิ้นสุดการใช้pppoeconfเพื่อตั้งค่าการเชื่อมต่อ PPPoE หรือไม่เนื่องจากมัน จำกัด MTU สำหรับฉัน ฉันปิดใช้งานการเชื่อมต่อ DSL ที่ฉันใช้ก่อนหน้านี้

สำหรับใครก็ตามที่ประสบปัญหาคล้ายกันคุณสามารถลองใช้วิธีแก้ไขปัญหานี้ได้โดยพิมพ์sudo ppoeconfและทำตามคำแนะนำ จากนั้นคุณสามารถเชื่อมต่อpon adsl-providerและยกเลิกการเชื่อมต่อได้poff

— mind.blank
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.