Нужны советы по отладке ошибок SSL от EKS с использованием лака - PullRequest
0 голосов
/ 17 января 2020

Я знаю, что это несколько конкретный c вопрос, но у меня проблема, которую я не могу отследить. У меня есть один модуль, развернутый на EKS - модуль содержит приложение python и прокси обратного кэширования varni sh. Я работаю с кусочками json (то есть потоковыми строками json, а-ля http://jsonlines.org/), и это может быть несколько ГБ данных.

В первый раз Я делаю запрос, и он попадает на сервер python, все работает правильно. Это занимает (намного) больше времени, чем кэшированная версия, но загружается весь набор json строк. Однако теперь, когда он кэшируется в varni sh, если я использую curl, я получаю:

curl: (56) GnuTLS recv error (-110): The TLS connection was non-properly terminated.

или

curl: (56) GnuTLS recv error (-9): A TLS packet with unexpected length was received.

SSL завершается на ELB, и когда я используйте curl из самого прокси-контейнера (используя curl http://localhost?....), проблем нет.

Сложная часть этого заключается в том, что проблема несколько прерывистая.

Если есть какие-либо советы в условия умного varnishlog использования или чего-то такого же на AWS, я был бы очень признателен.

Спасибо!

1 Ответ

0 голосов
/ 18 февраля 2020

Поскольку TLS прерывается на ваших балансировщиках нагрузки ELB , соединение между ними должно быть в простом HTTP.

Возможно, ошибка не исходит от Varni sh потому что Varni sh в настоящее время не обрабатывает TLS изначально. Я не уверен, что varnishlog может дать вам лучшее представление о том, что на самом деле происходит.

Контрольный список

Единственный контрольный список, который я могу вам дать, следующий:

  • Убедитесь, что используемый вами сертификат действителен
  • Убедитесь, что вы подключаетесь к целевой группе по протоколу HTTP, а не по HTTPS
  • Если вы включили протокол PROXY на своем ELB, убедитесь, что Varni sh имеет прослушиватель -a, который прослушивает PROXY запросы протокола, поверх обычных запросов HTTP.

Отладка

Выполните отладку сверху вниз:

  • Увеличьте детализацию ваших вызовов cURL и попробуйте получить дополнительную информацию об ошибке
  • Попробуйте получить доступ к журналам вашего ELB и получите более подробную информацию там
  • Получите дополнительную информацию из журналов EKS
  • И, наконец, выполните varnislog -g request -q "ReqUrl eq '/your-url'", чтобы получить полный журнал Varnishlog для указанного c URL
...