CUPS «400 Bad Request». Решение проблемы.

Автор electroz, 14 Ноября 2013, 20:38

« предыдущая тема - следующая тема »

0 Пользователей и 1 Гость просматривают эту тему.

electroz

Появилась нужда заходить на CUPS удалено и подключать принтеры через сервис DynDns. При вводе адреса http://localhost:631 на сервере или по IP на клиенте из локальной сети http://ip_сервера:631 все прекрасно работает и заходит. Но при попытке зайти удаленно из дома через DynDns например по адресу server.dyndns.org:631 появлялась ошибка «400 Bad Request». Немного погуглив и перепробовав несколько вариантов нашел один верный.

Для решения проблемы нужно в файл cupsd.conf добавить параметр ServerAlias и добавить ваш адрес, в моем примере это server.dyndns.org у вас конечно он будет другой.

Открываем файл из под рута текстовым редактором nano
sudo nano /etc/cups/cupsd.conf

И добавляем в конец файла
ServerAlias server.dyndns.org (server.dyndns.org нужно будет сменить на ваш адрес)

Сохраняем файл нажатием Ctrl+O, закрываем файл Ctrl+X и перезагружаем CUPS
sudo /etc/init.d/cups restart

Ну а теперь можно пробовать зайти удаленно.

sotrud_nik

А вход по локальной сети не сломается?

electroz

нет не сломается, я как с локалки, так и удалено сейчас захожу без проблем

sotrud_nik

А почему не настраиваешь через Ajenti?

electroz

там вроде нет  поддержки CUPS :(, да и меня интерфейс CUPS'а вполне устраивает, я уже к нему привык как-то :)

sotrud_nik

Я в том смысле что все это от лукавого. Тем более вытаскивать интерфейс веб-морды наружу

electroz

ну без этого никак, я не всегда могу находится рядом с сервером, когда настраивал проброс портов, то конечно изменил стандартный порт который смотрит в интернет, тем более чтоб что-нить сделать нужно ввести логин и пароль для администрирования

hedgeven

Цитата: sotrud_nik от 14 Ноября 2013, 21:23
Я в том смысле что все это от лукавого. Тем более вытаскивать интерфейс веб-морды наружу


Полностью согласен. Уязвимостей в подобных внутренних веб-сервисах полно и выставлять их в мир не стоит. Но если нет возможности поднять VPN, то можно хотя бы через iptables дать доступ на этот порт только с определенных сетей (напр. 192.168.0.0/16, 95.57.200.0/21).
А измененный порт защищает ровно на время, необходимое nmap'у для поиска открытых портов, и спасает только от тупых ботов.
Jah will give us everything...

electroz

Цитата: hedgeven от 14 Ноября 2013, 21:55
Цитата: sotrud_nik от 14 Ноября 2013, 21:23
Я в том смысле что все это от лукавого. Тем более вытаскивать интерфейс веб-морды наружу


Полностью согласен. Уязвимостей в подобных внутренних веб-сервисах полно и выставлять их в мир не стоит. Но если нет возможности поднять VPN, то можно хотя бы через iptables дать доступ на этот порт только с определенных сетей (напр. 192.168.0.0/16, 95.57.200.0/21).
А измененный порт защищает ровно на время, необходимое nmap'у для поиска открытых портов, и спасает только от тупых ботов.


сам проверял nmap'ом и он конечно все прекрасно находит, iptables почти так и настроил, но мне в основном нужны сети tele2 т.к. удаленно я захожу в основном с планшета

Yuriy_Y

Как вариант, настрой себе на сервере терминальный доступ через ssh посредством FreeNX. И наружу можно выставлять единственный порт ssh, который сломать ой как непросто, если даже поставить единственный сторожок fail2ban. Не знаю, правда, есть ли клиент FreeNX для андроида. Но очень удобно. Рабочий стол на порту ssh. У меня так на всех серверах почти.
С уважением, Юрий

sotrud_nik

Цитата: Yuriy_Y от 15 Ноября 2013, 08:26
Как вариант, настрой себе на сервере терминальный доступ через ssh посредством FreeNX. И наружу можно выставлять единственный порт ssh, который сломать ой как непросто, если даже поставить единственный сторожок fail2ban. Не знаю, правда, есть ли клиент FreeNX для андроида. Но очень удобно. Рабочий стол на порту ssh. У меня так на всех серверах почти.


Как вариант, могут просто заDDOSить.

Yuriy_Y

Могут. А может и сеть у провайдера упасть. Вероятность примерно одинакова.
С уважением, Юрий