Tapak NGINX khusus VPN: pendengar, tembok api dan senarai kebenaran HTTP

Tiga keputusan bebas terletak antara tapak persendirian dan internet: soket mana menerima sambungan, laluan mana boleh menyampaikannya, dan klien HTTP mana yang dijawab oleh pelayan terpilih. Blok pelayan hanya membuat keputusan pertama. Anggap dua yang lain sebagai kawalan berasingan, jika tidak tapak akan kelihatan peribadi sementara pintu masuk lama kekal terbuka. Kebanyakan kegagalan NGINX khusus VPN berpunca daripada menguji lapisan pertama sahaja.

Contoh menggunakan get laluan Linux OpenVPN di 10.90.0.1 pada tun0, klien dalam 10.90.0.0/24, sumber dikekalkan dan TCP 8443 yang dikhaskan untuk pintu masuk ini. Laraskan nilainya, kekalkan lapisannya.

Mulakan dengan soket, bukan nama hos

Ikat pendengar HTTPS pada alamat terowong dan port khusus. Alamat tertentu lebih mudah difikirkan daripada soket kad bebas serta semakan nama, kerana kernel tidak akan menyerahkan port itu kepada alamat tempatan lain.

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

Sijil mesti menyebut nama hos perkhidmatan yang ditaip klien, dan paparan DNS persendirian mesti menyelesaikan hos itu kepada alamat terikat. server_name hanya memilih hos maya; ia tidak mengesahkan sesiapa. Entri DNS yang hilang menghasilkan ralat sijil yang kelihatan seperti kerosakan TLS. Periksa nama sebelum menggantikan sijil.

Baca konfigurasi berkesan sebelum menambah fail. Sertaan dan pendengar kad bebas boleh menyajikan akar yang sama di tempat lain, dan pelayan lalai boleh menjawab permintaan yang tidak pernah dilihat oleh blok baharu.

Tutup setiap pendengar lain untuk kandungan itu

Senaraikan arahan listen dan bandingkan akar yang disajikannya. Blok yang ditambah untuk aplikasi lain boleh memproksi ke upstream yang sama, dan pelayan lalai lama boleh terus menjawab selepas yang baharu dipasang. Output itu ialah inventori sebenar, bukan fail yang baru anda sunting. Bandingkan setiap akar yang menyajikan kandungan yang sama.

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

Periksa kedua-dua keluarga alamat. Pengikatan IPv4 membiarkan soket IPv6 tidak tersentuh, dan rekod A baharu tidak menarik balik jawapan AAAA lama yang masih menunjuk ke laluan awam.

Bersarakan hos maya lama sebagai perubahan berasingan. Membuang kembar awam blok baharu biasanya langkah yang benar-benar menutup pintu masuk; pendengar persendirian hanya menambah yang dimaksudkan.

Hadkan skop laluan masuk pada hos

Alamat dengar mengehadkan soket, bukan antara muka masuk. Paket yang dihalakan ke alamat itu dari tempat lain tetap tiba sebagai input tempatan, jadi tembok api hos memerlukan pernyataannya sendiri tentang dari mana sambungan boleh datang. Itulah sebabnya pengikatan sahaja jarang memenuhi audit.

Dengan dasar masuk tolak-lalai dan tanpa kebenaran lebih luas untuk perkhidmatan ini, peraturan berskop menamakan terowong, julat sumber, destinasi dan port sekali gus:

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

Baca susunan tembok api berkesan sebelum menerapkannya. Penerimaan luas terdahulu boleh mengalahkan sekatan, dan penolakan terminal terdahulu boleh menghalang kebenaran ini daripada dicapai. Jangan kosongkan peraturan tidak berkaitan atau matikan tembok api supaya contoh itu sepadan.

Peraturan itu ialah input hos, bukan laluan ke mesin LAN lain, dan pendengar OpenVPN luar get laluan kekal perkhidmatan berasingan. Jika tapak pernah awam, rancang cara pintu masuk lama dihentikan dan cara sesi sedia ada dikendalikan.

Kekalkan senarai HTTP utuh semasa lokasi berubah

NGINX menilai entri allow dan deny mengikut susunan, dan senarai peringkat pelayan di atas menerima kumpulan yang diisytiharkan sebelum deny terakhir. Modul akses juga merekodkan bahawa lokasi yang mentakrifkan mana-mana entri akses menggunakan senarainya sendiri dan bukan senarai induk. Susunan sama pentingnya dengan entri itu sendiri.

Set semula itu ialah regresi biasa. Lokasi muat naik, API atau kesihatan baharu yang menambah satu entri secara senyap menggantikan sekatan peringkat pelayan, dan tapak menjadi lebih luas pada laluan yang paling baru ditambah.

Semak setiap lokasi, alias dan blok alternatif sebagai sebahagian daripada dasar yang sama. Jika semakan IP digabungkan dengan pengesahan NGINX, fahami satisfy: tetapan any boleh meluluskan klien melalui satu mekanisme sementara yang lain belum lulus. Masukkan senarai akses dalam senarai semak semakan lokasi.

Penafian HTTP berlaku selepas sambungan TCP sampai ke NGINX. Ia melengkapi sekatan rangkaian, dan kebenaran aplikasi itu sendiri masih terpakai kepada setiap pengguna.

Sahkan laluan langsung dan kes kegagalan

Jalankan penghurai konfigurasi, periksa soket yang mendengar, kemudian buat permintaan bernama baharu daripada klien yang dimaksudkan. Sahkan sijil disahkan, nama DNS diselesaikan kepada alamat terikat dan respons datang dari akar yang dijangkakan.

Uji sumber yang dikecualikan dan pintu masuk alternatif seterusnya. Permintaan dibenarkan yang berfungsi tidak memberitahu apa-apa tentang laluan yang anda mahu tutup, dan pada ujian yang dikecualikan itulah pendengar tertinggal atau penerimaan tembok api yang luas muncul.

Ulangi kes but atau pemulihan VPN. Jika NGINX bermula sebelum alamat terowong wujud, pengikatan boleh gagal walaupun dengan fail sempurna. Selaraskan kesediaan alamat dan kekalkan laluan pemulihan tempatan sebelum menukar pelayan web dikongsi.

Rekod soket, port, julat sumber dan senarai HTTP yang lulus. Perubahan VPN atau DNS seterusnya boleh menggerakkan mana-mana daripadanya, dan empat nilai bernama lebih mudah dibandingkan daripada tab pelayar yang berfungsi.