NGINX локација само за VPN: слушалац, заштитни зид и HTTP листа дозвола

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

Повуците стари виртуелни хост као одвојену измену. Уклањање јавног близанца новог блока обично је корак који заиста затвара улаз; приватни слушалац само додаје предвиђени.

Ограничите улазну путању на хосту

Адреса слушања ограничава сокет, не улазни интерфејс. Пакет усмерен на ту адресу са другог места ипак стиже као локални улаз, зато заштитни зид хоста треба сопствену изјаву о томе одакле веза сме да дође. Зато само повезивање ретко задовољава ревизију.

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

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-а може да помери било који од њих, а четири именоване вредности је лакше упоредити од радне картице прегледача.

Повезани чланци