Сайт NGINX толькі для VPN: слухач, міжсеткавы экран і спіс доступу HTTP

Прыватнаму сайту NGINX патрэбны прывязаны сокет VPN, абмежаванае правіла ўваходу на хаспе і цэлы спіс доступу HTTP. Правярайце ўсе тры, а не адзін блок сервера.

Паміж прыватным сайтам і інтэрнэтам стаяць тры незалежныя рашэнні: які сокет прымае злучэнне, які шлях можа яго даставіць і якім кліентам HTTP адказвае выбраны сервер. Блок сервера прымае толькі першае рашэнне. Астатнія два разглядайце як асобныя сродкі кантролю, інакш сайт будзе выглядаць прыватным, пакуль стары ўваход застаецца адкрытым. Большасць збояў NGINX, прызначаных толькі для VPN, паходзіць ад праверкі толькі першага ўзроўню.

Прыклад выкарыстоўвае шлюз OpenVPN на Linux па адрасе 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 і параўнайце карані, якія яны абслугоўваюць. Блок, дададзены для іншай праграмы, можа перанакіроўваць на тую ж вышэйшую крыніцу, а стары сервер па змаўчанні можа працягваць адказваць пасля ўсталявання новага. Гэты вывад і ёсць сапраўдны інвентар, а не файл, які вы толькі што змянілі. Параўнайце кожны корань, які абслугоўвае тое ж змесціва.

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 можа зрушыць любы з іх, і чатыры названыя значэнні параўноўваць лягчэй, чым працоўную ўкладку браўзера.

Падобныя артыкулы