Сообщение об ошибке nginx — на что ссылается одноранговый узел?

Чтобы отладить случай ошибки nginx, мне нужно сначала полностью понять сообщение журнала ошибок. Наш nginx время от времени записывает конкретное сообщение журнала ошибок.

Сообщение журнала

«одноранговое соединение закрыто при квитировании SSL (104: соединение сброшено узлом) при квитировании SSL к восходящему узлу».

Что подразумевается под "одноранговым"?

Я хотел бы знать: относится ли «пир» к восходящему потоку, что означает, что восходящий поток закрыл соединение во время рукопожатия ssl, или он относится к клиенту, что означает, что клиент закрыл соединение, пока балансировщик нагрузки и веб-сервер находились внутри во время рукопожатие?

Настройка

  • балансировщик нагрузки nginx
  • 2 веб-сервера (восходящие) под управлением IIS8
  • SSL-провайдер: Comodo

ssl nginx handshake
person Stephan Møller    schedule 22.01.2015    source источник

Ответы (3)


arrow_upward
5
arrow_downward

Peer в данном случае относится к восходящему потоку. Просто потому, что если мы возьмем, что пир является клиентом, это будет означать, что два рукопожатия SSL (Client -> nginx, nginx -> upstream) происходят одновременно, что не имеет смысла — клиент должен установить соединение и отправить запрос, и только тогда nginx может выбрать подходящий восходящий поток для подключения к

person SuddenHead    schedule 29.01.2015
comment
Спасибо. Это имеет смысл! - person Stephan Møller; 02.02.2015
comment
Побочный вопрос: как вы думаете, может ли эта ошибка каким-либо образом быть спровоцирована клиентом путем отправки определенных данных, или это изолированная проблема между балансировщиком laod и веб-сервером? - person Stephan Møller; 02.02.2015
comment
Я не думаю, что это о клиенте - person SuddenHead; 02.02.2015
comment
Сообщение об ошибке говорит о равноправном и вышестоящем узлах отдельно. В нем говорится, что peer закрыто соединение... при квитировании SSL с upstream, что указывает на то, что они НЕ одинаковы. - person Dayo; 03.02.2015
comment
Ну не могу с вами согласиться. в то время как рукопожатие SSL с восходящим потоком является контекстом события, а одноранговое закрытое соединение в рукопожатии SSL (104: сброс соединения одноранговым узлом) является самим событием. Эта ошибка определена в src/event/ngx_event_openssl.c и вызвана закрытием SSL-соединения, и в этом случае SSL-соединение является восходящим. - person SuddenHead; 03.02.2015

arrow_upward
1
arrow_downward

Ваша проблема может быть связана с порядком, в котором вы объединили файл Comodo .bundle с сертификатом вашего сайта.

Вам нужно поместить пакетный файл после сертификата сайта.

Нажмите на эту ссылку, чтобы подробнее

ИЗМЕНИТЬ

Партнер должен быть на том же «уровне», что и Nginx, который, поскольку ваши проблемы связаны с SSL, должен быть OpenSSL.

Рискну предположить, что ваша ОС — Ubuntu 12.x, а OpenSSL — 1.0.1. Если это так, то проблема, скорее всего, связана с ошибкой Ubuntu.

Кажется, вам нужно либо перейти на Ubuntu 13.04, либо отключить TLS 1.1.

Нажмите на эту ссылку, чтобы узнать подробности

В любом случае, одноранговый узел не является вышестоящим.

person Dayo    schedule 22.01.2015
comment
Спасибо, что указали на возможную причину сообщения об ошибке. Сертификат уже установлен правильно. Похоже, что на самом деле это клиент, на которого ссылается Peer. - person Stephan Møller; 23.01.2015
comment
В любом случае, я до сих пор не уверен, что имеет в виду сверстник. - person Stephan Møller; 29.01.2015
comment
Спасибо, что указали на ваше редактирование, Дайо. Я погружусь в это и вернусь. - person Stephan Møller; 03.02.2015
comment
На сервере уже установлена ​​последняя версия Ubuntu, поэтому проблема не в этом. Мы попытаемся исправить проблему, не запуская SSL между балансировщиком нагрузки и веб-серверами. - person Stephan Møller; 05.02.2015
comment
Я предполагаю, что это жизнеспособная работа над вашей реальной проблемой, но, как я уже сказал, одноранговый узел не является восходящим. Вы не упомянули, что смотрите на OpenSSL, но сейчас это спорно. Удачи! - person Dayo; 05.02.2015
comment
Что ж, я согласен с вами, что партнер может быть клиентом. Можно ли спровоцировать сообщение об ошибке с помощью рукопожатия с балансировщиком нагрузки, а затем перерезать провод через момент после рукопожатия, пока балансировщик нагрузки согласовывает рукопожатие с веб-сервером? Может ли это быть тем, что происходит на самом деле? Потому что это отправляет веб-сервер в нерабочий режим, даже если ошибка не вызвана веб-сервером. - person Stephan Møller; 05.02.2015
comment
Извините, я не понял, ваша проблема связана с OpenSSL и вышестоящим сервером. Закрытое соединение обычно связано с тем, что запрошенный метод шифрования не поддерживается. - person Dayo; 06.02.2015
comment
Но мы используем сертификаты comodo ssl. Разве это не другой поставщик ssl, чем открытый ssl? Или я пропустил некоторые подробности о работе ssl? - person Stephan Møller; 06.02.2015
comment
Еще одно: если вы говорите, что это может быть вызвано методом cifer, не возникнет ли проблема при рукопожатии с клиентом, а не при рукопожатии с восходящим потоком? Клиент и балансировщик нагрузки уже выполнили рукопожатие, когда происходит рукопожатие в сторону восходящего потока, или я ошибаюсь? - person Stephan Møller; 06.02.2015
comment
Теперь я знаю, что балансировщик нагрузки работает под управлением Ubuntu 14.04 и OpenSSL 1.0.1f от 6 января 2014 г. Ошибка все еще существует в этой версии? - person Stephan Møller; 06.02.2015
comment
Возможно, ошибка все еще существует: bugs.launchpad.net/ubuntu /+источник/openssl/+ошибка/1305175. Что касается различных последующих запросов, я думаю, вам, возможно, придется открыть еще один вопрос, чтобы задать их, поскольку их сложно ответить в разделе комментариев. - person Dayo; 07.02.2015

arrow_upward
0
arrow_downward

После многих часов отладки мы наконец нашли настоящую причину проблемы. Сообщение об ошибке было создано клиентом, запрашивающим nginx без домена, например. https://11.22.33.44/robots.txt. Затем Nginx перенаправил запрос на сервер IIS, у которого не было веб-сайтов по умолчанию, привязанных к https для запросов только по ip.

Таким образом, вывод по первоначальному вопросу заключается в том, что «одноранговый узел» на самом деле относится к восходящему потоку (IIS), поскольку IIS разрывает соединение.

Решение, которое мы выбрали для этой проблемы, чтобы не получить эту ошибку в nginx и, таким образом, избежать воздействия на клиентов, отправляющих все серверы в «неактивный» режим, — это настроить nginx так, чтобы он сам отклонял эти запросы. Еще одно возможное решение состояло в том, чтобы убедиться, что IIS хорошо справляется с этими запросами.

person Stephan Møller    schedule 24.04.2015