Belirli HTTPS sitelerine bağlanılamıyor

Yeni bir daireye taşındım ve bir yönlendirici üzerinden internet bağlantısı ile ve SSL kullanan birkaç siteye bağlanamadığımı görüyorum.

Örneğin, PayPal'a bağlanmaya çalışmak:

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 aynı çıktıyı verir.

Bazı siteler için çalışır:

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 kullanıyorum, Windows 7 de yüklü. Bu siteler Windows'da çalışır :(

Bu bilgilerin yardımcı olup olmadığından emin değilim ama koştum ifconfigve aşağıdakileri aldım:

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'i çalıştırdım:

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

Ve www olmadan:

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 olmadan:

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

Bu bir Japon ISS ve modeme / yönlendiriciye bir kablo ile bağlansam bile bir kullanıcı adı ve şifre eklemem gerekiyor, ancak Ubuntu'nun "Kablolu" bağlantısıyla bunları ekleyemedim. Ev arkadaşım bana bir OCN bağlantısı oluşturmamı söyledi ama bunun bir tür ağın mı yoksa sadece Japon şirketinin adı mı olduğundan emin değilim ... ama bilgisayarına baktıktan sonra PPPoE bağlantısı olduğunu gördük. Bazı googling sonra bir PPPoE bağlantısı oluşturmak için bir DSL bağlantısı oluşturmak gerektiğini ve buna bir şifre ve kullanıcı adı ekleyebilirim öğrendim. Ayrıca "Kablolu" bağlantısını otomatik olarak bağlanmayacak şekilde değiştirdim.

Modemi doğrudan bağlarsam aynı sorunu alıyorum.

DSL MTU'yu 500, 1500, 1492 ve 1482 olarak değiştirmeyi denedim ama bir fark yaratmadı.

Ayrıca nedense Ubuntu her zaman bağlantıyı açmıyor, bazen bağlanmak için yeniden başlatmam gerekiyor.

Bu eski bir soru, ancak buraya Google üzerinden gelenler için bu yardımcı olacaktır. Sorun SSL'de parçalanmanın kötü olması ve protokolü bozmasıdır. PPPOE kullanıyorsanız, yönlendiriciniz / DSL / Kablo modeminizdeki normal MTU 1492'dir. Bu çok yüksektir ve parçalanmaya neden olur. 1476, çoğu site ile çalışacak sihirli sayıdır. Bazı siteler farklı SSL uygulamaları kullanır, böylece 1480 veya hatta 1488 çalışabilir. MOST uyumluluğu için, ağ cihazınızın WAN tarafındaki MTU (yönlendirici, modem, vb.) 1476 olmalıdır.

İşte denenecek birkaç şey:

1. Ağ kartı ayarlarınızı kontrol edin. Her iki eth arabiriminiz IPv4 adreslerini göstermiyor. IPv4'ün açık olduğundan emin olun (IP'yi yenilemek için yönlendiricinizle yeniden bağlantı kurmanız gerekebilir). Bu işe yaramazsa, IPv6 desteğini kapatmayı deneyin ve bunun bir fark yaratıp yaratmadığına bakın. Bunu saatinize göre ağ simgesine sağ tıklatarak (Ethernet bağlantısında, biri yukarı, diğeri aşağı dönük bir çift ok) ve "Bağlantıları Düzenle ..." seçeneğini seçerek yapın. "IPv4 Ayarları" sekmesinde "Otomatik (DHCP)" olarak ayarlandığından emin olun. IPv6'yı kapatmak istiyorsanız, sekmesine gidin ve "Yoksay" olarak ayarlayın.

2. Sitelere başka yöntemler kullanarak bağlanıp bağlanamayacağınızı kontrol edin. pingBağlanamadığınız siteler için ne yanıt veriyor? Nasıl traceroute(kullanmak için traceroute yüklemeniz gerekebilir, FYI)? Yanıtları, sorunu gidermenize yardımcı olabilir. URL sunucularına erişemezlerse, bu bir DNS sorunu olabilir (ancak, URL sunucularına ulaşabilir, ancak bırakılırsa, bu komutların engellendiği anlamına gelebilir).

3. Yönlendiriciyi atlayın. Yönlendiriciniz ve modeminiz iki farklı makineyse, bilgisayarınızı doğrudan modeminize bağlamayı ve bunun bir şey değiştirip değiştirmediğini görmeyi deneyin.

4. Modeminizi ve yönlendiricinizi yeniden başlatın. Bazen sadece emerler.

5. Bilgisayarı yeniden başlatın. Bazen sadece emerler.

6. Farklı bir bilgisayar deneyin. Bilgisayarınız varsa, bunun başarısız olduğu başka bir bilgisayar çalışıyor mu? Değilse, o zaman bilgisayarınız ile ilgili bir şey olabilir.

7. Bilgisayarınızın önbelleğini, çerezlerini vb. Temizleyin. Bazen, kötü oturum çerezleri, önbellek vb. Bir siteye bağlanmayı engelleyebilir (Google ile bir süre önce bu sorunu yaşadım). Onları temizleyin ve yeni başlayın ve ne elde ettiğinizi görün.

8. Tüm VPN bağlantılarını ayırın. Noktadan Noktaya protokol genellikle VPN (PPP arayüzü) için kullanılır ve VPN'ler sitelere bağlanmayı engelleyebilir. Ağ simgenizi saatinize sağ tıklayıp "VPN Bağlantıları" girişini bularak ve hiçbir girişin işaretlenmediğinden ("VPN Bağlantıları" menü öğeniz yoksa bağlı olmadığınızdan emin olun, t bir ayar yapın). İşaretli varsa, ona bağlısınız, bağlantısını kesin.

Unutmayın: Yaptığınız her şey basit bir "çalışma ya da başarısızlık" ile sonuçlanmaz, sunucunun isteğinize verdiği tepkideki herhangi bir değişiklik bize bir şey söyleyemez. Bu nedenle, yukarıdakilerden herhangi birini yapar ve yeni bir mesaj alırsanız, sorunuzu güncellemeyi unutmayın.

Aşağıdaki davranışları bulduğum pratikte bu davranışı iki kez gördüm.

• Yerel ağdaki bazı bilgisayarlar başarılı bir şekilde ortadaki adam saldırısına teşebbüs ediyordu. ARP'yi ağ geçidi sahteciliği, böylece tüm trafiği bu makineden geçmek için yönlendiriyor, istekleri ve diğer kötü şeyleri değiştiriyordu. Makine Windows çalıştırıyordu ve bazı kötü amaçlı yazılım bulaşmış olduğu bulundu. Bu makinenin fiziksel olarak ağ ile bağlantısı kesilir kesilmez semptomlar ortadan kalktı.
• Bir MTU sorunu sizin veya başka ağ geçidi üzerinde. IPv4'te, yönlendirme trafiğinin yönlendirdiği ağların çerçeve boyutu aynı değilse, ağ üzerindeki IP paketlerini parçalamak ve yeniden birleştirmekten sorumludur. PPPoE / PPPoA kullanan DSL bağlantıları için MTU boyutu genellikle LAN tarafındaki 1500 bayttan küçüktür. Ayrıca aradaki yönlendiriciler başarısız olur ve yönlendiricinizde TCP MSS Sıkıştırma özelliğini etkinleştirmeniz gerekir . Bunu her zaman önceki ISS'imin bağlantısına ayarlamam gerekiyordu, ancak SSL ile ilgili sorunlardan daha fazlasını çözüyordu. Modeminizin / yönlendiricinizin böyle bir seçeneği olup olmadığını kontrol edin. Bunun bir çözüm olduğunu düşünün.
• SSL trafiğini de geçirmek için şeffaf bir proxy çalıştıran bir ağdaydım, ancak TLSv1'de bir nedenden dolayı başarısız oldum. Bir VPN bağlantısı kullanılırken aynı istek işe yaradı. korkunç Seçeneği ile
  çalıştırmayı deneyin . Bu çözerse, kokuyor.curl--sslv3

Denenecek genel şeyler:

• Modeminizde / yönlendiricinizde en son ürün yazılımını çalıştırıp çalıştırmadığınızı kontrol edin. Değilse, yükseltmeyi deneyin.

• tcpdumpVeya Whireshark kullanarak trafiği yakalayın ve analiz ettirin (örneğin buraya gönderin).

    # 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
  

  Eğer alıyorsanız bir araya getirmek hataları veya kayıp Önceki segmenti defalarca bu yanlış bir MTU boyutu kaynaklanan paket kaybı hakkında net bir işaretidir.
  Ancak, HTTPS trafiği şifrelenir ve ağ trafiğinden tek başına analiz edilmesi zordur.

Düzenle:

Senin tcpdump itibaren SSL Sorunun kökü açık: TCP Previous segment lost. Genel ağ sorunlarını giderme burada uygulanmalıdır, ancak yerel ağınızın kapsamı dışında ve İSS'nizle ilgili bir sorun olabilir.

Herkese merhaba bu İtalya'dan marcovaleriof IS, son zamanlarda sizinkine benzer bir sorunumuz vardı: Android veya Windows Device'ın bir sorunu olmasa da tüm Linux makinemiz artık herhangi bir https web sitesine bağlanamazdı. Sorun, 1492 mtu uzunluğundaki DSL yönlendiricimiz ile 1500 IS olan varsayılan Linux mtu arasında bir mtu sapmasıydı. Aslında bu komutu root olarak veren

ifconfig wlan0 mtu 1492 up

(İngilizce olarak bu set Net arayüzün mtu değeri - Benim durumumda wlan0 - 1492 uzunluğa kadar) problemden kurtuldu, teşekkür ederim! Umarım bu birine yardımcı olabilir.

Tüm yardımlarınız için teşekkürler, sorun sonunda düzeltildi!

MTU'nun yardım edip edemeyeceğini görmek için sınırlamaya çalışıyordum ve benim için MTU'yu sınırladığı için pppoeconfPPPoE bağlantısını kurmak için kullanıldı . Daha sonra daha önce kullandığım DSL bağlantısını devre dışı bıraktım.

Benzer bir sorun yaşayan herkes sudo ppoeconfiçin talimatları yazarak ve uygulayarak bu çözümü deneyebilirsiniz . Sonra ile bağlantı kurabilir pon adsl-providerve bağlantıyı kesebilirsiniz.poff