Alamat sumber mana yang akan dicatat NGINX untuk klien VPN?

Tiga alamat klien muncul dalam penyiapan NGINX dan OpenVPN pada host yang sama, satu untuk setiap jalur yang dapat diambil permintaan. Peramban yang mencapai alamat terowongan, peramban yang mencapai alamat publik, dan program yang keluar melalui jalur internet gateway semuanya terlihat berbeda di soket pendengar. Tentukan jalur mana yang sedang Anda lihat sebelum menafsirkan baris log. Keputusan bergantung pada tujuan yang dipakai klien, pengecualian yang dipegangnya untuk titik akhir VPN luar, dan apakah ada sesuatu yang menerjemahkan paket di sepanjang jalan.

Putuskan berdasarkan tujuan, bukan berdasarkan siapa penggunanya

Mulailah dari alamat ke mana permintaan dikirim, karena alamat itulah yang memilih jalur. Permintaan ke alamat terowongan host tiba di antarmuka terowongan dengan alamat dalam klien sebagai sumbernya. Permintaan ke alamat publik host biasanya tiba di antarmuka yang menghadap internet dengan alamat publik klien, bahkan ketika laptop yang sama memiliki terowongan yang terbentuk pada saat itu. Keanggotaan dalam kumpulan VPN karena itu merupakan sifat jalur paket, bukan sifat yang mengikuti pengguna.

Baris ketiga itulah yang layak diperiksa lebih dulu ketika pengguna VPN muncul di log dengan alamat yang tidak ada hubungannya dengan terowongan. Itu juga menjelaskan mengapa dua pengguna pada profil yang sama dapat menghasilkan entri berbeda: jaringan akses mereka sendiri berbeda, dan tidak ada apa pun di dalam terowongan yang menimpanya.

Mengapa titik akhir luar menciptakan jalur publik kedua

Klien harus mencapai alamat publik gateway untuk membentuk terowongan, jadi rute ke alamat itu harus ada di luar terowongan. Ketika klien mengalihkan seluruh lalu lintas ke dalam, implementasi yang masuk akal mempertahankan rute host eksplisit untuk alamat publik server agar terhindar dari terowongan yang bergantung pada dirinya sendiri. Pengecualian itu tidak memilah layanan, sehingga setiap permintaan ke alamat publik yang sama mengikutinya, termasuk permintaan peramban ke situs yang dihosting di gateway.

Inilah mekanisme di balik sebagian besar laporan yang membingungkan di bidang ini, dan itu tergantung pada implementasi klien bukan pada server. Dua klien dengan profil identik karena itu dapat berperilaku berbeda. Menghapus pengecualian untuk »memperbaiki« log ikut menjatuhkan terowongan, jadi pertahankan dan rancanglah di sekitarnya.

Baca soket, tabel, dan format log bersama-sama

Tiga pengamatan menyelesaikan jalur mana yang Anda lihat: di mana soket mendengarkan, antarmuka mana yang menjawab tujuan, dan apa yang sebenarnya dicatat format log. Jika pendengar hanya terikat ke alamat terowongan, permintaan publik tidak dapat mencapainya sama sekali, yang langsung menyingkirkan dua baris. Jika pencarian untuk klien mengembalikan perangkat terowongan, permintaan tiba dengan sumber dalam dan log seharusnya menunjukkannya.

ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44

Setelah itu baca formatnya, bukan barisnya. Bidang yang diisi oleh tajuk yang diteruskan mencatat klaim, bukan peer soket, dan klaim itu hanya penting ketika peer langsung merupakan proksi tepercaya. Menuliskan kedua nilai ke log menyelesaikan perdebatan kemudian, karena peer langsung dan alamat pengganti adalah fakta berbeda dan hanya satu di antaranya datang dari jaringan.

log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.conf

Pilih titik masuk yang Anda inginkan dan selaraskan DNS

Jika situs dimaksudkan hanya lewat terowongan, beri nama yang bagi klien VPN mengarah ke alamat terowongan dan tegakkan kebijakan pada soket pendengar. Jawaban DNS terpisah yang mengembalikan 10.24.0.1 untuk nama internal adalah keputusan perutean yang menyamar sebagai detail resolusi nama. Jika situs juga harus publik, pertahankan dua nama atau dua port dan biarkan log memberi tahu Anda mana yang melayani permintaan itu.

Aturan izinkan mengikuti logika yang sama. Mengizinkan kumpulan terowongan tidak memberi wewenang atas permintaan publik, dan tidak akan mengisi alamat dalam pada koneksi yang tiba melalui internet. Mencampur kedua titik masuk di bawah satu nama mengubah sumber yang tercatat menjadi efek samping perutean klien alih-alih pilihan desain.

Verifikasi jalurnya, lalu kebijakannya

Pastikan jalurnya dengan tangkapan di gateway dan permintaan yang Anda kendalikan. Tangkapan pada perangkat terowongan dan satu pada antarmuka publik menunjukkan mana yang membawa bita, dan urutan paket memberi tahu Anda apakah terjadi penerjemahan di antaranya.

tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5

Lalu verifikasi akses di kedua arah: titik masuk bernama yang dimaksud berfungsi untuk klien yang dimaksud, dan jalur publik yang tidak disetujui ditolak bukan sekadar lambat. Situs gema IP generik membuktikan sesuatu tentang jalan keluar internet gateway dan tidak membuktikan apa pun tentang situs ini pada host yang sama. Ketika halaman dan WebSocket tidak sepakat, bandingkan URL, keluarga alamat, dan jawaban DNS keduanya sebelum menyentuh konfigurasi server.