Comments 10
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 443 -j DNAT --to-destination :8443Не благодарите.
Никто благодарить и не будет, ваш коммент не имеет отношения к тому о чем говорилось в статье. С помощью ipables вы ни протокол ни хостнэйм которым пользуется браузер пользователя не измените.
Вот только необходимость указывать порт отпадает сама собой, и клиент приходит на нужный порт, основываясь на указанном протоколе.
Эти люди создали себе проблему на ровном месте, а теперь хвастаются костылями.
Эти люди создали себе проблему на ровном месте, а теперь хвастаются костылями.
А что в вашем варианте делать людям, которые хотят попасть по https на свой сайт а не в панель управления?
Очевидно, разрулить записью
cp.example.com. IN CNAME example.com.а если кастомер хочет использовать этот хостнейм для себя?
Очевидно, использовать другой хостнейм. Ну или по пути разрулить в нжинксе. В любом случае дописывание понятного (читай: запоминающегося) буквенного префикса в начале или буквенного суффикса в конце – гораздо более человечное поведение, чем дописывание непонятного численного суффикса.
Говорить пользователю о необходимости указать нестандартный порт – это первый шаг в расчеловечивании своих клиентов. Я не знаю, кто ваши клиенты, но на их месте я бы воспротивился расчеловечиванию.
Говорить пользователю о необходимости указать нестандартный порт – это первый шаг в расчеловечивании своих клиентов. Я не знаю, кто ваши клиенты, но на их месте я бы воспротивился расчеловечиванию.
Давайте порассуждаем :)
Мне кажется, вы преувеличиваете степень «расчеловечивания». Для приложения работающего в рамках одного сервера данное решение оптимально.
Да, наши мультисерверные продукты (PPA, PA) имеют единую «точку входа» и там такого вопроса нет, потому что сервер где хостится клиентский сайт и сервер где работает панель управления не один и тот же. Поэтому на каждом сервере, на 443 порту слушают соответствующие вебсервера: на менеджмент ноде — панель, на сервисной ноде — клиентский вебсервер. В рамках одного сервера вы такого добиться не сможете.
использовать другой хостнейм— для каждого пользователя свой? А не слишком ли сложно? Добавим сюда сломаный или бесполезный UX. Плюс необходимость где-то заранее это настроить для каждого клиента.
Ну или по пути разрулить в нжинксе— опять же, а если этот путь хочет использовать кастомер? А если клиентский вебсервер сломан (битая конфигурация), то как клиент попадет в панель управления, чтобы исправить ситуацию?
Мне кажется, вы преувеличиваете степень «расчеловечивания». Для приложения работающего в рамках одного сервера данное решение оптимально.
Да, наши мультисерверные продукты (PPA, PA) имеют единую «точку входа» и там такого вопроса нет, потому что сервер где хостится клиентский сайт и сервер где работает панель управления не один и тот же. Поэтому на каждом сервере, на 443 порту слушают соответствующие вебсервера: на менеджмент ноде — панель, на сервисной ноде — клиентский вебсервер. В рамках одного сервера вы такого добиться не сможете.
Ну я, например, как разработчик демона, который слушает SSL в юзерспейсе, использую как раз порт 8443, чтобы принимать соединения. Это решает проблему запуска под непривилегированным юзером. Так что все аргументы про «вдруг хостнейм или путь понядобятся пользователю» я считаю бессмысленными, так как мне, например, удобно использовать именно этот порт.
Далее, если вы говорите о сломанном клиентском вебсервере, то предполагается, что клиент достаточно компетентен, чтобы сломать нжинкс. В таком случае он достаточно компетентен, чтобы настроить файрволл, зарезав вашу дырку. В обратном случае файлик
Далее, если вы говорите о сломанном клиентском вебсервере, то предполагается, что клиент достаточно компетентен, чтобы сломать нжинкс. В таком случае он достаточно компетентен, чтобы настроить файрволл, зарезав вашу дырку. В обратном случае файлик
/etc/nginx/conf.d/cpanel.conf – гораздо более элегантное решение, чем непонятный демон в чужой системе.Как это вам поможет избавиться от предупреждения о не валидном сертификате в браузере?
Sign up to leave a comment.
Как правильно «послать» клиента