Vain VPN:lle tarkoitettu NGINX-sivusto: kuuntelija, palomuuri ja HTTP-sallintaluettelo

Kolme riippumatonta päätöstä on yksityisen sivuston ja internetin välissä: mikä soketti ottaa yhteyden vastaan, mikä polku voi toimittaa sen ja mille HTTP-asiakkaille valittu palvelin vastaa. Palvelinlohko tekee vain ensimmäisen päätöksen. Käsittele kahta muuta erillisinä kontrolleina, muuten sivusto näyttää yksityiseltä, kun vanha sisäänkäynti jää auki. Useimmat vain VPN:lle tarkoitetut NGINX-viat johtuvat vain ensimmäisen kerroksen testaamisesta.

Esimerkki käyttää Linuxin OpenVPN-yhdyskäytävää osoitteessa 10.90.0.1 rajapinnalla tun0, asiakkaita verkossa 10.90.0.0/24, säilytettyjä lähteitä ja tälle sisäänkäynnille varattua TCP 8443 -porttia. Mukauta arvoja, pidä kerrokset.

Aloita sokatista, älä isäntänimestä

Sido HTTPS-kuuntelija tunnelin osoitteeseen ja erilliseen porttiin. Tietty osoite on helpompi hahmottaa kuin jokerimerkkisoketti ja nimintarkistus, koska ydin ei anna porttia toiselle paikalliselle osoitteelle.

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

Varmenteen on nimettävä palvelun isäntänimi, jonka asiakkaat kirjoittavat, ja yksityisen DNS-näkymän on ratkaistava tämä isäntä sidottuun osoitteeseen. server_name valitsee vain virtuaalisen isännän; se ei todenna ketään. Puuttuva DNS-merkintä tuottaa varmentovirheen, joka näyttää TLS-vialta. Tarkista nimi ennen varmenteen vaihtamista.

Lue voimassa oleva kokoonpano ennen tiedoston lisäämistä. Sisällytykset ja jokerimerkkikuuntelijat voivat palvella samaa juurta muualla, ja oletuspalvelin voi vastata pyyntöihin, joita uusi lohko ei koskaan näe.

Sulje kaikki muut kyseisen sisällön kuuntelijat

Listaa listen-direktiivit ja vertaa juuria, joita ne palvelevat. Toiselle sovellukselle lisätty lohko voi välittää samaan upstreamiin, ja vanha oletuspalvelin voi jatkaa vastaamista, kun uusi on paikallaan. Tämä tuloste on todellinen luettelo, ei tiedosto, jota juuri muokkasit. Vertaa jokaista juurta, joka palvelee samaa sisältöä.

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

Tarkista molemmat osoiteperheet. IPv4-sidonta jättää IPv6-soketin koskemattomaksi, eikä uusi A-merkintä poista vanhaa AAAA-vastausta, joka osoittaa yhä julkiselle polulle.

Poista vanha virtuaali-isäntä erillisenä muutoksena. Uuden lohkon julkisen kaksosen poistaminen on yleensä se vaihe, joka todella sulkee sisäänkäynnin; yksityinen kuuntelija vain lisää aiotun.

Rajaa saapuva polku isännässä

Kuunteluosoite rajaa sokettia, ei saapumisrajapintaa. Muualta tähän osoitteeseen reititetty paketti saapuu silti paikallisena syötteenä, siksi isännän palomuurilla on oltava oma lausuntonsa siitä, mistä yhteys saa tulla. Siksi pelkkä sidonta harvoin tyydyttää auditin.

Kun saapuvan liikenteen oletuskäytäntö on kieltävä eikä tälle palvelulle ole laajempaa lupaa, rajattu sääntö nimeää tunnelin, lähdealueen, kohteen ja portin yhdessä:

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

Lue palomuurin voimassa oleva järjestys ennen sen soveltamista. Aiempi laaja hyväksyntä voi kumota rajoituksen, ja aiempi lopullinen hylkäys voi estää tämän luvan saavuttamisen kokonaan. Älä tyhjennä asiaankuulumattomia sääntöjä äläkä kytke palomuuria pois, jotta esimerkki sopisi.

Tämä sääntö on isännän saapumisliikennettä, ei reitti toiseen LAN-koneeseen, ja yhdyskäytävän ulompi OpenVPN-kuuntelija on edelleen erillinen palvelu. Jos sivusto oli aiemmin julkinen, suunnittele, miten vanha sisäänkäynti poistetaan ja miten olemassa olevat istunnot käsitellään.

Pidä HTTP-luettelo ehjänä, kun sijainnit muuttuvat

NGINX arvioi allow- ja deny-merkinnät järjestyksessä, ja yllä oleva palvelintason luettelo sallii ilmoitetun joukon ennen lopullista deny-merkintää. Käyttömoduuli kirjaa myös, että sijainti, joka määrittää minkä tahansa käyttömerkinnän, käyttää omaa luetteloaan ylätason luettelon sijaan. Järjestys on yhtä tärkeä kuin merkinnät itse.

Tuo nollaus on tavallinen regressio. Uusi lataus-, API- tai terveyssijainti, joka lisää yhden merkinnän, korvaa hiljaa palvelintason rajoituksen, ja sivustosta tulee laajempi viimeksi lisätyllä polulla.

Käy läpi jokainen sijainti, alias ja vaihtoehtoinen lohko osana samaa käytäntöä. Jos IP-tarkistukset yhdistetään NGINX-todennukseen, ymmärrä satisfy: any-asetus voi päästää asiakkaan yhdellä mekanismilla, kun toinen ei ole mennyt läpi. Laita käyttöluettelo sijaintien tarkistuslistaan.

HTTP-hylkäys tapahtuu sen jälkeen, kun TCP-yhteys saavuttaa NGINXin. Se täydentää verkkorajoitusta, ja sovelluksen oma valtuutus koskee edelleen jokaista käyttäjää.

Varmista toimiva polku ja virhetilanne

Aja kokoonpanon jäsentäjä, tarkasta kuuntelevat sokatet ja tee sitten tuore nimetty pyyntö aiottuun asiakkaaseen. Vahvista, että varmenne validoituu, DNS-nimi ratkeaa sidottuun osoitteeseen ja vastaus tulee odotetusta juuresta.

Testaa seuraavaksi ulkopuolelle jätetty lähde ja vaihtoehtoinen sisäänkäynti. Toimiva sallittu pyyntö ei kerro mitään poluista, jotka aioit sulkea, ja juuri pois jätetyssä testissä jäljelle jäänyt kuuntelija tai laaja palomuurin hyväksyntä paljastuu.

Toista käynnistys- tai VPN-palautustilanne. Jos NGINX käynnistyy ennen kuin tunneliosoite on olemassa, sidonta voi epäonnistua täydellisestä tiedostosta huolimatta. Koordinoi osoitteen valmius ja pidä paikallinen palautuspolku ennen jaetun verkkopalvelimen muuttamista.

Kirjaa soketti, portti, lähdealue ja HTTP-luettelo, jotka menivät läpi. Seuraava VPN- tai DNS-muutos voi siirtää mitä tahansa niistä, ja neljää nimettyä arvoa on helpompi verrata kuin toimivaa selaimen välilehteä.