ОБРАТНЫЙ ПРОКСИ-СЕРВЕР NGINX
Топология домашней сети постепенно усложняется и, кажется, пора бы уже настроить обратный прокси-сервер. Суть его работы сводится к тому, чтобы перенаправлять запросы по разным серверам. Так, набрав в адресной строке браузера madmentat.ru, мы попадаем на Mad-PC3, а если mail.madmentat.ru, то на веб-морбу почтового сервера Mad-PC4. Ну, и таких поддоменов можно наделать чертову уйму, на все случаи жизни. К тому же, получается, все ssl сертификаты теперь хранятся в одном месте и больше не надо долго компостировать себе мозги, чтобы, например, включить https протокол на Микротике. Все делает уже знакомый нам и простой в использовании Cerbot.
Отмечу, что первоначальная настройка заняла у меня довольно много времени, мой nginx наотрез отказывался заводиться. Три дня искал причину, потом все-таки не выдержал и обратился за помощью к фрилансеру. Заплатил денег, но не так уж и много, за то уже вместе мы докапались до сути проблемы - оказалось все дело в том, что на том же компе (Mad-PC2) был установлен apache2, так что, если у вас по каким-то причинам не получается настроить обрытный прокси-сервер, необходимо убедиться, что больше никакие сервисы не перехватывают запросы, обращаемые через 80-й и 443-й порты. Для этого можно воспользоваться программой, вроде TCP Connector. Подключаемся на порт 80 и шлем запрос типа
<code>ProductOnly</code>
 |
 |
На самом деле, там пофигу чего писать - скорее всего, в ответ все равно вернется страничка в виде html кода, с сообщением об ошибке, и там будет видно что за сервак отработал по запросу. Если вы настраиваете nginx, то, соответственно, Апача там быть не должно, а если уж у вас по какой-то причине все-таки установлен Апач и вы не можете от него отказаться, тогда готовьтесь задрачиваться с настройкой портов, которые слушают ваши серваки, чтобы они друг другу не мешали.
В данном примере рассмотрим следующий кейс: наш виртуальный сервер Apache 2, расположенный, согласно схеме, на Mad-PC3 с контекстом test.madmentat.ru, слушает порт 8080. Итак, пожалуй, приступим.
Для начала установим сам nginx:
sudo apt install -y nginx
Далее создадим файл конфигурации.
sudo nano /etc/nginx/sites-available/test.conf
server {
server_name test.madmentat.ru www.test.madmentat.ru;
access_log /var/log/nginx/test.log;
error_log /var/log/nginx/test-error.log;
location / {
proxy_pass http://192.168.88.238: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;
}
}
sudo cp /etc/nginx/sites-available/test.conf /etc/nginx/sites-enabled/test.conf
Теперь установим cerbot и установим сам сертификат на сервер.
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d test.madmentat.ru -d www.test.madmentat.ru
К слову, cerbot любит поебывать мозги, если не может достучаться до проксируемого хоста. Лучше всего там подготовить голый виртуальный сервер с обычными портами и стандартным index.html, "Hello World!", и только потом запустить скрипт на нашем nginx. Сам скрипт будет задавать вопросы, надо отвечать исходя из контекста - там ничего сложного. Вот, собственно, и все. Пример тут.
ЧАСТЬ 2, СИЛЬНО ПОЗЖЕ
Работая, в компании АРД-Системы Северо-Запад, я столкнулся с локальным распиздяйством со стороны нашего провайдера Инфолан. А весь сыр-бор случился из-за камеры наблюдения, охватывающей наш парадный вход и ворота склада. Очень важный объект, требующий особого внимания. До того как я принял на себя роль местного сисадмина, тут приезжали их ребята и настроили эту камеру.... Таким образом, чтобы она оказалась не в общей сети, а в подсети, черз роутер. То есть, им пришлось пробросить порты через NAT основного шлюза на Кинетик, и через кинетик на саму камеру. В какой-то момент я, естественно, этот Кинетик нахуй выкинул в коробку с таким же барахлом, а камеру оставил в общей сети, и пароль на ней сбросил, так как надо было подключить ее к нашему видеорегистратору... Изучил внимательней настройки Микротика - а там порты были проброшены 80 и 8080 на тот Кинетик... Причем, как оказалось, 8080 вообще даже и не работал... То есть, они подключили камеру напрямую через порт 80! Вот прямо так, незатейливо! Но ведь при таком раскладе вырастает целая проблема... Представляете, какая имено? Вообще-то у меня тут веб-серверы работают и так далее... И я не знал, как ее решить, ну почему-то не приходило на ум, хотя к тому моменту у меня уже был настроен прокси-nginx для внутренних нужд и DNS сервер для AD. Проблема заключалась в том, что порт 80 в итоге слушал мой реверс- прокси-Nginx, а не камера, и, конечно, картинка не транслировалась в облако. Пробовал с ними общаться... Несколько раз звонил, писал всякие кляузы, чтобы они на своем облачном серваке настройку поменяли - хуй там плавал, ни в какую не хотят! Столько нервов на них потратил... Наконец-то меня осенило... Посмотрел в настройки Trassir-клиента, там был указан сервер trassir2.gorod.tv. Пробил его IP комндой dig., и настроил новый конфиг на Nginx-реверс-прокси:
sudo nano /etc/nginx/sites-enabled/trassir.conf
server {
listen 80;
# Проверяем, что запрос пришел из подсети 46.32.68.0/24 для камеры
location / {
set $is_trassir_subnet 0;
if ($remote_addr ~ ^46\.32\.68\.) {
set $is_trassir_subnet 1;
}
# Если это подсеть Trassir, проксируем на камеру
if ($is_trassir_subnet) {
proxy_pass http://192.168.88.37:80; # IP вашей камеры
break;
}
# Если запрос не из подсети Trassir, проксируем на основной сервис
proxy_pass http://localhost; # Замените на ваш основной сервис
}
# Директивы проксирования, которые должны быть глобально для всех location
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
sudo systemctl restart nginx
То есть, мы тут слушаем порт 80 и если запросы приходят из подсети 46.32.68.0/24, тогда перенапрвляем из на камеру, а если откуда-то еще, тогда проксируем на локальный хост! Вот и все решение, ребята! Целый месяц нервотрепки, а оказалось все так просто...