NGINX страница само за VPN: слушач, firewall и листа со 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 одговор што сѐ уште покажува на јавен пат.

Отстранете го стариот виртуелен домаќин како одделна промена. Отстранувањето на јавниот близнак на новиот блок обично е чекорот што навистина го затвора влезот; приватниот слушач само го додава предвидениот.

Ограничете ја влезната патека на домаќинот

Адресата за слушање го ограничува сокетот, не влезниот интерфејс. Пакет упатен кон таа адреса од друго место сѐ уште пристигнува како локален влез, затоа firewall-от на домаќинот бара своја изјава за тоа од каде смее да дојде врската. Затоа само врзување ретко задоволува ревизија.

Со стандардна политика за одбивање на влезниот сообраќај и без поширока дозвола за оваа услуга, ограниченото правило ги именува тунелот, опсегот на изворот, одредиштето и портот заедно:

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

Прочитајте го ефективниот редослед на firewall-от пред да го примените. Претходно широко прифаќање може да го победи ограничувањето, а претходно терминално отфрлање може да спречи оваа дозвола воопшто да се достигне. Не исчистувајте неповрзани правила и не исклучувајте го firewall-от за примерот да се вклопи.

Тоа правило е влез на домаќинот, не маршрута до друга LAN машина, а надворешниот OpenVPN слушач на портата останува одделна услуга. Ако страницата претходно била јавна, испланирајте како стариот влез се отстранува и како се справува со постојните сесии.

Одржете ја HTTP листата непроменета додека се менуваат локациите

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

Тоа ресетирање е вообичаената регресија. Нова локација за поставување, API или здравје што додава еден запис тивко го заменува ограничувањето на ниво на сервер, а страницата станува поширока на најново додадената патека.

Прегледајте ја секоја локација, алијас и алтернативен блок како дел од истата политика. Ако IP проверките се комбинираат со NGINX автентикација, разберете го satisfy: поставката any може да пушти клиент низ еден механизам додека другиот не поминал. Ставете ја листата за пристап во контролната листа за преглед на локации.

HTTP одбивање се случува откако TCP врската ќе стигне до NGINX. Тоа го дополнува мрежното ограничување, а сопствената авторизација на апликацијата сѐ уште важи за секој корисник.

Проверете ја живата патека и случајот на дефект

Стартувајте го анализаторот на конфигурација, прегледајте ги сокетите што слушаат, потоа направете ново именувано барање од предвиден клиент. Потврдете дека сертификатот валидира, DNS името се решава на врзаната адреса и одговорот доаѓа од очекуваната коренска патека.

Потоа тестирајте исклучен извор и алтернативен влез. Барањето што работи и е дозволено не кажува ништо за патеките што сакавте да ги затворите, а токму во исклучениот тест се појавува преостанат слушач или широко прифаќање на firewall-от.

Повторете го случајот на подигање или обнова на VPN. Ако NGINX стартува пред адресата на тунелот да постои, врзувањето може да не успее дури и со совршена датотека. Координирајте ја подготвеноста на адресата и одржувајте локална патека за обнова пред да смените споделен веб сервер.

Запишете ги сокетот, портот, опсегот на изворот и HTTP листата што поминаа. Следната промена на VPN или DNS може да премести кој било од нив, а четири именувани вредности полесно се споредуваат отколку работна картичка во прелистувач.