Site NGINX doar pentru VPN: listener, firewall și lista de permisiuni HTTP

Un site NGINX privat are nevoie de un socket VPN legat, de o regulă de intrare de host limitată și de o listă de acces HTTP intactă. Testați toate trei, nu un singur bloc de server.

Trei decizii independente stau între un site privat și internet: ce socket acceptă conexiunea, ce cale o poate livra și căror clienți HTTP le răspunde serverul ales. Un bloc de server ia doar prima decizie. Tratați celelalte două ca măsuri de control separate, altfel site-ul va părea privat în timp ce o intrare veche rămâne deschisă. Majoritatea defecțiunilor NGINX doar pentru VPN provin din testarea doar a primului strat.

Exemplul folosește o poartă Linux OpenVPN la 10.90.0.1 pe tun0, clienți în 10.90.0.0/24, surse păstrate și TCP 8443 rezervat pentru această intrare. Ajustați valorile, păstrați straturile.

Începeți cu socketul, nu cu numele de host

Legați listenerul HTTPS de adresa tunelului și de un port dedicat. O adresă specifică este mai ușor de analizat decât un socket wildcard plus o verificare de nume, deoarece nucleul nu va da portul altei adrese locale.

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;
    }
}

Certificatul trebuie să conțină numele de host al serviciului pe care îl tastează clienții, iar vizualizarea DNS privată trebuie să rezolve acel host la adresa legată. server_name doar alege un host virtual; nu autentifică pe nimeni. O intrare DNS lipsă produce o eroare de certificat care arată ca o defecțiune TLS. Verificați numele înainte de a înlocui certificatul.

Citiți configurația efectivă înainte de a adăuga fișierul. Includerile și listenerii wildcard pot servi aceeași rădăcină în altă parte, iar un server implicit poate răspunde la cereri pe care noul bloc nu le vede niciodată.

Închideți orice alt listener pentru acel conținut

Enumerați directivele listen și comparați rădăcinile pe care le servesc. Un bloc adăugat pentru altă aplicație poate face proxy către același upstream, iar un server implicit vechi poate continua să răspundă după ce noul este pus. Acea ieșire este inventarul real, nu fișierul pe care tocmai l-ați editat. Comparați fiecare rădăcină care servește același conținut.

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

Verificați ambele familii de adrese. O legare IPv4 lasă netulburat un socket IPv6, iar o înregistrare A nouă nu retrage un răspuns AAAA vechi care încă indică o cale publică.

Retrageți vechiul host virtual ca modificare separată. Eliminarea geamănului public al noului bloc este de obicei pasul care închide efectiv intrarea; listenerul privat doar îl adaugă pe cel dorit.

Limitați calea de intrare pe host

Adresa de ascultare limitează socketul, nu interfața de intrare. Un pachet rutat către acea adresă din altă parte ajunge totuși ca intrare locală, de aceea firewallul hostului are nevoie de propria declarație despre de unde poate veni conexiunea. De aceea o singură legare satisface rar un audit.

Cu o politică de intrare care refuză implicit și fără o permisiune mai largă pentru acest serviciu, o regulă limitată numește împreună tunelul, intervalul sursă, destinația și portul:

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

Citiți ordinea efectivă a firewallului înainte de a o aplica. O acceptare largă anterioară poate anula restricția, iar o respingere terminală anterioară poate împiedica atingerea acestei permisiuni. Nu goliți reguli irelevante și nu opriți firewallul ca să se potrivească exemplul.

Acea regulă este intrare de host, nu o rută către altă mașină din LAN, iar listenerul OpenVPN extern al porții rămâne un serviciu separat. Dacă site-ul era public înainte, planificați cum este retrasă intrarea veche și cum sunt tratate sesiunile existente.

Păstrați lista HTTP intactă atunci când se schimbă locațiile

NGINX evaluează intrările allow și deny în ordine, iar lista la nivel de server de mai sus admite grupul declarat înainte de deny final. Modulul de acces înregistrează și că o locație care definește orice intrare de acces folosește propria listă, nu lista părinte. Ordinea contează la fel de mult ca intrările în sine.

Acea resetare este regresia obișnuită. O nouă locație de încărcare, API sau stare care adaugă o intrare înlocuiește în tăcere restricția de la nivel de server, iar site-ul devine mai larg pe calea adăugată cel mai recent.

Examinați fiecare locație, alias și bloc alternativ ca parte a aceleiași politici. Dacă verificările IP sunt combinate cu autentificarea NGINX, înțelegeți satisfy: o setare any poate admite un client printr-un mecanism în timp ce celălalt nu a trecut. Puneți lista de acces în lista de verificare a locațiilor.

Un refuz HTTP are loc după ce conexiunea TCP ajunge la NGINX. El completează restricția de rețea, iar autorizarea proprie a aplicației se aplică în continuare fiecărui utilizator.

Verificați calea activă și cazul de eșec

Rulați analizatorul de configurare, inspectați socketurile în ascultare, apoi faceți o cerere nouă cu nume de la un client prevăzut. Confirmați că certificatul se validează, numele DNS se rezolvă la adresa legată și răspunsul vine din rădăcina așteptată.

Testați apoi o sursă exclusă și o intrare alternativă. O cerere permisă care funcționează nu spune nimic despre căile pe care voiați să le închideți, iar în testul exclus apare un listener rămas sau o acceptare largă a firewallului.

Repetați cazul de pornire sau de recuperare VPN. Dacă NGINX pornește înainte ca adresa tunelului să existe, legarea poate eșua chiar și cu un fișier perfect. Coordonați disponibilitatea adresei și păstrați o cale locală de recuperare înainte de a schimba un server web partajat.

Înregistrați socketul, portul, intervalul sursă și lista HTTP care au trecut. Următoarea schimbare VPN sau DNS poate muta oricare dintre ele, iar patru valori numite sunt mai ușor de comparat decât o filă de browser funcțională.

Articole similare