Situs NGINX khusus VPN: listener, firewall, dan daftar izin HTTP

Situs NGINX privat memerlukan socket VPN terikat, aturan masuk host yang terbatas, dan daftar akses HTTP yang utuh. Uji ketiganya, bukan satu blok server.

Tiga keputusan independen berdiri antara situs privat dan internet: socket mana yang menerima koneksi, jalur mana yang dapat mengantarkannya, dan klien HTTP mana yang dijawab server terpilih. Blok server hanya mengambil keputusan pertama. Perlakukan dua lainnya sebagai kontrol terpisah, atau situs akan tampak privat sementara pintu masuk lama tetap terbuka. Sebagian besar kegagalan NGINX khusus VPN berasal dari menguji lapisan pertama saja.

Contoh menggunakan gateway Linux OpenVPN di 10.90.0.1 pada tun0, klien di 10.90.0.0/24, sumber yang dipertahankan, dan TCP 8443 yang dicadangkan untuk pintu masuk ini. Sesuaikan nilainya, pertahankan lapisannya.

Mulai dari socket, bukan nama host

Ikat listener HTTPS ke alamat tunnel dan port khusus. Alamat spesifik lebih mudah dipikirkan daripada socket wildcard plus pemeriksaan nama, karena kernel tidak akan menyerahkan port ke alamat lokal 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;
    }
}

Sertifikat harus memuat nama host layanan yang diketik klien, dan tampilan DNS privat harus menyelesaikan host itu ke alamat terikat. server_name hanya memilih host virtual; ia tidak mengautentikasi siapa pun. Entri DNS yang hilang menghasilkan kesalahan sertifikat yang tampak seperti gangguan TLS. Periksa namanya sebelum mengganti sertifikat.

Baca konfigurasi efektif sebelum menambahkan file. Include dan listener wildcard dapat melayani root yang sama di tempat lain, dan server default dapat menjawab permintaan yang tidak pernah dilihat blok baru.

Tutup setiap listener lain untuk konten itu

Daftar direktif listen dan bandingkan root yang dilayaninya. Blok yang ditambahkan untuk aplikasi lain dapat memproksi ke upstream yang sama, dan server default lama dapat terus menjawab setelah yang baru terpasang. Keluaran itu adalah inventaris sebenarnya, bukan file yang baru Anda sunting. Bandingkan setiap root yang melayani konten yang sama.

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

Periksa kedua keluarga alamat. Pengikatan IPv4 membiarkan socket IPv6 tak tersentuh, dan record A baru tidak menarik kembali jawaban AAAA lama yang masih menunjuk ke jalur publik.

Pensiunkan host virtual lama sebagai perubahan terpisah. Menghapus kembaran publik blok baru biasanya adalah langkah yang benar-benar menutup pintu masuk; listener privat hanya menambahkan yang dimaksud.

Batasi jalur masuk di host

Alamat listen membatasi socket, bukan antarmuka ingress. Paket yang dirutekan ke alamat itu dari tempat lain tetap tiba sebagai masukan lokal, karena itu firewall host memerlukan pernyataannya sendiri tentang dari mana koneksi boleh datang. Itulah sebabnya pengikatan saja jarang memenuhi audit.

Dengan kebijakan masuk tolak-secara-default dan tanpa izin lebih luas untuk layanan ini, aturan terbatas menyebut tunnel, rentang sumber, tujuan, dan port sekaligus:

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

Baca urutan firewall efektif sebelum menerapkannya. Penerimaan luas sebelumnya dapat mengalahkan pembatasan, dan penolakan terminal sebelumnya dapat menghalangi izin ini tercapai. Jangan bersihkan aturan tak terkait atau mematikan firewall agar contohnya cocok.

Aturan itu adalah masukan host, bukan rute ke mesin LAN lain, dan listener OpenVPN luar gateway tetap layanan terpisah. Jika situs sebelumnya publik, rencanakan bagaimana pintu masuk lama dipensiunkan dan bagaimana sesi yang ada ditangani.

Jaga daftar HTTP tetap utuh saat lokasi berubah

NGINX mengevaluasi entri allow dan deny secara berurutan, dan daftar tingkat server di atas mengizinkan kumpulan yang dideklarasikan sebelum deny terakhir. Modul akses juga mencatat bahwa lokasi yang mendefinisikan entri akses apa pun memakai daftarnya sendiri alih-alih daftar induk. Urutan sama pentingnya dengan entrinya.

Reset itu adalah regresi yang biasa. Lokasi unggah, API, atau kesehatan baru yang menambahkan satu entri diam-diam menggantikan pembatasan tingkat server, dan situs menjadi lebih luas pada jalur yang paling baru ditambahkan.

Tinjau setiap lokasi, alias, dan blok alternatif sebagai bagian dari kebijakan yang sama. Jika pemeriksaan IP digabung dengan autentikasi NGINX, pahami satisfy: pengaturan any dapat meloloskan klien melalui satu mekanisme sementara yang lain belum lulus. Masukkan daftar akses ke daftar periksa lokasi.

Penolakan HTTP terjadi setelah koneksi TCP mencapai NGINX. Ia melengkapi pembatasan jaringan, dan otorisasi aplikasi itu sendiri tetap berlaku bagi setiap pengguna.

Verifikasi jalur aktif dan kasus kegagalan

Jalankan pengurai konfigurasi, periksa socket yang mendengarkan, lalu buat permintaan bernama baru dari klien yang dimaksud. Pastikan sertifikat tervalidasi, nama DNS terselesaikan ke alamat terikat, dan respons berasal dari root yang diharapkan.

Uji sumber yang dikecualikan dan pintu masuk alternatif berikutnya. Permintaan diizinkan yang berfungsi tidak mengatakan apa pun tentang jalur yang ingin Anda tutup, dan pada uji yang dikecualikan itulah listener sisa atau penerimaan firewall yang luas muncul.

Ulangi kasus boot atau pemulihan VPN. Jika NGINX mulai sebelum alamat tunnel ada, pengikatan dapat gagal bahkan dengan file yang sempurna. Koordinasikan kesiapan alamat dan pertahankan jalur pemulihan lokal sebelum mengubah server web bersama.

Catat socket, port, rentang sumber, dan daftar HTTP yang lolos. Perubahan VPN atau DNS berikutnya dapat menggeser salah satunya, dan empat nilai bernama lebih mudah dibandingkan daripada tab peramban yang berfungsi.

Artikel terkait