Je viens d'emménager dans un nouvel appartement et avec une connexion Internet via un routeur et je constate que je ne peux pas me connecter à pas mal de sites utilisant SSL.
Par exemple, essayez de vous connecter à 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 donne la même sortie.
Pour certains sites, cela fonctionne:
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/
.
.
.
J'utilise Ubuntu 12.04, avec Windows 7 également installé. Ces sites fonctionnent sous Windows :(
Je ne sais pas si ces informations sont utiles, mais j'ai couru ifconfiget j'ai obtenu les informations suivantes:
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)
J'ai exécuté 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
Et sans 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 * * *
sans 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 * * *
Le 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
Il s'agit d'un FAI japonais et même si je me connecte avec un câble au modem / routeur, je dois ajouter un nom d'utilisateur et un mot de passe, mais avec la connexion "filaire" d'Ubuntu, je ne pouvais pas les ajouter. Mon colocataire m'a dit de créer une connexion OCN mais je ne sais pas si c'est le nom d'un type de réseau ou simplement de la société japonaise ... mais après avoir regardé son ordinateur, nous avons constaté qu'il s'agissait d'une connexion PPPoE. Après quelques recherches sur Google, j'ai appris que pour créer une connexion PPPoE, je devais créer une connexion DSL et que je pouvais y ajouter un mot de passe et un nom d'utilisateur. J'ai également changé la connexion "filaire" pour ne pas me connecter automatiquement.
J'obtiens le même problème si je me connecte directement au modem.
J'ai essayé de changer le DSL MTU en 500, 1500, 1492 et 1482 mais cela n'a fait aucune différence.
Aussi, pour une raison quelconque, Ubuntu ne prend pas toujours la connexion, je dois parfois redémarrer pour qu'il se connecte.
curl-ils pas uniquement ou ne s'ouvrent -ils pas également avec d'autres navigateurs?Error 7 (net::ERR_TIMED_OUT): The operation timed out. FireFox continue juste d'essayer de se charger mais ne le fait jamais (la page ne change pas). La console et le réseau ne me donnent rien ...Réponses:
C'est une vieille question, mais pour ceux qui arrivent ici via Google, cela aidera. Le problème est que la fragmentation sur SSL est mauvaise et rompt le protocole. Si vous utilisez PPPOE, le MTU normal de votre routeur / modem DSL / câble est 1492. C'est trop élevé et cela provoquera une fragmentation. 1476 est le nombre magique qui fonctionnera avec le plus de sites. Certains sites utilisent différentes implémentations SSL, donc 1480 peut fonctionner, ou même 1488. Pour la compatibilité la PLUS, le MTU du côté WAN de votre périphérique réseau (routeur, modem, etc.) doit être 1476.
la source
sudo yum install docker-engineaprès avoir ajouté le repo yum.dockerproject.org sur une boîte CentOS 7:sudo ip link set mtu 1476 dev enp6s0pour abaisser le MTU de sa valeur par défaut de 1500 à 1476. Je me suis gratté la tête pendant une journée en essayant de comprendre pourquoi yum.dockerproject.org était accessible via https à partir d'autres nœuds sur le même réseau.Voici quelques choses à essayer:
Vérifiez les paramètres de votre carte réseau. Aucune de vos interfaces eth n'affiche les adresses IPv4. Assurez-vous que IPv4 est activé (vous devrez peut-être rétablir votre connexion avec votre routeur pour renouveler l'IP). Si cela ne fonctionne pas, essayez de désactiver la prise en charge IPv6 et voyez si cela fait une différence. Pour ce faire, faites un clic droit sur l'icône de mise en réseau près de votre horloge (lorsque vous êtes sur une connexion Ethernet, c'est une paire de flèches, l'une pointant vers le haut, l'autre vers le bas) et en sélectionnant "Modifier les connexions ...". Dans l'onglet "Paramètres IPv4", assurez-vous qu'il est défini sur "Automatique (DHCP)". Si vous souhaitez désactiver IPv6, accédez à son onglet et réglez-le sur "Ignorer".
Vérifiez si vous pouvez vous connecter aux sites à l'aide d'autres méthodes. À quoi
pingrépond les sites auxquels vous ne pouvez pas vous connecter? Que diriez-traceroutevous d' un (vous devrez peut-être installer traceroute pour l'utiliser, pour info)? Leurs réponses peuvent vous aider à résoudre le problème. S'ils ne peuvent pas accéder aux serveurs de l'URL, cela pourrait être un problème DNS (cependant, s'ils peuvent accéder aux serveurs de l'URL, mais sont ensuite supprimés, cela peut simplement signifier que ces commandes sont bloquées).Contournez le routeur. Si votre routeur et votre modem sont deux machines différentes, essayez de connecter votre ordinateur directement à votre modem et voyez si cela change quelque chose.
Redémarrez votre modem et votre routeur. Parfois, ils sucent juste.
Redémarrez votre ordinateur. Parfois, ils sucent juste.
Essayez un autre ordinateur. Si vous en avez un, un autre ordinateur fonctionne-t-il là où celui-ci échoue? Sinon, cela pourrait être quelque chose avec votre ordinateur spécifique.
Vider le cache de votre ordinateur, les cookies, etc. Parfois, les cookies de mauvaise session, le cache, etc. peuvent interférer avec la connexion à un site (j'ai eu ce problème avec Google il y a quelque temps). Éliminez-les et recommencez à zéro et voyez ce que vous obtenez.
Déconnectez toutes les connexions VPN. Le protocole point à point est souvent utilisé pour les VPN (l'interface PPP), et les VPN peuvent interférer avec la connexion aux sites. Assurez-vous que vous n'êtes pas connecté en faisant un clic droit sur l'icône de votre réseau près de votre horloge, en trouvant l'entrée "Connexions VPN" et en vous assurant qu'aucune liste n'est cochée (si vous n'avez pas d'élément de menu "Connexions VPN", alors vous ne ' t en avoir un). S'il y en a une cochée, alors vous y êtes connecté, déconnectez-vous-en.
N'oubliez pas : tout ce que vous faites n'entraînera pas un simple «travail ou échec», tout changement dans la réaction du serveur à votre demande nous dira quelque chose. Donc, si vous faites l'une des choses ci-dessus et recevez un nouveau message, n'oubliez pas de mettre à jour votre question.
la source
J'ai vu ce comportement deux fois dans la pratique pour lequel j'ai trouvé les solutions suivantes.
Essayez de courir
curlavec l'option--sslv3. Si cela le résout, alors ça pue.Trucs généraux à essayer:
Capturez le trafic à l'aide de
tcpdumpou Whireshark et faites-le analyser (postez-le ici par exemple).Si vous obtenez des erreurs de réassemblage ou si le segment précédent est perdu à plusieurs reprises, c'est un signe clair de la perte de paquets causée par une mauvaise taille MTU.
Cependant, le trafic HTTPS est chiffré et difficile à analyser à partir du trafic réseau par lui-même.
Éditer:
A partir de votre tcpdump la racine de votre problème SSL est clair:
TCP Previous segment lost. Le dépannage général du réseau doit s'appliquer ici, mais il peut être en dehors de la portée de votre réseau local et un problème avec votre FAI.la source
--sslv3et cela ne fonctionne toujours pas. J'ai aussi essayé de capturer le vidage mais cela ne semble pas fonctionner?tcpdump: WARNING: eth0: no IPv4 address assigned0 packets captured6 packets received by filter0 packets dropped by kernel- Je ne sais pas comment attribuer l'IPv4 ... Je devrai essayer le reste demain car il se fait tard et mon cerveau ne fonctionne pas bien. Merci pour votre aide à tous jusqu'à présent!ppp0interface au lieu deeth0laquelle me fait penser: pourquoi avez-vous besoin de PPP pour une connexion lorsque vous utilisez un routeur?Salut tout le monde, c'est Marcovaleriof d'Italie, récemment, nous avons eu un problème similaire au vôtre: toute notre machine Linux ne pouvait plus se connecter à aucun site Web https alors qu'Android ou Windows Device n'avait aucun problème. Le problème était un désalignement mtu entre notre routeur DSL qui avait une longueur de 1492 mtu et le mtu Linux par défaut qui est 1500. En fait, émettre cette commande en tant que root
(en anglais cet ensemble La valeur mtu de l'interface nette - wlan0 dans mon cas - jusqu'à 1492 de longueur) a éliminé le problème, merci! J'espère que cela pourrait aider quelqu'un.
la source
Merci pour toute votre aide, le problème est enfin résolu!
J'essayais de limiter le MTU pour voir si cela aiderait et j'ai fini par utiliser
pppoeconfpour configurer la connexion PPPoE car il limite le MTU pour moi. J'ai ensuite désactivé la connexion DSL que j'utilisais précédemment.Pour toute personne rencontrant un problème similaire, vous pouvez essayer cette solution en tapant
sudo ppoeconfet en suivant les instructions. Ensuite, vous pouvez vous connecterpon adsl-provideret vous déconnecter avecpoffla source