NGINX сайт само за VPN: слушател, защитна стена и списък за достъп по HTTP

Частен сайт NGINX изисква вързан VPN сокет, ограничено правило за входящ трафик на хоста и непокътнат списък за достъп по HTTP. Проверете и трите, не само един сървърен блок.

Три независими решения стоят между частен сайт и интернет: кой сокет приема връзката, кой път може да я достави и на кои HTTP клиенти отговаря избраният сървър. Сървърният блок взема само първото решение. Третирайте другите две като отделни контроли, иначе сайтът ще изглежда частен, докато стар вход остава отворен. Повечето откази на NGINX само за VPN идват от тестване само на първия слой.

Примерът използва Linux шлюз OpenVPN на 10.90.0.1 по tun0, клиенти в 10.90.0.0/24, запазени източници и TCP 8443, запазен за този вход. Нагласете стойностите, запазете слоевете.

Започнете със сокета, не с името на хоста

Вържете HTTPS слушателя към адреса на тунела и отделен порт. Конкретният адрес е по-лесен за обмисляне от универсален сокет плюс проверка на име, защото ядрото няма да даде порта на друг локален адрес.

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

    ssl_certificate     /etc/nginx/tls/admin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/admin-key.pem;

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

Сертификатът трябва да съдържа името на хоста на услугата, което клиентите въвеждат, а частният изглед на DNS трябва да разрешава този хост към вързания адрес. server_name само избира виртуален хост; той не удостоверява никого. Липсващ DNS запис води до грешка със сертификата, която изглежда като TLS повреда. Проверете името, преди да смените сертификата.

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

Затворете всеки друг слушател за това съдържание

Избройте директивите listen и сравнете корените, които обслужват. Блок, добавен за друго приложение, може да препраща към същия upstream, а стар сървър по подразбиране може да продължи да отговаря, след като новият е на място. Този изход е истинският инвентар, а не файлът, който току-що редактирахте. Сравнете всеки корен, който обслужва същото съдържание.

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

Проверете и двете семейства адреси. Връзването на IPv4 оставя IPv6 сокета незасегнат, а нов A запис не отменя стар AAAA отговор, който все още сочи към публичен път.

Оттеглете стария виртуален хост като отделна промяна. Премахването на публичния двойник на новия блок обикновено е стъпката, която наистина затваря входа; частният слушател само добавя желания.

Ограничете входящия път на хоста

Адресът за слушане ограничава сокета, не входящия интерфейс. Пакет, насочен към този адрес от друго място, пак пристига като локален вход, затова защитната стена на хоста се нуждае от собствено изявление откъде може да идва връзката. Затова самото връзване рядко удовлетворява одит.

При политика за входящ трафик по подразбиране „забрани“ и без по-широко разрешение за тази услуга, ограничено правило назовава тунела, диапазона на източника, дестинацията и порта заедно:

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

Прочетете действащия ред на защитната стена, преди да го приложите. По-ранно широко приемане може да осуети ограничението, а по-ранно окончателно отхвърляне може да попречи това разрешение изобщо да бъде достигнато. Не изчиствайте несвързани правила и не изключвайте защитната стена, за да пасне примерът.

Това правило е входящ трафик на хоста, не маршрут към друга машина в LAN, а външният OpenVPN слушател на шлюза остава отделна услуга. Ако сайтът е бил публичен преди, планирайте как старият вход се оттегля и как се обработват съществуващите сесии.

Пазете списъка по HTTP непокътнат при промяна на местоположенията

NGINX оценява записите allow и deny по ред, а списъкът на ниво сървър по-горе допуска обявения пул преди окончателния deny. Модулът за достъп също отбелязва, че местоположение, което дефинира какъвто и да е запис за достъп, използва собствения си списък, а не родителския. Редът е толкова важен, колкото самите записи.

Това нулиране е обичайната регресия. Ново местоположение за качване, API или здраве, което добавя един запис, тихо замества ограничението на ниво сървър и сайтът става по-широк по най-скоро добавения път.

Прегледайте всяко местоположение, псевдоним и алтернативен блок като част от същата политика. Ако IP проверките се комбинират с удостоверяване на NGINX, разберете satisfy: настройка any може да пропусне клиент през един механизъм, докато другият не е преминат. Включете списъка за достъп в контролния списък за местоположенията.

Отказът по HTTP се случва, след като TCP връзката достигне NGINX. Той допълва мрежовото ограничение, а собствената авторизация на приложението продължава да важи за всеки потребител.

Проверете живия път и случая на отказ

Стартирайте анализатора на конфигурацията, прегледайте слушащите сокети, след което направете ново именувано заявка от предвиден клиент. Потвърдете, че сертификатът се валидира, DNS името се разрешава към вързания адрес и отговорът идва от очаквания корен.

След това тествайте изключен източник и алтернативен вход. Работещата разрешена заявка не казва нищо за пътищата, които сте искали да затворите, и именно при изключения тест се показва остатъчен слушател или широко приемане в защитната стена.

Повторете случая на зареждане или възстановяване на VPN. Ако NGINX стартира преди адресът на тунела да съществува, връзването може да се провали дори с безупречен файл. Координирайте готовността на адреса и пазете локален път за възстановяване, преди да променяте споделен уеб сървър.

Запишете сокета, порта, диапазона на източника и списъка по HTTP, които са минали. Следваща промяна на VPN или DNS може да премести всеки от тях, а четири именувани стойности се сравняват по-лесно от работещ раздел на браузъра.

Подобни статии