Alamat sumber manakah yang akan direkodkan NGINX untuk klien VPN?

Tiga alamat klien muncul dalam persediaan NGINX dan OpenVPN pada hos yang sama, satu untuk setiap laluan yang boleh diambil oleh permintaan. Pelayar yang sampai ke alamat terowong, pelayar yang sampai ke alamat awam dan program yang keluar melalui laluan internet get lalu semuanya kelihatan berbeza pada soket pendengar. Tentukan laluan mana yang anda lihat sebelum mentafsir baris log. Keputusan bergantung pada destinasi yang digunakan oleh klien, pengecualian yang dipegangnya untuk titik akhir VPN luar, dan sama ada sesuatu menterjemah paket itu di sepanjang jalan.

Tentukan mengikut destinasi, bukan mengikut siapa pengguna

Mulakan dengan alamat yang dihantar kepada permintaan, kerana alamat itulah yang memilih laluan. Permintaan ke alamat terowong hos tiba pada antara muka terowong dengan alamat dalam klien sebagai sumber. Permintaan ke alamat awam hos biasanya tiba pada antara muka yang menghadap internet dengan alamat awam klien, walaupun komputer riba yang sama mempunyai terowong yang dibina pada saat itu. Keahlian dalam kumpulan VPN oleh itu ialah sifat laluan paket, bukan sifat yang mengikut pengguna.

Baris ketiga itulah yang wajar diperiksa dahulu apabila pengguna VPN muncul dalam log dengan alamat yang tiada kaitan dengan terowong. Ia juga menjelaskan mengapa dua pengguna pada profil yang sama boleh menghasilkan entri berbeza: rangkaian akses mereka sendiri berbeza, dan tiada apa pun di dalam terowong menimpa itu.

Mengapa titik akhir luar mencipta laluan awam kedua

Klien mesti sampai ke alamat awam get lalu untuk membina terowong, jadi laluan ke alamat itu mesti wujud di luar terowong. Apabila klien mengubah hala semua trafik ke dalam, pelaksanaan yang wajar mengekalkan laluan hos yang jelas untuk alamat awam pelayan bagi mengelakkan terowong yang bergantung pada dirinya sendiri. Pengecualian itu tidak memilih perkhidmatan, jadi setiap permintaan ke alamat awam yang sama mengikutinya, termasuk permintaan pelayar ke laman yang dihoskan pada get lalu.

Inilah mekanisme di sebalik kebanyakan laporan yang mengelirukan dalam bidang ini, dan ia bergantung pada pelaksanaan klien bukan pelayan. Dua klien dengan profil yang sama oleh itu boleh berkelakuan berbeza. Membuang pengecualian untuk »membaiki« log turut menjatuhkan terowong, jadi kekalkan dan reka bentuk di sekelilingnya.

Baca soket, jadual dan format log bersama-sama

Tiga pemerhatian menyelesaikan laluan mana yang anda lihat: di mana soket mendengar, antara muka mana yang menjawab destinasi, dan apa yang sebenarnya direkodkan oleh format log. Jika pendengar terikat hanya pada alamat terowong, permintaan awam tidak boleh sampai kepadanya sama sekali, yang menyingkirkan dua baris serta-merta. Jika carian untuk klien mengembalikan peranti terowong, permintaan itu tiba dengan sumber dalam dan log sepatutnya menunjukkannya.

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

Kemudian baca format itu dan bukan barisnya. Medan yang diberi makan oleh pengepala yang dimajukan merekodkan dakwaan, bukan rakan soket, dan dakwaan itu hanya penting apabila rakan segera ialah proksi yang dipercayai. Menulis kedua-dua nilai ke dalam log menyelesaikan perdebatan kemudian, kerana rakan segera dan alamat yang diganti ialah fakta berbeza dan hanya satu daripadanya datang dari rangkaian.

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

Pilih titik masuk yang anda mahu dan selaraskan DNS

Jika laman itu bertujuan hanya melalui terowong, berikan nama yang bagi klien VPN menyelesaikan ke alamat terowong dan kuatkuasakan dasar pada soket pendengar. Jawapan DNS berpecah yang mengembalikan 10.24.0.1 untuk nama dalaman ialah keputusan penghalaan yang menyamar sebagai butiran penyelesaian nama. Jika laman itu juga mesti awam, kekalkan dua nama atau dua port dan biarkan log memberitahu anda yang mana telah melayani permintaan itu.

Peraturan membenarkan mengikut logik yang sama. Membenarkan kumpulan terowong tidak memberi kuasa kepada permintaan awam, dan ia tidak akan mengisi alamat dalam pada sambungan yang tiba melalui internet. Mencampurkan kedua-dua titik masuk di bawah satu nama menjadikan sumber yang direkodkan sebagai kesan sampingan penghalaan klien dan bukan pilihan reka bentuk.

Sahkan laluan, kemudian dasarnya

Sahkan laluan itu dengan tangkapan pada get lalu dan permintaan yang anda kawal. Tangkapan pada peranti terowong dan satu pada antara muka awam menunjukkan yang mana membawa bait, dan susunan paket memberitahu anda sama ada terjemahan berlaku di antaranya.

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

Kemudian sahkan akses dalam kedua-dua arah: titik masuk bernama yang dimaksudkan berfungsi untuk klien yang dimaksudkan, dan laluan awam yang tidak diluluskan ditolak dan bukan sekadar lambat. Laman gema IP generik membuktikan sesuatu tentang jalan keluar internet get lalu dan tiada apa-apa tentang laman ini pada hos yang sama. Apabila halaman dan WebSocket tidak bersetuju, bandingkan URL, keluarga alamat dan jawapan DNS mereka sebelum menyentuh konfigurasi pelayan.