Apa yang diungkap balasan STUN saat VPN berjalan di router

Saat terowongan berada di router, mesin yang menjalankan peramban sama sekali tidak punya antarmuka terowongan. Tanyakan alamat lokal mesin itu dan Anda akan mendapat alamat LAN privat dan satu loopback, tidak ada yang menyerupai alamat VPN. Namun server STUN di sisi jauh tetap dapat melaporkan sesuatu yang berarti tentang jalur, dan apa yang dilaporkannya bergantung sepenuhnya pada bagaimana permintaan khusus itu dirutekan dan diterjemahkan.

Itulah bagian yang layak diperlambat. „Peramban tidak memiliki alamat VPN“ menjawab pertanyaan tentang antarmuka, sedangkan alamat terpantul adalah jawaban tentang jalur melalui penerjemahan. Mencampur keduanya menghasilkan kesimpulan percaya diri tentang pengungkapan yang tidak didukung bukti.

Dua perangkat, dua set antarmuka

Dalam penyiapan berbasis router, terowongan berakhir di router dan klien LAN mengirim lalu lintas biasa ke gerbang bawaannya. Daftar antarmuka klien tetap pendek: satu alamat privat, mungkin satu lagi untuk jaringan lain, dan loopback. Risikonya bukan bahwa salah satunya kebetulan alamat terowongan; risikonya adalah permintaan keluar melalui jalur yang tidak Anda pilih.

Tanyakan kepada klien jalur mana yang akan diambil tujuan tertentu alih-alih menanyakan antarmuka mana yang ada. Jawabannya menyebut gerbang dan alamat sumber yang akan dipakai kernel, dan itu sudah lebih informatif daripada inventaris alamat mana pun.

ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ips

Rentang dokumentasi adalah tujuan uji yang baik karena tidak pernah diselesaikan menjadi layanan nyata. Bandingkan apa yang dikatakan klien dengan apa yang dikatakan router, dan perlakukan ketidakcocokan apa pun sebagai bukti bahwa perutean kebijakan, aturan terowongan terpisah, atau rute bawaan kedua melakukan sesuatu yang tidak Anda perhitungkan.

Apa yang boleh dikatakan balasan Binding

RFC 8489 mendefinisikan permintaan dan balasan Binding, tempat server melaporkan alamat transportasi sumber yang diamatinya untuk permintaan itu. Ini pernyataan tentang satu kuintup pada satu saat, bukan sensus antarmuka klien. Karena itu semua yang menarik terjadi antara klien dan titik pengamatan.

Celah itu diisi oleh perutean dan penerjemahan. Router yang melakukan NAT sumber pada lalu lintas keluar menggantikan sumber privat klien dengan alamatnya sendiri pada antarmuka keluar. Jika antarmuka itu adalah terowongan, pemantul melihat alamat terowongan. Jika paket dikecualikan dari terowongan, pemantul melihat apa yang dihasilkan penerjemahan WAN. Klien sama, pemantul sama, jawaban berbeda.

Tiga kasus yang tampak serupa dan tidak

Pembeda yang berguna bukan publik versus privat, melainkan titik penegakan mana yang menangani paket. Kerjakan kasus-kasusnya dengan tabel router sendiri terbuka, karena satu peramban dapat menghasilkan ketiganya tergantung aturan yang Anda lupa pernah menulisnya.

Hanya kasus kedua yang melanggar syarat bahwa lalu lintas tertentu tidak pernah keluar langsung, dan hanya kasus pertama dan ketiga yang mengungkap pengenal dari sisi terowongan. Tak satu pun dari ketiga baris itu merupakan klaim tentang perilaku penyedia tertentu: apakah pemantul privat dapat dijangkau sama sekali bergantung pada perutean, alamat IP yang diizinkan pihak lain, dan kebijakan tembok api di kedua ujung.

Memiliki akun pada penyedia yang sama tidak membuktikan satu pun dari itu. Perlu juga diingat bahwa permintaan yang dirutekan dapat mempertahankan sumber LAN klien jika tidak ada yang menerjemahkannya, jadi bidang sumber harus dilacak dan bukan diasumsikan dari diagram topologi.

Mengumpulkan bukan memilih

WebRTC mengumpulkan alamat kandidat untuk dicoba, dan kandidat yang muncul dalam daftar diagnostik mungkin tidak pernah membawa media. Membaca daftar itu sebagai „inilah yang dipelajari pihak lain“ membesar-besarkan bukti. Pasangan terpilih adalah yang benar-benar membawa sesi, dan ia berada di bidang lain.

Pemeriksa keluar HTTPS menjawab pertanyaan lain lagi: alamat sumber yang dilihat server web untuk permintaan itu. Ini pemeriksaan silang yang berguna justru karena memakai protokol berbeda dan sering tujuan berbeda daripada pemantul UDP, dan ketidakcocokan antara keduanya biasanya menunjuk pada aturan perutean, bukan bug.

Tetapkan kebijakan, lalu baca jawabannya

Tuliskan niat sebelum menguji: lalu lintas mana yang harus memakai terowongan, mana yang boleh keluar langsung, keluarga alamat mana yang termasuk cakupan, dan apa yang harus terjadi saat terowongan mati. Tanpa garis dasar itu setiap pengamatan ambigu, karena Anda tidak dapat memisahkan kebocoran dari jalur yang sengaja Anda izinkan.

Lalu ajukan satu pertanyaan pada satu waktu. Jalur mana yang diambil tujuan ini. Alamat mana yang dilaporkan pemantul ini. Pasangan kandidat mana yang dipilih sesi. Simpan jawabannya di samping kebijakan dan beri tanggal, karena pembaruan firmware dapat mengubah perilaku bawaan dengan cara yang diam-diam membatalkan kesimpulan tahun lalu.

Router tetap merupakan titik penegakan yang kuat, karena ia melihat lalu lintas yang tidak dapat dilewati klien tanpa mengonfigurasi ulang klien itu sendiri. Itu bukan janji bahwa setiap bidang dalam setiap protokol aplikasi tidak mengungkap apa pun, dan bukan pengganti menuliskan jalur yang Anda pilih untuk izinkan.