Как исправить ошибку кластера etcd tls: первая запись не похожа на рукопожатие TLS "" - PullRequest
Новая
       12

Как исправить ошибку кластера etcd tls: первая запись не похожа на рукопожатие TLS ""

0 голосов
/ 12 января 2019

Я создал три узла etcd cluester, config и start уже в порядке, но когда я проверяю /var/log/messages, он показывает

etcd: отклонено соединение из "172.17.0.3:43192" (ошибка "tls: first запись не похожа на рукопожатие TLS ", ServerName" ")

Как я могу это исправить?

Я проверил состояние etcd: 

member 48b0dff99d5c867e is healthy: got healthy result from https://172.17.0.9:2379
member 646dab89331aabab is healthy: got healthy result from https://172.17.0.8:2379
member b45603216bfac234 is healthy: got healthy result from https://172.17.0.10:2379

Это показывает ОК, но когда я cat /var/log/messages, это всегда показывает эту ошибку:

12 января 20:08:57 master etcd: отклонено соединение от "172.17.0.3:43160" (ошибка "tls: первая запись не похожа на TLS рукопожатие ", ServerName" ")
12 января 20:08:57 мастер etcd: отклонено соединение из "172.17.0.3:43162" (ошибка "tls: oversized record получено с длиной 21536 ", ServerName" ")

Ответы [ 2 ]

0 голосов
/ 12 марта 2019

для меня помогло 

listen       443 ssl http2;
ssl on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers on;

в конфигурации nginx

0 голосов
/ 14 января 2019

С моей стороны нет решения, которое бы полностью помогло вам с проблемой, но я нашел пару ссылок, которые могут помочь вам в дальнейших исследованиях. Прочитайте их внимательно, попробуйте решения, и я надеюсь, что вы решите проблему.

  1. Github question # 9917 : проверьте ETCDCTL_API переменную, особенно убедитесь, что --endpoints настроен с https.

  2. Переконфигурирование во время выполнения : попытаться перенастроить ваш etcd путем обновления / удаления / добавления членов etcs.

  3. вход nginx : check your nginx ingress annotations, если вы используете nginx

  4. google groups Тема рукопожатия TLS : проверьте эту тему, особенно комментарии, относящиеся к переменной VAULT_ADDR. Я скопирую вставить последний комментарий из темы здесь:

Мы смогли заставить все работать, после понимания вопросы разрешения.

Вы спросили: «Пожалуйста, подтвердите, если вы видите сообщения об ошибках сервера перед инициализацией Vault "После дальнейшего изучения я определил что ошибок не было до инициализации Хранилища.

Проблема оказалась не связанной с VAULT_ADDR, и мы использовали значение: "http://127.0.0.1:8200"

У меня есть сценарий операции установки, и кажется, что не все было запущено с соответствующими разрешениями. Сначала я был выполнение сценариев с помощью команды "sudo", в результате чего неудачи. Я обнаружил, что разрешения для ключа сертификата были ограничены, и мой пользователь не мог получить доступ к файлу. Там возможно, были и другие проблемы с разрешениями. Но однажды я переключился Пользователь рут и запустил скрипт, все вело себя корректно.

Спасибо

...