NGINX stranica samo za VPN: listener, firewall i HTTP popis dopuštenja

Privatna NGINX stranica treba vezani VPN socket, ograničeno pravilo ulaza na hostu i netaknut HTTP popis pristupa. Testirajte sva tri, ne samo jedan blok poslužitelja.

Tri nezavisne odluke stoje između privatne stranice i interneta: koji socket prihvata vezu, koji put je može dostaviti i kojim HTTP klijentima odgovara izabrani server. Serverski blok donosi samo prvu odluku. Tretirajte druge dvije kao odvojene kontrole, inače će stranica izgledati privatno dok stari ulaz ostaje otvoren. Većina NGINX kvarova samo za VPN dolazi od testiranja samo prvog sloja.

Primjer koristi Linux OpenVPN gateway na 10.90.0.1 na tun0, klijente u 10.90.0.0/24, sačuvane izvore i TCP 8443 rezervisan za ovaj ulaz. Prilagodite vrijednosti, zadržite slojeve.

Počnite sa socketom, a ne s imenom hosta

Vežite HTTPS listener na adresu tunela i namjenski port. Konkretna adresa je lakša za razmišljanje od wildcard socketa plus provjere imena, jer kernel neće dati port drugoj lokalnoj adresi.

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

Certifikat mora sadržavati ime hosta usluge koje klijenti upisuju, a privatni DNS pogled mora taj host razriješiti na vezanu adresu. server_name samo bira virtualni host; on nikoga ne autentifikuje. Nedostajući DNS zapis daje grešku certifikata koja izgleda kao TLS kvar. Provjerite ime prije nego zamijenite certifikat.

Pročitajte efektivnu konfiguraciju prije dodavanja datoteke. Uključenja i wildcard listeneri mogu posluživati isti korijen drugdje, a podrazumijevani server može odgovarati na zahtjeve koje novi blok nikada ne vidi.

Zatvorite svaki drugi listener za taj sadržaj

Navedite listen direktive i uporedite korijene koje poslužuju. Blok dodat za drugu aplikaciju može prosljeđivati na isti upstream, a stari podrazumijevani server može nastaviti odgovarati nakon što je novi postavljen. Taj izlaz je pravi inventar, ne datoteka koju ste upravo uredili. Uporedite svaki korijen koji poslužuje isti sadržaj.

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

Provjerite obje porodice adresa. IPv4 vezanje ostavlja IPv6 socket netaknutim, a novi A zapis ne povlači stari AAAA odgovor koji još pokazuje na javni put.

Povucite stari virtualni host kao odvojenu promjenu. Uklanjanje javnog blizanca novog bloka obično je korak koji zaista zatvara ulaz; privatni listener samo dodaje predviđeni.

Ograničite dolazni put na hostu

Adresa slušanja ograničava socket, ne ulazno sučelje. Paket rutiran na tu adresu s drugog mjesta ipak stiže kao lokalni ulaz, zato firewall hosta treba vlastitu izjavu o tome odakle veza smije doći. Zato samo vezanje rijetko zadovoljava reviziju.

Uz podrazumijevanu politiku odbijanja dolaznog saobraćaja i bez šireg dopuštenja za ovu uslugu, ograničeno pravilo zajedno imenuje tunel, raspon izvora, odredište i port:

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

Pročitajte efektivni redoslijed firewalla prije primjene. Ranije široko prihvatanje može poništiti ograničenje, a ranije terminalno odbacivanje može spriječiti da se do ovog dopuštenja uopće dođe. Ne čistite nepovezana pravila i ne isključujte firewall da bi primjer odgovarao.

To pravilo je ulaz na host, ne ruta do druge LAN mašine, a vanjski OpenVPN listener gatewaya ostaje odvojena usluga. Ako je stranica prije bila javna, planirajte kako se stari ulaz povlači i kako se obrađuju postojeće sesije.

Održite HTTP listu netaknutom dok se lokacije mijenjaju

NGINX procjenjuje allow i deny unose po redu, a lista na nivou servera iznad propušta deklarisani pul prije konačnog deny. Modul pristupa takođe bilježi da lokacija koja definira bilo koji unos pristupa koristi vlastitu listu umjesto roditeljske. Redoslijed je jednako važan kao i sami unosi.

To resetiranje je uobičajena regresija. Nova lokacija za upload, API ili health koja doda jedan unos tiho zamjenjuje ograničenje na nivou servera, a stranica postaje šira na najskorije dodanom putu.

Pregledajte svaku lokaciju, alias i alternativni blok kao dio iste politike. Ako se IP provjere kombiniraju s NGINX autentifikacijom, razumite satisfy: postavka any može propustiti klijenta kroz jedan mehanizam dok drugi nije prošao. Stavite listu pristupa u kontrolnu listu pregleda lokacija.

HTTP odbijanje se događa nakon što TCP veza stigne do NGINX-a. Ono dopunjuje mrežno ograničenje, a vlastita autorizacija aplikacije i dalje važi za svakog korisnika.

Provjerite živi put i slučaj kvara

Pokrenite parser konfiguracije, pregledajte sockete koji slušaju, pa napravite svjež imenovani zahtjev sa predviđenog klijenta. Potvrdite da certifikat validira, da se DNS ime razrješava na vezanu adresu i da odgovor dolazi s očekivanog korijena.

Zatim testirajte isključeni izvor i alternativni ulaz. Zahtjev koji radi ništa ne govori o putevima koje ste namjeravali zatvoriti, a na isključenom testu se pojavljuje preostali listener ili široko prihvatanje firewalla.

Ponovite slučaj podizanja ili oporavka VPN-a. Ako NGINX startuje prije nego postoji adresa tunela, vezanje može pasti čak i s besprijekornom datotekom. Uskladite spremnost adrese i držite lokalni put oporavka prije promjene zajedničkog web servera.

Zapišite socket, port, raspon izvora i HTTP listu koji su prošli. Sljedeća VPN ili DNS promjena može pomjeriti bilo koji od njih, a četiri imenovane vrijednosti lakše je uporediti od radne kartice preglednika.

Povezani članci