Nginx deny all не работает

Nginx allow/deny ip

Братья и сестры, прошу вашей помощи.
Кто на опыте, объясните, как ограничить доступ к урлу по ip, с помощью nginx?
Указываю nginx такие параметры:

Директива deny работает. Директива allow не работает. Директивы указываю на сервере, который проксирует запросы.

Кто скажет гуглить — отправляется в ад! Гарантирую это.

Попробуй
allow 195.0.0.0/24;
рекомендую пользоваться командой nginx -t

Посмотри логи, точно-ли запрос на сервер приходит с IP из сети 195.0.0.0/24

Запросы отправляются на локальный сервер 10.0.0.10. А должны отправляться на удаленный 10.0.0.3. При этом директивы отрабатывают верно.

Я неверно указываю location для allow/deny. А как его правильно указать, хер его знает:

Ты ведь в курсе что при твоём текущем конфиге проксирование запросов не будет работать для запросов попадающих в локейшен /admin/? Такие запросы будут обрабатываться локально (в данном случае, видимо, выдавать ошибку). Конфигурация локейшенов не наследуется.

Спасибо за ответ.

Нет, не вкурсе. Молод я. Вы верно говорите, что запросы не проксируются для /admin/.

Если я настрою allow/deny в 10.0.0.3, то придется разрешать не только 100.0.0.19, но и 10.0.0.10, и получается, что никакого ограничения нет =(.

Как это обойти? Может вы работали с такой задачей?

А других возможных source ip кроме этих двух быть не может? Нарисуйте схему сети, не пойму что там у вас к чему

Спасибо за ответ.

«ngx_http_auth_basic_module» Сие уже настроено. Хотелось бы вообще отрезать админку от интернет.

Схема сети: 1. 10.0.0.1 — гетвей 2. 10.0.0.10 — Прокси сервер nginx + ssl. Его конфиг выше. 3. 10.0.0.3 — Сервер веб приложения. 4. 10.0.0.* — Серверы приложений.

Источник

Модуль ngx_http_access_module

Модуль ngx_http_access_module позволяет ограничить доступ для определённых адресов клиентов.

Ограничить доступ можно также по паролю, по результату подзапроса или по JWT. Одновременное ограничение доступа по адресу и паролю управляется директивой satisfy.

Пример конфигурации

Правила проверяются в порядке их записи до первого соответствия. В данном примере доступ разрешён только для IPv4-сетей 10.1.1.0/16 и 192.168.1.0/24 , кроме адреса 192.168.1.1 , и для IPv6-сети 2001:0db8::/32 . Если правил много, то лучше воспользоваться переменными модуля ngx_http_geo_module.

Директивы

Синтаксис:	allow адрес | CIDR | unix: | all ;
Умолчание:	—
Контекст:	http , server , location , limit_except

Разрешает доступ для указанной сети или адреса. Если указано специальное значение unix: (1.5.1), разрешает доступ для всех UNIX-сокетов.

Синтаксис:	deny адрес | CIDR | unix: | all ;
Умолчание:	—
Контекст:	http , server , location , limit_except

Запрещает доступ для указанной сети или адреса. Если указано специальное значение unix: (1.5.1), запрещает доступ для всех UNIX-сокетов.

Источник

Nginx deny all, Nginx deny ip — ограничение доступа к сайту

Можно задать ограничение в целом для веб-сервера в nginx.conf, но чаще требуется сделать это для определенного сайта. В этом случае нужен конфигурационный файл виртуального хоста.

location / <
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

deny 123.123.123.0/24;
deny 91.91.91.91;

error_page 403 /error403.html;

(приведен фрагмент конифга для связки Nginx-Apache2, может быть и любая другая конфигурация)

Директивой deny запрещается доступ клиенту 91.91.91.91 и клиентам из подсети 123.123.123.0/24.

Чтобы изменения вступили в силу нужно проверить конфигурацию и перезапустить Nginx

Дополнительно указали директиву error_page 403 /403error.html;

Этой директивой задается пользовательская страница ошибки 403. Клиенты, которым запрещен доступ не увидят ошибки, а увидят заранее подготовленную для них html страницу необходимого содержания.Страницу с именем 403error.html нужно разместить в корне сайта.

Содержимое может быть любым. Чаще всего имеет смысл выводить на ней сообщение о том, что доступ запрещен или показывать стандартную страницу Niginx, которая открывается при обращении по IP адресу.

Указав директиву deny all можно полностью закрыть доступ к сайту. В Nginx такие директивы прописываются если Apache не используется или если его конфигурация не позволяет задавать ограничения в файле .htaccess.

Источник

Nginx сайт недоступен извне.

Nginx сайт недоступен извне.

Вот конфиг из sites-enabled

Телепаты в отпуске. Ты представляешь, по скольким причинам он может быть недоступен? Ты б хоть логи приложил, что ли

читать пробовал? allow/deny

два Ъ нашли друг друга. один не читая создаёт тему, другой не читая отвечает

location /doc/ же. К корню-то доступ должен быть

Ну извините, просто я большой ламер в Linux,а на счет сайта могу сказать, что вроде все настроил правильно: dns прописал, в конфиги все вписал по туториалам, но нифига.

согласен, я был невнимателен

Я не уверен, что проблема в конфиге nginx

А в чем тогда может быть? Может dns неправильно пробросил? Вот скрины(домен на reg.ru регал):

Да ничего, тут, к тому же, и не в nginx дело вовсе

А в чем тогда может быть?
Note: Host seems down

Ну либо ты наворотил там фильтрацию nmap и ICMP-пакетов

Скорее всего у тебя фаервол запрещает входящие подключения на 80-й порт. Выполни sudo iptables -F если всё заработает, значит дело в этом. Изучай документацию по iptables, своему дистрибутиву, настраивай всё как тебе нужно.

С IPtables все норм, я вроде в свое время уже с ним намучался, вот лог iptables -L

а по ip открывается извне? или у тебя несколько сайтов на одном ip? если не открывается по ip то значит проблема у тебя, если открывается то проблема с настройкой домена

ps попробовал открыть твой ip не фурычит, смотри настройки наружу экран и т.д. выше XMs это подтвердил

ip 95.25.228.151 — точно твой?
локально работает имено на этот ip?
nmap говорит что порт закрыт

Источник

Установка и базовая настройка nginx и php-fpm для разработки проектов локально в Ubuntu 16.04

Здравствуй, уважаемый пользователь Хабрахабра. Мое повествование будет о том, как подготовить почву для локальной веб-разработки проектов в операционной системе Ubuntu 16.04.1 LTS.

В данной статье хочется развеять и разъяснить возможные трудности связанные с установкой и настройкой ПО, которое требуется для современной веб-разработки, с которыми возможно сталкиваются начинающие разработчики и не только.

Технологии которые будут использованы в статье: nginx, php-fpm.

Перед началом повествования, хочу отметить, что я проделывал все эти действия на «голой» системе.
Я буду работать с пакетным менеджером aptitude. Так же рекомендую обновить индекс пакетов и сами пакеты перед установкой ПО. В статье мы проделаем эти действия вместе.

Установка пакетного менеджера aptitude, обновление индекса и пакетов

Обновляем пакеты (команда обновит все пакеты, для которых есть новые версии, если потребуется удаление пакетов, то оно будет выполнено).

Установка и настройка nginx (версия >= 1.10.0)

Проверяем версию, чтобы убедиться что не установили старую, то есть ниже 1.10.0.

Установку и запуск произвели, теперь пойдем в каталог туда куда установлен наш nginx и посмотрим на его структуру. Каталог nginx находится по такому пути:

Посмотреть содержимое директории можно командой ls, с флагами -la будет удобнее просматривать содержимое каталога (в действительности эту команду с конкретными флагами можно описать детальнее и вернее, но у нас сегодня другая тема).

Наc интересуют в данный момент два каталога, которые вы видите на скриншоте. Это каталоги sites-available и sites-enabled.

Давайте перейдем в каталог sites-available и начнем конфигурировать наш виртуальный хост (сайт).

Перед началом создания конфигурационного файла, проверим что лежит у нас в данном каталоге. В моей случае каталог не пустой, в нем уже есть конфигурационные файлы, я их затер, чтобы не вводить вас в заблуждение.

В случае установки nginx «с нуля», именно «с нуля», так как при удалении nginx командой
или конфигурационные файлы остаются и если вы вдруг будете не понимать, почему nginx не работает и захотите его переустановить (обычно к такому прибегают начинающие пользователи Linux), то и после переустановки он не будет корректно работать, из-за того что в старых конфигурационных файлах (они не удаляются после удаления командой remove) прописаны неверные настройки, их придется удалить, либо настроить верно, только тогда nginx заработает.

Рекомендую удалять командой sudo apt-get purge nginx или sudo apt purge nginx . Если вы используете пакетный менеджер aptitude, то команда sudo aptitude purge nginx удаляет пакет полностью со всеми зависимостями и конфигурационными файлами.

В этом каталоге будет по умолчанию один файл, с названием default. В нем будет конфигурационный файл с примером, с комментариями, его вы можете изучить на досуге, а можете и вовсе удалить (всегда можно обратиться к официальной документации).

Создадим свой конфигурационный файл, который будет соответствовать названию домена нашего локального сайта (или реального, если уже знаете его название). Это удобно, в будущем, когда будет много конфигурационных файлов, то это избавит вас от путаницы в них. У меня этот файл будет называться project.local.

Посмотрим что получилось.

Теперь откроем его в редакторе, я открою его в nano.

Видим что он у нас пустой. Теперь перейдем к формированию нашего файла. Нужно привести конфигурацию к такому виду, как написано ниже. Я опишу только жизненно важные директивы этого файла, описывать остальное не буду, так как это не является на данный момент важным, все-таки у нас тема базовой настройки. Этих настроек с «горкой» хватит для разработки проектов локально, не только мелких, но и довольно крупных. В следующих статьях опишу отдельно каждые использованные директивы (именно так называются строки, например server_name) этого файла.

Смотрите комментарии прям в конфигурационном файле.

Сохраняем файл. Теперь нам надо проверить, нет ли в нем ошибок. Сделать мы это можем командой.

Если видим такую информацию как на скриншоте, значит у нас все верно, может продолжать настройку. Если вы получаете какие-либо ошибки, стоит перепроверить конфигурационный файл.

Теперь нам надо активировать конфигурационный файл, в каталоге /etc/nginx/sites-enabled/ необходимо создать симлинк (символическая ссылка). Если у вас nginx был установлен «с нуля», то в этом каталоге есть симлинк на файл default, про который рассказывалось выше, его можно удалить, если он вам не требуется. Переходим в нужный каталог.

Теперь мы в нужном каталоге. Давайте создадим наш симлинк. Для создания используется команда ln с флагом -s, далее мы укажем путь до нашего конфига project.local.

Посмотрим на наш созданный симлинк.

Чтобы убедиться что мы делаем еще все верно опять запустим команду.

Если все ок, едем дальше.

Файл hosts

Этот файл находится по пути /etc/hosts. Наличие в нем записей, позволяет запускать nginx с использованием в качестве домена localhost. В этом файле можно присваивать альтернативные псевдонимы, например для нашего проекта project.local, мы присвоим домен project.local.

Открываем файл в редакторе nano.

У вас в этом файле будет и другая информация, просто игнорируйте ее. Вам всего лишь нужно добавить строку как на моем скриншоте.

Не забываем сохранить файл. На этом настройка файла hosts закончена.

Установка php-fpm (>=7.0)

Проверяем установленную версию, на всякий случай, хотя в Ubuntu 16.04.1 в репозиториях лежит именно 7.0 версия.

Убеждаемся что все ок. Стартуем php-fpm.

Если будете править конфиги, то не забывайте рестартовать демон. Это делает так. Но нам это не потребуется.

На этом установка и настройка php-fpm закончена. Правда, это все. Это не магия, путь до сокета php-fpm у нас уже был прописан в конфигурационном файле. Конечно, вам могут понадобиться какие-либо расширения php для разработки личных проектов, но их вы можете поставить по мере того как они будут требоваться.

Теперь пойдем для в каталог с нашим проектом, у меня он лежит по такому пути.

Поднимемся на каталог выше и сделаем права 777 (то есть мы будем делать полные права каталогу с нашим проектом project.local). В будущем это избавим нас от лишних проблем.

На этом настройка ПО завершена, давайте создадим тестовый файл в нашем рабочем каталоге project.local и убедимся что все работает. Я создам файл index.php с таким содержанием.

Идем в браузер и видим что у нас все прекрасно работает! Интерпретатор php в том числе.

Источник