NGINX-side allinnich foar VPN: listener, fjoerwacht en HTTP-tastimminglist

Trije ûnôfhinklike beslissingen steane tusken in partikuliere side en it ynternet: hokker socket de ferbining akseptearret, hokker paad it leverje kin en hokker HTTP-klanten de keazen server antwurdet. In serverblok nimt allinnich de earste beslissing. Behannelje de oare twa as aparte kontrôles, oars liket de side partikulier wylst in âlde yngong iepen bliuwt. De measte NGINX-flaters allinnich foar VPN komme fan it testen fan allinnich de earste laach.

It foarbyld brûkt in Linux-OpenVPN-gateway op 10.90.0.1 op tun0, klanten yn 10.90.0.0/24, bewarre boarnen en TCP 8443 reservearre foar dizze yngong. Pas de wearden oan, hâld de lagen.

Begjin mei de socket, net de hostnamme

Byn de HTTPS-listener oan it tunneladres en in aparte poarte. In spesifyk adres is makliker te beredenearjen as in wildcard-socket plus in nammerkontrôle, om't de kernel de poarte net oan in oar lokaal adres jout.

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

It sertifikaat moat de tsjinsthostnamme neame dy't klanten yntype, en de partikuliere DNS-byld moat dy host nei it bûne adres oplosse. server_name kiest allinnich in firtuele host; it autentisearret nimmen. In ûntbrekkende DNS-ynfier produsearret in sertifikaatflater dy't op in TLS-flater liket. Kontrolearje de namme foardat it sertifikaat ferfongen wurdt.

Lês de effektive konfiguraasje foardat it bestân tafoege wurdt. Ynklusjes en wildcard-listeners kinne deselde woartel earne oars betsjinje, en in standertserver kin antwurdzje op oanfregens dy't it nije blok nea sjocht.

Slút elke oare listener foar dy ynhâld

List de listen-ynstruksjes op en ferlykje de woartels dy't se betsjinje. In blok tafoege foar in oare applikaasje kin nei deselde upstream proxyje, en in âlde standertserver kin trochgean mei antwurdzjen nei't de nije stiet. Dy útfier is de echte ynventaris, net it bestân dat jo krekt bewurke hawwe. Ferlykje elke woartel dy't deselde ynhâld betsjinnet.

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

Kontrolearje beide adresfamyljes. In IPv4-bining lit in IPv6-socket ûnoantaaste, en in nij A-record lûkt gjin âld AAAA-antwurd werom dat noch nei in iepenbier paad wiist.

Weromlûk de âlde firtuele host as in aparte feroaring. It fuortheljen fan 'e iepenbiere twilling fan it nije blok is meast de stap dy't de yngong echt slút; de partikuliere listener foeget allinnich de bedoelde ta.

Behein it ynkommende paad op 'e host

It harkadres beheint de socket, net de ynfierinterface. In pakket dat fan earne oars nei dat adres rûte is, komt noch altyd as lokale ynfier oan, dêrom hat de fjoerwacht fan 'e host syn eigen ferklearring nedich oer wêr't de ferbining wei komme mei. Dêrom foldocht in bining allinnich selden oan in audit.

Mei in standert-wergerjende ynfierpolicy en sûnder bredere tastimming foar dizze tsjinst neamt in beheinde regel de tunnel, it boarneberik, de bestimming en de poarte tegearre:

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

Lês de effektive oarder fan 'e fjoerwacht foardat dy tapast wurdt. In eardere brede akseptaasje kin de beheining ferslaan, en in eardere terminale drop kin foarkomme dat dizze tastimming ea berikt wurdt. Spielje gjin ûnbesibbe regels en skeakelje de fjoerwacht net út om it foarbyld te passen.

Dy regel is host-ynfier, gjin rûte nei in oare LAN-masine, en de bûtenste OpenVPN-listener fan 'e gateway bliuwt in aparte tsjinst. As de side earder iepenbier wie, plan dan hoe't de âlde yngong weromlutsen wurdt en hoe't besteande sesjes behannele wurde.

Hâld de HTTP-list yntakt wylst lokaasjes feroarje

NGINX evaluearret allow- en deny-ynfier yn folchoarder, en de list op servernivo hjirboppe lit de ferklearre pool ta foar de definitive deny. De tagongsmodule registrearret ek dat in lokaasje dy't in tagongsynfier definiearret syn eigen list brûkt ynstee fan 'e âlderlist. Folchoarder is like wichtich as de ynfier sels.

Dy reset is de gewoane regresje. In nij upload-, API- of sûnenslokaasje dat ien ynfier tafoeget, ferfangt stil de beheining op servernivo, en de side wurdt breder op it meast resint tafoege paad.

Besjoch elk lokaasje, alias en alternatyf blok as ûnderdiel fan itselde belied. As IP-kontrôles mei NGINX-autentikaasje kombinearre wurde, begryp satisfy: in any-ynstelling kin in klant troch ien meganisme talitte wylst de oare net slagge is. Set de tagongslist yn 'e kontrôlelist foar lokaasjes.

In HTTP-ôfwizing bart neidat de TCP-ferbining NGINX berikt. It oanfollet de netwurkbeheining, en de eigen autorisaasje fan 'e applikaasje jildt noch foar elke brûker.

Ferifiearje it libbene paad en it flatergefal

Rin de konfiguraasjeanalyzer, ynspektearje de harkende sockets, en meitsje dan in nij neamd fersyk fan in bedoelde klant. Befêstigje dat it sertifikaat falidearret, de DNS-namme nei it bûne adres oplost en it antwurd fan 'e ferwachte woartel komt.

Test dêrnei in útsletten boarne en in alternative yngong. In wurkjend tastien fersyk seit neat oer de paden dy't jo slute woenen, en it is by de útsletten test dat in oerbleaune listener of in brede fjoerwachtakseptaasje opkomt.

Werhelje it opstart- of VPN-herstelgefal. As NGINX start foardat it tunneladres bestiet, kin de bining mislearje sels mei in perfekt bestân. Koördinearje adresgeredens en hâld in lokale herstelpaad foardat in dielde webserver feroare wurdt.

Registrearje de socket, poarte, boarneberik en HTTP-list dy't slagge binne. De folgjende VPN- of DNS-feroaring kin ien fan har ferpleatse, en fjouwer neamde wearden binne makliker te ferlykjen as in wurkjend browser-tabblêd.