NGINX сайты: VPN үчүн гана угуучу, брандмауэр жана HTTP уруксат тизмеси

Жеке NGINX сайты байланган VPN сокетин, чектелген хост кирүү эрежесин жана бузулбаган HTTP кирүү тизмесин талап кылат. Үчөөнү тең текшериңиз, бир сервер блокун эмес.

Жеке сайт менен интернеттин ортосунда үч көз карандысыз чечим турат: кайсы сокет байланышты кабыл алат, кайсы жол аны жеткире алат жана тандалган сервер кайсы HTTP кардарларына жооп берет. Сервер блогу биринчи чечимди гана кабыл алат. Калган экөөнү өзүнчө көзөмөл катары караңыз, болбосо сайт жеке болуп көрүнөт, ал эми эски кирүү ачык калат. VPN үчүн гана NGINX каталарынын көбү биринчи катмарды гана текшерүүдөн келип чыгат.

Мисал tun0 боюнча 10.90.0.1 дарегиндеги Linux OpenVPN дарбазасын, 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 өзгөрүү алардын кайсынысын болсо да жылдырышы мүмкүн, ал эми төрт аттуу маанини салыштыруу иштеп жаткан браузер өтмөгүнөн оңой.

Тектеш макалалар