Зөвхөн VPN-д зориулсан NGINX сайт: listener, галт хана, HTTP зөвшөөрлийн жагсаалт

Хувийн NGINX сайтад холбогдсон VPN socket, хязгаарлагдмал хост оролтын дүрэм, бүрэн бүтэн HTTP хандалтын жагсаалт хэрэгтэй. Нэг серверийн блок биш, бүгдийг шалгана уу.

Хувийн сайт ба интернетийн хооронд гурван бие даасан шийдвэр байдаг: аль socket холболтыг хүлээн авах, аль зам түүнийг хүргэх, сонгосон сервер аль HTTP клиентүүдэд хариулах. Серверийн блок зөвхөн эхний шийдвэрийг гаргана. Бусад хоёрыг тусдаа хяналт гэж үзнэ үү, эс бөгөөс сайт хувийн мэт харагдах боловч хуучин орц нээлттэй үлдэнэ. Зөвхөн VPN-д зориулсан NGINX-ийн ихэнх алдаа нь зөвхөн эхний давхаргыг шалгахаас үүсдэг.

Жишээ нь tun0 дээрх 10.90.0.1 дэх Linux OpenVPN гарц, 10.90.0.0/24 дахь клиентүүд, хадгалагдсан эх сурвалж, энэ орцонд зориулсан TCP 8443-ыг ашигладаг. Утгуудыг тохируулж, давхаргуудыг хадгална уу.

Хост нэрээр биш, socket-ээр эхэл

HTTPS listener-ийг туннелийн хаяг болон тусдаа портод холбоно. Тодорхой хаягийн талаар бодох нь орлуулагч socket болон нэр шалгахаас хялбар, учир нь цөм портыг өөр локал хаягт өгөхгүй.

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 гэмтэл мэт харагдах гэрчилгээний алдаа гарна. Гэрчилгээг солихын өмнө нэрийг шалгана уу.

Файлыг нэмэхийн өмнө үйлчилж буй тохиргоог уншина уу. Оруулга болон орлуулагч listener-үүд ижил үндсийг өөр газарт үйлчилж болно, анхдагч сервер шинэ блок хэзээ ч хардаггүй хүсэлтэд хариулж болно.

Тухайн агуулгын бусад бүх listener-ийг хаа

listen зааварчилгааг жагсааж, тэдгээрийн үйлчилдэг үндсийг харьцуулна уу. Өөр апп-д нэмсэн блок ижил upstream руу прокси хийж болно, хуучин анхдагч сервер шинийг суулгасны дараа ч хариулсаар байж болно. Тэр гаралт бол жинхэнэ бүртгэл, саяхан зассан файл биш. Ижил агуулгад үйлчилдэг үндэс бүрийг харьцуулна уу.

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

Хоёр хаягийн бүлгийг шалгана уу. IPv4 холболт IPv6 socket-ийг хөндөхгүй үлдээдэг, шинэ A бичлэг олон нийтийн зам руу заасан хуучин AAAA хариултыг буцааж татдаггүй.

Хуучин виртуал хостыг тусдаа өөрчлөлтөөр зогсоо. Шинэ блокийн олон нийтийн ихэрийг арилгах нь орцыг үнэхээр хаадаг алхам ихэвчлэн; хувийн listener нь зөвхөн зориулсан орцыг нэмдэг.

Хост дээрх оролтын замыг хязгаарла

Сонсох хаяг нь socket-ийг хязгаарладаг, оролтын интерфейсийг биш. Өөр газраас тэр хаяг руу чиглүүлсэн пакет локал оролт хэвээр ирдэг, тиймээс хост галт хана нь холболт хаанаас ирж болох тухай өөрийн мэдэгдэл хэрэгтэй. Тиймээс зөвхөн холболт нь аудитыг хангах нь ховор.

Анхдагчаар татгалзсан оролтын бодлого, энэ үйлчилгээнд илүү өргөн зөвшөөрөл байхгүй үед хязгаарлагдмал дүрэм туннель, эх сурвалжийн хүрээ, очих газар, портыг хамт нэрлэнэ:

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

Хэрэглэхийн өмнө галт ханын үйлчилж буй дарааллыг уншина уу. Өмнөх өргөн зөвшөөрөл хязгаарлалтыг хүчингүй болгож болно, өмнөх эцсийн хасалт энэ зөвшөөрөлд хүрэхээс сэргийлж болно. Жишээ тохирохын тулд холбоогүй дүрмийг цэвэрлэж, галт ханыг унтрааж болохгүй.

Тэр дүрэм нь хост оролт, өөр LAN машин руу чиглэсэн маршрут биш бөгөөд гарцын гадаад OpenVPN listener нь тусдаа үйлчилгээ хэвээр. Сайт өмнө нь олон нийтэд нээлттэй байсан бол хуучин орцыг хэрхэн зогсоох, одоо байгаа сессийг хэрхэн шийдвэрлэхийг төлөвлөнө үү.

Байршил өөрчлөгдөхөд HTTP жагсаалтыг бүрэн бүтэн байлга

NGINX allow болон deny бичлэгийг дарааллаар үнэлдэг, дээрх серверийн түвшний жагсаалт эцсийн deny-ээс өмнө зарласан бүлгийг оруулна. Хандалтын модуль мөн хандалтын бичлэг тодорхойлсон байршил эх жагсаалтын оронд өөрийн жагсаалтыг ашигладаг гэдгийг бүртгэдэг. Дараалал нь бичлэгүүд шиг л чухал.

Тэр дахин тохируулалт бол ердийн регресс. Нэг бичлэг нэмсэн шинэ upload, API эсвэл эрүүл мэндийн байршил серверийн түвшний хязгаарлалтыг чимээгүй орлуулж, сайт хамгийн сүүлд нэмсэн зам дээр өргөсдөг.

Байршил, alias, өөр блок бүрийг ижил бодлогын хэсэг гэж хянана уу. IP шалгалтыг NGINX баталгаажуулалттай хослуулсан бол satisfy-г ойлго: any тохиргоо клиентийг нэг механизмаар нэвтрүүлж болно, нөгөө нь хараахан давж амжаагүй байхад. Хандалтын жагсаалтыг байршлын хяналтын жагсаалтад оруул.

HTTP татгалзал нь TCP холболт NGINX-д хүрсний дараа болдог. Энэ нь сүлжээний хязгаарлалтыг нөхдөг, програмын өөрийн зөвшөөрөл хэрэглэгч бүрт үргэлжлэн үйлчилнэ.

Амьд зам болон эвдрэлийн тохиолдлыг шалга

Тохиргооны анализаторыг ажиллуулж, сонсож буй socket-уудыг шалгаад, дараа нь зориулсан клиентээс шинэ нэртэй хүсэлт гарга. Гэрчилгээ хүчинтэй, DNS нэр холбогдсон хаяг руу шийдэгдэж, хариулт хүлээгдэж буй үндэснээс ирж байгааг батал.

Дараа нь хасагдсан эх сурвалж болон өөр орцыг турш. Ажиллаж буй зөвшөөрөгдсөн хүсэлт нь хаахыг зорьсон замуудын талаар юу ч хэлэхгүй, хасагдсан туршилтад л үлдсэн listener эсвэл өргөн галт ханын зөвшөөрөл илэрдэг.

Ачаалах эсвэл VPN сэргээх тохиолдлыг давт. Хэрэв NGINX туннелийн хаяг үүсэхээс өмнө эхэлбэл төгс файлтай ч холболт бүтэлгүйтэж болно. Хаягийн бэлэн байдлыг зохицуулж, хуваалцсан вэб серверийг өөрчлөхийн өмнө локал сэргээх замыг хадгал.

Тэнцсэн socket, порт, эх сурвалжийн хүрээ, HTTP жагсаалтыг тэмдэглэ. Дараагийн VPN эсвэл DNS өөрчлөлт тэдгээрийн аль нэгийг нь зөөж болно, дөрвөн нэртэй утгыг ажиллаж буй хөтчийн табаас харьцуулахад хялбар.

Холбоотой нийтлэлүүд