NGINX-vefsvæði eingöngu fyrir VPN: hlustari, eldveggur og HTTP-heimilista

Þrjár sjálfstæðar ákvarðanir standa milli einkavefsvæðis og internetsins: hvaða socket tekur við tengingunni, hvaða slóð getur skilað henni og hvaða HTTP-biðlur valinn þjónn svarar. Þjónblokk tekur aðeins fyrstu ákvörðunina. Meðhöndlið hinar tvær sem aðskildar stýringar, annars virðist vefsvæðið einkarekið á meðan gömul innganga er enn opin. Flest NGINX-óhöpp sem eru eingöngu fyrir VPN koma frá því að prófa aðeins fyrsta lag.

Dæmið notar Linux OpenVPN hlið á 10.90.0.1 á tun0, biðlara í 10.90.0.0/24, varðveittar uppsprettur og TCP 8443 sem er frátekið fyrir þessa inngöngu. Stilltu gildin, haltu lögunum.

Byrjið á socketnum, ekki hýsilsnafninu

Tengið HTTPS-hlustarann við göngufangið og sérstaka port. Auðveldara er að hugsa um tiltekið fang en alheimssocket ásamt nafnaprófun, því kjarninn mun ekki afhenda portið öðru staðbundnu fangi.

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

Skírteinið verður að nefna þjónustuhýsilnafnið sem biðlarar slá inn, og einkadNS-sýnin verður að leysa þann hýsil í bundna fangið. server_name velur aðeins sýndarhýsil; það auðkennir engan. Vantað DNS-færsla framleiðir skírteinisvillu sem lítur út eins og TLS-bilun. Athugið nafnið áður en skírteininu er skipt.

Lestu virka stillinguna áður en skránni er bætt við. Innifellingar og alheimshlustarar geta þjónað sama rót annars staðar, og sjálfgefinn þjónn getur svarað beiðnum sem nýja blokkin sér aldrei.

Lokið öllum öðrum hlusturum fyrir það efni

Listið listen-skipanirnar og berið saman ræturnar sem þær þjóna. Blokk sem bætt var við fyrir annað forrit getur milliliðað á sama upstream, og gamall sjálfgefinn þjónn getur haldið áfram að svara eftir að nýi er kominn. Sú úttak er raunverulega birgðatalan, ekki skráin sem þú varst að breyta. Berið saman hverja rót sem þjónar sama efni.

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

Athugið báðar fangafjölskyldurnar. IPv4-binding skilur IPv6-socket eftir ósnortið, og ný A-færsla dregur ekki til baka gamalt AAAA-svar sem bendir enn á opinbera slóð.

Takið gamla sýndarhýsilinn út sem sérstaka breytingu. Að fjarlægja opinbera tvíbura nýju blokkarinnar er venjulega skrefið sem raunverulega lokar inngöngunni; einkahlustarinn bætir aðeins við þeirri fyrirhuguðu.

Afmarkið inntaksslóðina á hýsilnum

Hlustunarfangið takmarkar socketið, ekki inntaksviðmótið. Pakki sem er beint á það fang annars staðar frá kemur samt inn sem staðbundið inntak, þess vegna þarf eldveggur hýsilsins sína eigin yfirlýsingu um hvaðan tengingin má koma. Þess vegna fullnægir binding ein sjaldan úttekt.

Með sjálfgefinni synjunarstefnu fyrir inntak og án víðtækara leyfis fyrir þessa þjónustu nefnir afmörkuð regla göngin, uppsprettubilið, áfangastaðinn og portið saman:

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

Lestu virka röð eldveggsins áður en henni er beitt. Fyrra víðtækt samþykki getur gert takmörkunina að engu, og fyrri endanleg höfnun getur komið í veg fyrir að þetta leyfi náist. Hreinsið ekki ótengdar reglur og slökktu ekki á eldveggnum til að dæmið passi.

Sú regla er inntak á hýsil, ekki leið á aðra LAN-vél, og ytri OpenVPN-hlustari hliðsins er áfram sérstök þjónusta. Ef vefsvæðið var opið áður, skipuleggið hvernig gamla inngangan er tekin út og hvernig núverandi lotur eru meðhöndlaðar.

Haldið HTTP-listanum óskertum þegar staðsetningar breytast

NGINX metur allow- og deny-færslur í röð, og listinn á þjónstigi hér að ofan hleypir skilgreinda hópnum inn fyrir endanlegt deny. Aðgangseiningin skráir einnig að staðsetning sem skilgreinir hvaða aðgangsfærslu sem er noti fyrir eigin lista í stað foreldralistans. Röðin skiptir jafn miklu máli og færslurnar sjálfar.

Þessi endurstilling er venjulega afturförin. Ný upphleðslu-, API- eða heilsustaðsetning sem bætir við einni færslu kemur hljóðlaust í stað takmörkunarinnar á þjónstigi, og vefsvæðið verður víðtækara á nýjustu slóðinni.

Farið yfir hverja staðsetningu, alias og aðra blokk sem hluta af sömu stefnu. Ef IP-prófanir eru sameinaðar NGINX-auðkenningu, skiljið satisfy: any stilling getur hleypt biðlara inn um eina aðferð á meðan hin hefur ekki staðist. Setjið aðgangslistann á gátlistann fyrir staðsetningar.

HTTP-synjun á sér stað eftir að TCP-tengingin nær NGINX. Hún bætir við nettakmörkunina, og eigin heimild forritsins gildir áfram fyrir hvern notanda.

Sannprófið lifandi slóðina og bilanatilfellið

Keyrið stillingarþáttarann, skoðið hlustandi socketin og gerið síðan nýja nefnda beiðni frá fyrirhuguðum biðlara. Staðfestið að skírteinið sé gilt, DNS-nafnið leysist í bundna fangið og svarið komi frá væntri rót.

Prófið næst útilokaða uppsprettu og aðra inngöngu. Virk leyfð beiðni segir ekkert um slóðirnar sem þú ætlaðir að loka, og það er í útilokuðu prófuninni sem eftirfarandi hlustari eða víðtækt eldveggssamþykki kemur í ljós.

Endurtakið ræsingar- eða VPN-endurheimtutilfellið. Ef NGINX byrjar áður en gangafangið er til, getur bindingin mistekist jafnvel með fullkomna skrá. Samræmið framboð fangsins og haldið staðbundinni endurheimtarslóð áður en sameiginlegum vefþjóni er breytt.

Skráið socketið, portið, uppsprettubilið og HTTP-listann sem stóðust. Næsta VPN- eða DNS-breyting getur fært hvað sem er af þeim, og fjögur nefnd gildi er auðveldara að bera saman en vinnandi vafraflipi.