Не может соединиться с определенными сайтами HTTPS
Я только что переместился в новую квартиру и с интернет-соединением через маршрутизатор, и я нахожу, что не могу подключить к довольно многим сайтам то использование 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. После некоторого поиска с помощью Google я узнал, что для создания соединения PPPoE я должен буду создать соединение DSL и что я мог добавить пароль и имя пользователя к нему. Я также изменил "Проводное" соединение для не соединения автоматически.
Я получаю ту же проблему, если я сцепляюсь до модема непосредственно.
Я попытался изменить MTU DSL на 500, 1500, 1492 и 1482, но это не имело значения.
Также по некоторым причинам Ubuntu не всегда берет соединение, я иногда должен перезапускать, чтобы это соединилось.
5 ответов
Это старый вопрос, но для тех, кто попадает сюда через Google, это поможет. Проблема в том, что фрагментация по протоколу SSL является плохой и нарушает протокол. Если вы используете PPPOE, обычный MTU в вашем маршрутизаторе / DSL / кабельном модеме равен 1492. Это слишком высокое значение и приведет к фрагментации. 1476 - это магическое число, которое будет работать с большинством сайтов. Некоторые сайты используют разные реализации SSL, поэтому может работать 1480 или даже 1488. Для совместимости с MOST значение MTU на стороне WAN вашего сетевого устройства (маршрутизатора, модема и т. Д.) Должно быть 1476.
Я видел такое поведение дважды на практике, для которого я нашел следующие решения.
- На каком-то компьютере в локальной сети была предпринята попытка атаки «человек посередине». Это был ARP-спуфинг шлюза, таким образом перенаправляя весь трафик, проходящий через эту машину, изменяя запросы и другие неприятные вещи. Машина работала под управлением Windows и была обнаружена зараженной вредоносной программой. Как только эта машина была физически отключена от сети, симптомы исчезли.
- Проблема MTU на вашем или другом шлюзе. В IPv4 шлюзы отвечают за фрагментацию и повторную сборку IP-пакетов в сети, если размер кадра сетей, для которых маршрутизируется трафик, не одинаков. Для DSL-соединений, использующих PPPoE / PPPoA, размер MTU обычно меньше 1500 байт на стороне локальной сети. Также между маршрутизаторами происходит сбой, и вам необходимо включить TCP MSS Clamping на вашем маршрутизаторе. Мне всегда нужно было установить это при подключении моего предыдущего интернет-провайдера, но это решало не только проблемы, связанные с 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.
[ 117] Однако трафик HTTPS зашифрован и его трудно анализировать из сетевого трафика.
Редактировать:
Из вашего tcpdump корень вашей проблемы с SSL ясен: TCP Previous segment lost . Здесь следует применять общие методы устранения неполадок в сети, но это может выходить за рамки вашей локальной сети и проблемы с вашим провайдером.
Привет всем. Это marcaleriof из Италии, недавно у нас была проблема, похожая на вашу: все наши Linux-машины больше не могли подключаться к любому веб-сайту https, в то время как Android или Windows Device не имели проблем. Проблема заключалась в несоответствии mtu между нашим DSL-маршрутизатором, длина которого составляла 1492 mtu, и Linux mtu по умолчанию, равным 1500. Фактически, эта команда была выполнена как root
ifconfig wlan0 mtu 1492 up
(на английском Значение mtu интерфейса net - wlan0 в моем случае - до длины 1492) избавило от проблемы, спасибо! Надеюсь, это может кому-то помочь.
Спасибо за вашу помощь, проблема наконец-то решена!
Я пытался ограничить MTU, чтобы посмотреть, поможет ли он, и в итоге использовал pppoeconf для настройки соединения PPPoE, так как он ограничивает MTU для меня. Затем я отключил соединение DSL, которое использовал ранее.
Если вы столкнулись с подобной проблемой, попробуйте это решение, набрав sudo ppoeconf и следуя инструкциям. Затем вы можете подключиться с помощью pon adsl-provider и отключиться с помощью poff
Вот несколько вещей попробовать:
Проверьте свои настройки сетевой платы. Ни один из Ваших интерфейсов eth не показывает адреса IPv4. Удостоверьтесь, что Вам включили IPv4 (Вы, возможно, должны восстановить свое соединение с Вашим маршрутизатором для возобновления IP). Если это не работает, попытайтесь выключить поддержку IPv6 и посмотрите, имеет ли это значение. Сделайте это путем щелчка правой кнопкой по значку сетевых подключений часами (когда на соединении Ethernet, это будет пара стрелок, одного подчеркивания, другой вниз), и выбор "Соединений Редактирования...". На вкладке "IPv4 Settings" удостоверьтесь, что она установлена на "Автоматический (DHCP)". Если Вы хотите выключить IPv6, перейдите к его вкладке и установите ее, чтобы "Проигнорировать".
Проверьте, чтобы видеть, можно ли соединиться с сайтами с помощью других методов. Что делает
pingответьте для сайтов, с которыми Вы не можете соединиться? Как насчет atraceroute(Вам, вероятно, придется установить traceroute для использования его, к вашему сведению)? Их ответы могли бы помочь Вам диагностировать проблему. Если они не могут добраться до серверов URL, то это могла бы быть проблема DNS (однако, если они могут добраться до серверов URL, но затем отбрасываются, это могло бы просто означать, что те команды заблокированы).Обойдите маршрутизатор. Если Ваш маршрутизатор и Ваш модем являются двумя различными машинами, попробуйте присоединение Ваш компьютер непосредственно к Вашему модему и видящий, изменяет ли это что-нибудь.
Перезапустите свой модем и маршрутизатор. Иногда, они просто сосут.
Перезагрузите компьютер. Иногда, они просто сосут.
Попробуйте другой компьютер. Если Вы имеете один, другой компьютер работает где эти сбои? В противном случае затем это могло бы быть что-то с Вашим определенным компьютером.
Очистите кэш своего компьютера, cookie, и т.д. Иногда, плохие cookie сессий, кэш, и т.д. могут вмешаться в соединение с сайтом (у меня была эта проблема с Google некоторое время назад). Уберите их и запустите новый и посмотрите то, что Вы получаете.
Разъедините любые соединения VPN. Протокол "точка-точка" часто используется для VPN (интерфейс PPP), и VPNs может вмешаться в соединение с сайтами. Удостоверьтесь, что Вы не соединены путем щелчка правой кнопкой по значку сети часами, нахождения записи "соединений VPN" и проверки, что никакой список не проверяется (если у Вас нет пункта меню "VPN Connections", затем у Вас нет того настроенным). Если существует кто-либо проверенный, то Вы подключены к нему, разъединение от него.
Помните: Не все, что Вы делаете, приведет к простой "работе или сбою", скажет любое изменение в реакции сервера к Вашему запросу нам что-то. Так, если Вы делаете какое-либо вышеупомянутое и получаете новое сообщение, не забывайте обновлять свой вопрос.