Назад | Перейти на главную страницу

SSL-соединение зависает при приветствии клиента (curl, openssl client, apt-get, wget, все)

Я столкнулся с проблемой на моем Debian VPS (xen domU) относительно SSL. А именно почти все SSL-соединения зависают при приветствии клиента. Например:

# curl -vI https://graph.facebook.com

То же самое и при использовании клиента openssl. Однако часть трафика SSL работает (например, https://www.nordea.se).

Сервер

#uname -a

Linux server.com 2.6.26-1-xen-amd64 #1 SMP Fri Mar 13 21:39:38 UTC 2009 x86_64 GNU/Linux

Однако он работает на моем Dom 0 (основном хосте xen).

Apt-get

Я даже не могу запустить apt-get update с источниками безопасности debian (зависает при чтении заголовков)

Открытый SSL

Вначале я думал, что у меня старый клиент openssl (0.9.8o-4), так как у меня, похоже, был более новый на Dom 0 (0.9.8g-15 + lenny8), но обновление manuanl на openssl deb не Помогите.

Открыть клиент SSL

Это полный результат зависания клиента openssl: http://pastebin.com/PAjwMap9

Заключительные мысли

Я погуглил дерьмо из этого, и я не пойду дальше. Я видел проблемы с curl, apt-get и т. Д., Но все они относятся к самому приложению, а не к системе. Есть предположения?

После некоторых дискуссий с моим провайдером хостинга выяснилось, что у них была проблема с MTU в цепях IP, которые использовал мой DomU (но не Dom0). Хочу поблагодарить всех, кто помогал мне в этом процессе, ваша помощь неоценима :)

Это старый вопрос, на который уже был дан ответ, но у нас возникла та же самая проблема, и причина была связана, но другая.

Ключевым моментом было прослушивание трафика на нашем пограничном маршрутизаторе, где мы видели сообщения ICMP на сервер (GitHub.com), запрашивающие фрагментация. Это мешало соединению с повторными передачами, дублированными ACK и т. Д.

В пакете ICMP есть поле, MTU of next hop со странным значением - 1450. Обычное значение - 1500.

Мы проверили наш маршрутизатор, и один из интерфейсов (туннель Ethernet) имел это значение как MTU, поэтому маршрутизатор принимал минимальное значение MTU всех интерфейсов в качестве следующего перехода. Как только мы удалили этот интерфейс (он не использовался), квитирование SSH снова заработало.

Я бы попытался использовать openssl s_client и дать ему случайный файл («любой» файл), чтобы проверить, связана ли проблема с / dev / random | urandom, как сказал Бен:

openssl s_client -state -connect graph.facebook.com:443 -rand anyfile

Имейте в виду, что использование файла таким образом очень опасно с точки зрения криптографии, поэтому обязательно найдите другое решение, прежде чем запускать его в производство.

Похоже, проблема с гостевым / dev / urandom или / dev / random .. или, может быть, с другим устройством. Запустите процесс зависания под strace и посмотрите, не зависает ли он при чтении.

Пытаться:

 $sudo apt-get --reinstall install openssl libssl0.9.8