Ykidia Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Всем привет!   Несколько раз искал, но нигде не нашел - везде только про редирект со стандартного порта на стандартный. А у меня вопрос такой - имеем внешний IP, как обычно хотим выставить один порт наружу, чтобы заходить извне на службу внутри. Допустим, это веб-камера, mjpg-streamer, который умеет только HTTP. Чтобы получить HTTPS, я прикручиваю stunnel, либо какой-нибудь прокси в режиме reverse - nginx, squid, haproxy или еще какой-нибудь. Но теперь, чтобы зайти извне, мне необходимо в адресной строке браузера приписывать к своему адресу https:// , кроме порта, который надо указать после адреса. Длинновато получается, неудобно. А 2 (два!) порта публиковать уже не хочется - и так уже опубликовано до фига всего - и RDP (и не один), и SSH (тоже не один), а тут еще и на каждый HTTPS по два порта, один из которых фиктивный (только для редиректа). Итак, можно ли на один порт повесить прослушивание и HTTP, и HTTPS, причем так, что если ломятся по протоколу HTTP, то делается редирект туда же, но на протокол HTTPS?   Спасибо. Всего записей: 242 | Зарегистр. 03-03-2005 | Отправлено: 00:25 31-10-2018

Ykidia Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Так я и открою наружу только один, тем более что он будет не 443. Просто нужно, чтобы один порт обрабатывал оба протокола корректно. А то реверс-прокси либо совсем не работают, когда оба порта одинаковых указываешь, либо работают через раз. Всего записей: 242 | Зарегистр. 03-03-2005 | Отправлено: 02:06 31-10-2018

Paromshick Silver Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Вопрос, по сути, по вашему "пограничнику". Если это не просто "пробрасыватель портов", а у него есть встроенный прокси сервер (в т.ч. и обратный), то нет никаких проблем. Он слушает HTTPS трафик на внешнем интерфейсе. Исходя из адреса в заголовке, выбирает внутренний адрес. Таким образом, на одном 443 можно опубликовать вагон внутренних сервисов (по сути веб сайтов). Ровно то же самое с HTTP. Можно сделать редирект, так же стандартно. Если пришел HTTP запрос на сайт cam.domain.ru, то он автоматически уходит на http(s)://camera.domain.ru Это стандартный функционал более или менее продвинутого брандмауэра (здесь могла быть реклама ) ---------- Скучно Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 11:47 31-10-2018

Ruza Gold Member Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору Прикольно... Кто бы ещё клиентскому браузеру сказал что HTTP это не 80 порт. А то клиент замахается руками писать   http://www.Ykidia.domain:443/ Что мешает поставить нормальный реверс на стандартных портах и проксировать по именам ---------- Fools rush in where angels fear to tread. Всего записей: 5472 | Зарегистр. 10-09-2003 | Отправлено: 14:00 31-10-2018

Ykidia Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Редирект сделать можно, и это стандартная тема. Проблема в том, что когда я ввожу http://her.no-ip.info:12480, редирект переводит на этот ваш https://her.no-ip.info:12443, и для него (кто обслуживает редирект) все нормально, а для меня нет, потому что порт 12480 я прокидываю, по сути, вхолостую, по нему никакой работы не идет, кроме редиректа на другой порт. Не отклоняйтесь от темы, пожалуйста, изначально разговор шел про один и тот же порт. То есть, открываю я на роутере порт 12480, прокидываю к своему веб серверу в локалке на порт X: 1) А тот веб сервер, не будь дураком, умеет разделять, по http к нему обратились или по https, на одном и том же порту. 2) Либо на роутере стоит некая примочка, как по ссылкам, что дал уважаемый Mavrikii, которая понимает, что за протокол, и уже прокидывает запросы дальше в локалку на разные порты. 3) Комбо - на машине (в локалке) с веб-сервером установлена примочка-перенаправлялка, как в п.2, а сам веб сервер отвечает только на запросы от 127.0.0.1. Варианты 1 и 3 предпочтительнее, потому что прокидывать порты можно как обычно, и заморачиваться (с разделением протоколов по портам) уже на машине с веб сервером. А вариант 2 для красноглазых, в основном, которые любят для каждого случая делать свою отдельную припарку везде, где только можно; но тоже имеет право на существование )))     Добавлено: В общем, попробую я в ближайшее время по варианту 3 сделать. А то на роутере у меня snapshot OpenWRT, и там некоторые пакеты, в том числе и отвечающий за node.js, отсутствуют. Всего записей: 242 | Зарегистр. 03-03-2005 | Отправлено: 18:24 31-10-2018

Paromshick Silver Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору 1) Сервер будет принимать и разговаривать по HTTPS. После пары ошибок клиента, пытающегося разговаривать по HTTP, даже ранее, будет послан. Если б вы понимали, вы бы этого не написали. Это несерьёзно. 2) "Примочка на роутере" - это реверс прокси, в чём см. п.1   То есть, писать бла, бла, бла:12836 это не сильно напрягает, а вот написать бла, бла, бла:13836 - уже проблема? Ржунимагу.   А замутить тему с умным видом, употребив теримы squid, nginx... вовсе не напряжно.   Вы спросИте, как правильно сделать - вам скажут.   ---------- Скучно Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 21:06 31-10-2018

Ykidia Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Paromshick 1) Потому этот вариант и не подходит. 2) Нет, это не реверс прокси. Вы крайне невнимательно читали тему.   В первом же ответе мне господин Mavrikii достаточно ёмко изложил варианты. Которые я собираюсь попробовать, так что вопрос вроде бы исчерпан, и тему можно было бы закрыть во избежание всяческих невнимательных флудеров и просто троллей. Но хотелось бы услышать и другие варианты, ибо с указанными в OpenWRT туго, хотя у меня есть и Debian. Вот подробно, что мне нужно и как это все выглядит: 1. OpenWRT, установленный на WD MBLD. Там же, в chroot-е, установлен Debian. Работает Transmission (который умеет только HTTP для своего веб-лица), и чтобы заходить извне в его веб-лицо, нужен HTTPS (чтобы не палить логин/пароль, к примеру), поэтому еще работает haproxy как реверс-прокси (только с haproxy мне удалось правильно обрабатывать X-Transmission-Session-Id; иначе веб-лицо постоянно обваливается). 1а. Зачем на таком девайсе OpenWRT? Новейшее ядро, поддерживающее всякие приятности, в частности, камеры, файловые системы, опять же веб-лицо для простейших настроек и т.д.. Производительность чтения/записи оказалась вполне приемлемой для файлопомойки и торрентов. 1б. Зачем Debian с таким извратом? Хотел, чтобы на нем вертелся Syncthing, но жестко обломался, когда выяснилось, что Golang пока что не поддерживает компиляцию для архитектуры powerpc32 (Syncthing написан на языке Go). 2. Роутер Mikrotik, перепрошитый в OpenWRT. Зачем перепрошитый? Хотя бы затем, чтобы на нем вертелись mwan3 (2 разных подключения к инету), adblock и squid+privoxy+tor (сделано примерно по этой статье) и mjpg-streamer. Почему Mikrotik? Потому что, если честно, я лоханулся с выбором, приобретая его несколько лет назад, хотя за такие деньги это чуть ли не самое лучшее железо; плюс чуть позже нашлось применение PoE. В общем, к роутеру подключены 2 веб-камеры. Просмотр ведется через mjpg-streamer, чье веб-лицо также не умеет HTTPS (пока сделано через stunnel), а вводить логин/пароль извне по HTTP стремно. Сейчас уже начинаю думать, что не роутерское это дело - обслуживать веб-камеры, возможно, подключу Rasberry Pi, который все равно большую часть времени валяется без дела.   Да, порты у меня на всё нестандартные. Но писать в браузере "поддомен.no-ip.info:12345" гораздо проще и быстрее, чем "https://поддомен.no-ip.info:12345". Да, мне не влом задать такой вопрос и не лень написать много букв, которые, как видно, не каждому дано осилить, ибо я ленивый, и данная тема меня преследует уже давно всякий раз, когда приходится либо заходить по HTTP, либо приписывать https://. Еще один момент, который выбешивает - если ошибся и явно/неявно указал не тот протокол, далее браузер начинает умничать и использовать ранее введенную информацию, подставлять неправильный протокол, хотя уже указываешь в явном виде правильный; и уже не до захода в веб-интерфейс, а приходится бороться с кешем браузера.   И зачем Вы так нервничаете, да еще и наезжаете на меня? Читайте внимательно вопрос, и увидите, что а) он актуален, б) как оказывается, задача не нерешаема, более того, есть решения и в) значит, ничего "несерьезного" тут нет. Вам такие решения не нужны, или же они непривычны, ну и ладно, никто их Вам не навязывает. Если же Вас оскорбляет употребление мною каких-то терминов, то поверьте, создавая эту тему, я никак не хотел никого обидеть, тем более лично Вас. Всего записей: 242 | Зарегистр. 03-03-2005 | Отправлено: 00:07 01-11-2018

Paromshick Silver Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Ykidia Не внимательно? Возможно. Нет смысла вдаваться в тонкости изобретения вечного двигателя. Как будет работать то, что вынесено в заглавие темы + то, что в принципе похоже на реальность, типа публикации внутреннего web сервера, примерно всем понятно. И в основном сказано, а дальше гугл. Конкретные вопросы сюда. На кружок умелые руки просто нет времени. Не говоря уже о том, что тема сильно смахивает на дубль этой темы: Софт для трансляции аудио/видео/радио по сети ---------- Скучно Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 15:55 01-11-2018

Ykidia Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Конечно же, это и близко никакой не дубль. Для тех, кто понял. Я нашел решение, которое работает, при помощи HAProxy. Node.js, к сожалению, не удалось заставить работать, даже собираться/устанавливаться не захотело это чудо на powerpc32... Итак, вот выдержка из конфига haproxy, которая позволяет принимать любые соединения HTTP/HTTPS на одном порту с редиректом с HTTP на HTTPS на том же порту, плюс SSL termination для веб-лица Transmission:   Код: frontend http-transmission-auto     bind *:19091     mode tcp     tcp-request inspect-delay 100ms     tcp-request content accept if HTTP     tcp-request content accept if { req.ssl_hello_type 1 }     use_backend forward_http if HTTP     default_backend forward_https   frontend http-transmission     bind *:19090     mode http     redirect scheme https code 301 if !{ ssl_fc }   frontend https-transmission     bind *:19092 ssl crt /etc/transmission/transmission.pem     mode http     reqadd X-Forwarded-Proto:\ https     capture request header X-Transmission-Session-Id len 48     capture response header X-Transmission-Session-Id len 48     default_backend transmission   backend forward_http     mode tcp     server serverhttp 127.0.0.1:19090   backend forward_https     mode tcp     server serverhttps 127.0.0.1:19092   backend transmission     mode http     stick-table type binary len 48 size 32k expire 30m     stick store-response hdr(X-Transmission-Session-Id)     stick on hdr(X-Transmission-Session-Id)     server transmission-daemon 127.0.0.1:9091     Гвоздь конфига - frontend http-transmission-auto. Он распознает на одном внешнем порту (19091) и распределяет HTTP и HTTPS на разные внутренние порты (19090 и 19092 соответственно) сам себе. Тут можно остановиться, если SSL termination не нужен, и вместо самого себя указать на реальный сервер, обслуживающий HTTP/HTTPS запросы раздельно, как это принято. Мне же было нужно, чтобы HTTP-соединения в обязательном порядке "обувались" в HTTPS, поэтому в моем случае HAProxy отправляет соответствующие запросы на другие порты, где с HTTP (внутренний порт 19090) делается редирект на HTTPS (внутренний порт 19092), где уже осуществляется SSL termination и "голые" HTTP-запросы, привычные для Transmission, передаются на сервер с веб-лицом Transmission, в моем случае находящийся на том же устройстве, но на другом порту (9091). Возможно, можно как-то перекидывать запросы между frontend-ами без излишних перенаправлений на порты (19090 и 19092), но я об этом не знаю. Если найду как, отпишусь. Всего записей: 242 | Зарегистр. 03-03-2005 | Отправлено: 04:25 19-11-2018 | Исправлено: Ykidia, 20:46 05-01-2019

Ykidia Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Приведу еще пару работающих конфигов, попроще.     Первый - SSL termination + распознавание протокола на едином порту 18080 для MJPG-Streamer: Код: frontend http-webcam-auto     bind *:18080     mode tcp     tcp-request inspect-delay 100ms     tcp-request content accept if HTTP     tcp-request content accept if { req.ssl_hello_type 1 }     use_backend forward-webcam-http if HTTP     default_backend forward-webcam-https frontend http-webcam     bind *:18079     mode http     redirect scheme https code 301 if !{ ssl_fc } frontend https-webcam     bind *:18081 ssl crt /etc/mjpg-streamer.pem     mode http     default_backend webcam backend forward-webcam-http     mode tcp     server webcam-http 127.0.0.1:18079 backend forward-webcam-https     mode tcp     server webcam-https 127.0.0.1:18081 backend webcam     mode http     server mjpg-streamer 127.0.0.1:8080 Сам MJPG-Streamer слушает порт по умолчанию (8080) и находится на том же устройстве (127.0.0.1), что и HAProxy. Так же необходимо заранее подготовить сертификат и положить его в /etc/mjpg-streamer.pem или указать в конфиге другой путь. Сертификат может быть и самоподписанный, можно сделать примерно такой командой Код: openssl req -new -newkey rsa:2048 -days 3650 -sha256 -nodes -x509 -keyout /etc/mjpg-streamer.pem -out /etc/mjpg-streamer.pem     Второй - просто распознавание протокола на едином порту 8443 для веб-интерфейса LuCI: Код: frontend http-luci-auto     bind *:8443     mode tcp     tcp-request inspect-delay 100ms     tcp-request content accept if HTTP     tcp-request content accept if { req.ssl_hello_type 1 }     use_backend forward-luci-http if HTTP     default_backend forward-luci-https frontend http-luci     bind *:8442     mode http     redirect scheme https code 301 if !{ ssl_fc } backend forward-luci-http     mode tcp     server luci-http 127.0.0.1:8442 backend forward-luci-https     mode tcp     server luci-https 127.0.0.1:443 Веб-сервер (в данном конкретном случае это uHTTPd) находится на том же устройстве (127.0.0.1), что и HAProxy. Конфиг подойдет для любого другого веб-сервера, самостоятельно обрабатывающего HTTPS. Всего записей: 242 | Зарегистр. 03-03-2005 | Отправлено: 20:39 05-01-2019 | Исправлено: Ykidia, 00:22 24-06-2019

Компьютерный форум Ru.Board » Компьютеры » В помощь системному администратору » Редирект с HTTP на HTTPS на тот же порт

Переход по форумам  Закладки   » Компьютеры Цифровое изображение Программы Microsoft Windows UNIX Другие OS Hardware В помощь сисадмину Прикладное программирование Игры Форумные игры   » Интернет Web-программирование В помощь вебмастеру Графика Хостинг Зацените-ка!   » Тематические Ikonboard v.2 Ikonboard v.3 Invision Board Другие форумы PHP-Nuke и другие порталы Мобила   » Общие Спорт Флейм Темы по региональным встречам Музыка и Кино Юмор Литература и Живопись   » Ru.Board Новости Помощь по форуму   » Андеграунд eBookz Варезник Раздачи и акции Мобильный варезник Андеграунд Игры и фильмы   » Специальные Тестирование