Apa yang didedahkan oleh balasan STUN apabila VPN berjalan pada penghala
Alamat terowong penghala bukan alamat setempat pelayar. Jejaki bagaimana setiap permintaan dihalakan dan diterjemah sebelum membaca apa yang dilaporkan pemantul.
Apabila terowong berada pada penghala, mesin yang menjalankan pelayar tidak mempunyai sebarang antara muka terowong. Tanya mesin itu tentang alamat setempatnya dan anda mendapat alamat LAN persendirian dan gelung balik, tiada apa yang menyerupai alamat VPN. Namun pelayan STUN di sebelah sana masih boleh melaporkan sesuatu yang bermakna tentang laluan, dan apa yang dilaporkannya bergantung sepenuhnya pada bagaimana permintaan tertentu itu dihalakan dan diterjemah.
Itulah bahagian yang wajar diperlahankan. „Pelayar tidak memiliki alamat VPN“ menjawab soalan tentang antara muka, manakala alamat terpantul ialah jawapan tentang laluan melalui terjemahan. Mengelirukan kedua-duanya menghasilkan kesimpulan yakin tentang pendedahan yang tidak disokong bukti.
Dua peranti, dua set antara muka
Dalam susunan berasaskan penghala, terowong tamat pada penghala dan klien LAN menghantar trafik biasa ke get laluan lalainya. Senarai antara muka klien kekal pendek: satu alamat persendirian, mungkin satu lagi untuk rangkaian lain, dan gelung balik. Risikonya bukanlah salah satunya kebetulan alamat terowong; risikonya ialah permintaan keluar melalui laluan yang anda tidak pilih.
Tanya klien laluan mana yang akan diambil oleh destinasi tertentu daripada bertanya antara muka mana yang wujud. Jawapannya menamakan get laluan dan alamat sumber yang akan digunakan oleh kernel, dan itu sudah lebih bermaklumat daripada mana-mana inventori alamat.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsJulat dokumentasi ialah destinasi ujian yang baik kerana ia tidak pernah diselesaikan kepada perkhidmatan sebenar. Bandingkan apa yang dikatakan klien dengan apa yang dikatakan penghala, dan anggap sebarang percanggahan sebagai bukti bahawa penghalaan dasar, peraturan terowong berpecah atau laluan lalai kedua melakukan sesuatu yang anda tidak perhitungkan.
Apa yang boleh dikatakan balasan Binding
RFC 8489 mentakrifkan permintaan dan balasan Binding, di mana pelayan melaporkan alamat pengangkutan sumber yang diperhatikannya untuk permintaan itu. Ia pernyataan tentang satu kuintup pada satu saat, bukan banci antara muka klien. Oleh itu segala yang menarik berlaku antara klien dan titik pemerhatian.
Jurang itu diisi oleh penghalaan dan terjemahan. Penghala yang melakukan NAT sumber pada trafik keluar menggantikan sumber persendirian klien dengan alamatnya sendiri pada antara muka keluar. Jika antara muka itu ialah terowong, pemantul melihat alamat terowong. Jika paket dikecualikan daripada terowong, pemantul melihat apa yang dihasilkan oleh terjemahan WAN. Klien sama, pemantul sama, jawapan berbeza.
Tiga kes yang kelihatan serupa dan tidak
Perbezaan berguna bukan awam berbanding persendirian, tetapi titik penguatkuasaan mana yang mengendalikan paket. Kerjakan kes itu dengan jadual penghala sendiri terbuka, kerana satu pelayar boleh menghasilkan ketiga-tiganya bergantung pada peraturan yang anda lupa anda tulis.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
Hanya kes kedua melanggar syarat bahawa trafik tertentu tidak pernah keluar terus, dan hanya kes pertama dan ketiga mendedahkan pengecam dari sisi terowong. Tiada satu pun daripada tiga baris itu dakwaan tentang tingkah laku pembekal tertentu: sama ada pemantul persendirian boleh dicapai langsung bergantung pada penghalaan, alamat IP yang dibenarkan pihak lain dan dasar tembok api di kedua-dua hujung.
Mempunyai akaun dengan pembekal yang sama tidak membuktikan apa-apa daripada itu. Perlu juga diingat bahawa permintaan yang dihalakan boleh mengekalkan sumber LAN klien jika tiada apa yang menterjemahkannya, jadi medan sumber mesti dijejaki dan bukan diandaikan daripada rajah topologi.
Mengumpul bukan memilih
WebRTC mengumpul alamat calon untuk dicuba, dan calon yang muncul dalam senarai diagnostik mungkin tidak pernah membawa media. Membaca senarai itu sebagai „inilah yang dipelajari pihak lain“ melebih-lebihkan bukti. Pasangan yang dipilih ialah yang benar-benar membawa sesi, dan ia berada dalam medan lain.
Pemeriksa keluar HTTPS menjawab soalan lain lagi: alamat sumber yang dilihat oleh pelayan web untuk permintaan itu. Ia pemeriksaan silang yang berguna justeru kerana menggunakan protokol berbeza dan sering destinasi berbeza daripada pemantul UDP, dan percanggahan antara keduanya biasanya menunjuk kepada peraturan penghalaan dan bukan pepijat.
Tentukan dasar, kemudian baca jawapannya
Tuliskan hasrat sebelum menguji: trafik mana yang mesti menggunakan terowong, mana yang boleh keluar terus, keluarga alamat mana yang dalam skop, dan apa yang patut berlaku apabila terowong mati. Tanpa garis dasar itu setiap pemerhatian adalah kabur, kerana anda tidak dapat memisahkan kebocoran daripada laluan yang anda sengaja benarkan.
Kemudian tanya satu soalan pada satu masa. Laluan mana yang diambil destinasi ini. Alamat mana yang dilaporkan pemantul ini. Pasangan calon mana yang dipilih sesi. Simpan jawapan di sebelah dasar dan tarikhkannya, kerana kemas kini firmware boleh mengubah tingkah laku lalai dengan cara yang membatalkan kesimpulan tahun lalu secara senyap.
Penghala masih merupakan titik penguatkuasaan yang kukuh, kerana ia melihat trafik yang tidak dapat dielakkan oleh klien tanpa mengkonfigurasi semula klien itu sendiri. Ia bukan janji bahawa setiap medan dalam setiap protokol aplikasi tidak mendedahkan apa-apa, dan ia bukan pengganti untuk menulis laluan yang anda pilih untuk benarkan.