Тек VPN үшін NGINX сайты: тыңдаушы, брандмауэр және 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 өзгерісі олардың кез келгенін жылжытуы мүмкін, ал төрт атаулы мәнді салыстыру жұмыс істеп тұрған браузер қойындысынан оңай.

Қатысты мақалалар