Как отдебажить почему openssl s_client не устанавливает туннель?

Question

[Quqas]

1) если запускать s_server без -www то в консоле вижу как браузер пытается лезть на порт
2) если с -www то в консоле уже чисто, но в браузере открывается текст ключ сервера

а s_client в обоих вариантах не создаёт туннель - показывает только сертификат промежуточного прокси, но не сертификат сервера. и я даже не могу понять он до сервера-то доходит или рвётся еще на проксе\шлюзе\фаерволе?

как отдебажить и понять?(и в итоге починить)

подробности

есть два роутера
роутер1 лицензионный "облачный" но тупой (без entware) кинетик - смотрит наружу
роутер2 "поддельный" но умный кинетик с entware внутри сети, к которому и надо подключиться по ssh ИЗВНЕ
ip серый поэтому весь доступ извне через облако кинетика
и если "чистый" web то всё работает
а openssl не лезет по вот этому облачному пути
понять бы почему и как s_client сделать больше похожим на браузер? -servername уже освоил

Comments

[Кот Абсолютный]

как s_client сделать больше похожим на браузер

Никак. s_client - это коммандлайновая тулза для проверки соединения.

This command implements a generic SSL/TLS client which connects to a remote host using SSL/TLS. It is
a very useful diagnostic tool for SSL servers.

man openssl-s_client

[AUser0]

А что, -debug недостаточно подробностей даёт?

[Quqas]

AUser0, даже излишне много
а понимания дошло до сервера или нет - не добавляет
что именно в выводе надо искать?

[Quqas]

в случае браузера серт не сервака, а прокси становится (в самом браузере) но показывает именно страницу сервера
может и s_client на первом попавшемся tls пытается соединится?
хотя мысль что должен проходить через прокси внутрь до сервака.

Answer 1

[ValdikSS]

Команда работает корректно, как и должна. openssl s_server это TLS-терминатор, который выдаст клиенту данные, которые получит в stdin, и отправит то, что ему отправят в stdout.

openssl s_client не устанавливает туннели! Это TLS-клиент, который работает по принципу netcat — «оборачивает» stdin/stdout в TLS. Вам всё уже ответили в предыдущем вопросе.

Comments

[Quqas]

ответить то ответили - но я не могу поставить рекомендованные "усложнения" nginx

а s_client такое впечатление не может сквозь nginx прокси пролезть - и "руки-жмёт" с ним а не s_server (который тоже вовнутри сети)

осталось только в этом на 146% убедится

или совет как заставить таки "пробится" вовнутрь
и тогда уже вовнутре ssl пойдёт ssh (но это да уже обсудили)

[ValdikSS]

Quqas, TLS на Keenetic терминируется на внутреннем веб-сервере. Разве сервис позволяет сделать доступ до чего-то помимо самого web-интерфейса роутера?
Если нет, то и сервер Keenetic не пропустит не-web-трафик, и серверная часть на самом роутере (софт от keenetic, который направляет трафик в nginx на keenetic).

[Quqas]

ValdikSS,

самого web-интерфейса роутера

это-то вполне.
любой внутренний и даже не очень ip(типа момеда который какбы "вовне" по отношению к роутеру)

не пропустит не-web-трафик

а вот это да. но начиналось то всё (в гугле) что ssh в этот самый web можно завернуть. но оказывается нельзя или нетольколишьвсе варианты tls заворачиваются
но как-то труЪ https браузеров идёт, а остальное уже не очень. хотя обещали(в гугле) с три короба