Вопросы Теги

Не удается выполнить квитирование SSL с одним сервером из образа GCE Ubuntu 16.04.1 (но работает везде)

Я пытаюсь подключиться к swift.ca-ns-1. clouda.ca:8443 через SSL. Я могу подключиться к этому серверу с нескольких других машин, включая другие свежие ящики 16.04.1 (не на GCE), и я подключаюсь к нему из других экземпляров GCE, которые не являются Ubuntu 16.04.1, но когда я пытаюсь подключиться с любого Ubuntu 16.04. 1 экземпляр GCE не удается установить соединение SSL. Я' Ниже мы разместили пример вывода openssl. Обратите внимание, что я могу подключиться к любому другому серверу SSL, который я пробовал. Сами CloudA разобраться не смогли. Есть идеи? 

% openssl s_client -connect swift.ca-ns-1.clouda.ca:8443
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 305 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1475846555
Timeout : 300 (sec)
Verify return code: 0 (ok)
---

ОБНОВЛЕНИЕ : Я подтвердил, что это происходит только в зонах us-central1 (также затрагивается любая субаренда). Создание экземпляра в us-east1 отлично работает.

3
задан 7 October 2016 в 22:16
2 ответа

write:errno=104
. ...
SSL handshake прочитал 0 байт и записал 305 байт

Это означает, что

  • TCP соединение с сервером было успешно
  • openssl s_client попытался запустить TLS handshake, отправив ClientHello
  • сервер или какой-нибудь middlebox (брандмауэр, балансировщик нагрузки). ...) вызвал RST (errno 104 is ECONNRESET) TCP-соединение (вероятно) в качестве ответа на ClientHello

Невозможно сказать из этой информации, что вызвало RST и какая система его послала. Но можно попытаться сузить его с помощью некоторых экспериментов:

  • Проверьте, что все 16.04.1 (рабочие и нерабочие) используют одну и ту же openssl версию. Вызова openssl версии недостаточно, так как в дистрибутивах меняется обратный порт на более старые версии и номер версии не меняется. Вместо этого используйте openssl версию -a и сравнивайте время сборки. Если они не совпадают, убедитесь, что они совпадают, и повторите проверку.
  • Проверьте, что на всех системах используется один и тот же IP-адрес цели, т.е. попробуйте вместо него использовать s_client с известным хорошим IP-адресом цели.
  • Проверьте, не имеет ли сервер проблем с IP-адресом источника, туннелируя соединение (например, с OpenSSH) так, чтобы он исходил из известной хорошей системы. Если вам не повезло, IP-адрес вашей системы находится в каком-нибудь черном списке из-за действий предыдущего владельца.
8
ответ дан 3 December 2019 в 05:02

У меня была аналогичная проблема. Это было решено добавлением опции имени сервера. Например, если вы подключаетесь к Gmail: openssl s_client -connect imap.gmail.com:993 -servername gmail.com

Подробнее см. https://en.wikipedia.org/wiki/Server_Name_Indication .

0
ответ дан 3 December 2019 в 05:02

Теги

Похожие вопросы