Mengapakah DNS router sendiri memintas terowong VPN?

Carian klien mengikut terowong manakala carian router sendiri keluar melalui WAN, dan peraturan tembok api yang mengawal satu tidak memberi kesan pada yang lain. Puncanya bukan pepijat: permintaan yang dimajukan dan permintaan yang dijana oleh router sendiri ialah dua aliran berasingan, dan setiap satu dipadankan dengan bahagian konfigurasi yang berbeza. Menangkap separuh klien sahaja menghasilkan jawapan yakin tentang laluan yang tidak pernah digunakan oleh separuh kedua. Pembaikannya ialah mengarahkan penyelesai router secara sengaja, kemudian menguji kedua-dua laluan secara berasingan.

Aliran manakah yang sebenarnya dimiliki oleh tangkapan paket

Satu carian melibatkan dua pertukaran. Klien LAN menghantar pertanyaan kepada penyelesai router, dan ia tiba sebagai trafik dimajukan pada antara muka LAN, jadi laluan dasar atau peraturan NAT yang ditulis untuk paket dimajukan boleh memadankannya. Router kemudian menjawab dari cache atau, jika tiada, membuka pertanyaannya sendiri kepada pelayan huluan.

Pertanyaan kedua itu bersumberkan router sendiri dan tujuannya juga dirinya sendiri, dan platform memilih laluannya daripada blok konfigurasi yang berbeza. Kedua-dua pertukaran membawa nama yang sama, dan tidak satu pun merupakan salinan yang lain. Oleh itu tangkapan yang diambil di sebelah LAN membuktikan ke mana paket klien pergi dan tidak menyatakan apa-apa tentang paket keluar.

Semakan praktikal ialah memerhati kedua-dua belah serentak. Pada router, senaraikan soket penyelesai, tanyakan secara setempat dan tangkap antara muka WAN:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Jika senarai soket menunjukkan pendengar yang terikat pada alamat loopback atau LAN, router menjawab secara setempat dan bukannya memajukan kepada hos lain. Tangkapan kemudian menunjukkan sama ada pertanyaan huluan yang terhasil keluar melalui antara muka terowong atau melalui WAN, dan itulah jawapan yang tidak akan pernah diberikan oleh peraturan laluan dasar.

Mengapa laluan dasar tidak pernah melihat pertanyaan kedua

Peraturan tembok api ditulis terhadap antara muka, sumber, destinasi dan port, dan dinilai untuk paket yang melalui peranti. Pertanyaan yang dijana router tidak melalui apa-apa, kerana proses setempat menyerahkannya terus kepada jadual penghalaan. Penghalaan dasar dan NAT oleh itu hanya terpakai pada laluan dimajukan, dan itulah sebabnya satu set peraturan boleh kelihatan lengkap namun masih meninggalkan DNS router di luar terowong.

Perbezaan itu kekal selepas setiap penulisan semula firmware kerana ia berpunca daripada laluan paket dan bukan daripada ciri. Segala yang dijana peranti untuk dirinya sendiri, sama ada pertanyaan penyelesai, penyegerakan masa, semakan kemas kini atau akses cermin paket, berasal dari setempat dan jatuh ke titik buta yang sama. Itulah juga sebabnya ujian dari komputer riba tidak membuktikan apa-apa tentang router.

Di mana penyelesai pfSense menentukan laluan huluannya sendiri

pfSense menjadikan pemisahan itu kelihatan. Trafik klien boleh dihalakan mengikut dasar melalui get laluan VPN manakala trafik tembok api sendiri mengikut tetapan keluar penyelesai dan bukan peraturan LAN. Dalam antara muka web tetapan itu berada di bawah Services > DNS Resolver > Outgoing Network Interfaces, dan nilainya ialah senarai antara muka yang boleh digunakan oleh penyelesai untuk pertanyaan huluan.

Menamakan antara muka terowong di situ, dan hanya antara muka itu, ialah yang membuatkan carian router sendiri mengikut terowong. Jika dibiarkan pada lalai, penyelesai memilih keluaran daripada jadual penghalaan, yang pada hos dengan dua WAN atau VPN selalunya WAN.

Firmware lain mendedahkan keputusan yang sama di bawah label berbeza: senarai pelayan huluan yang terikat pada alamat sumber, mod hanya memajukan, atau dasar laluan yang didokumenkan. Tetapan yang perlu dicari sentiasa yang memilih keluaran atau sumber untuk pertanyaan yang dijana secara setempat. Rujukan konfigurasi penyelesai mendokumenkan pilihan itu untuk pfSense dan wajar dibaca sebelum perubahan.

Pilih tingkah laku kegagalan sebelum tetapan

Apabila terowong jatuh, dua tingkah laku boleh dipertahankan: hentikan pertanyaan huluan supaya tiada yang bocor, atau kembali kepada penyelesai yang diluluskan pada laluan yang diketahui. Kedua-duanya dasar, dan tiada satu pun yang diperoleh secara lalai. Tentukan mana yang diperlukan rangkaian sebelum menyentuh senarai antara muka.

Menutup semasa kegagalan lebih mudah dipertahankan, tetapi ia mengubah terputusnya terowong menjadi terputusnya penyelesaian nama bagi setiap peranti di belakang router. Sandaran mengekalkan pejabat boleh digunakan, dengan kos pertukaran huluan di luar terowong yang mesti boleh diterima secara sengaja dan bukan secara kebetulan. Tuliskan pilihan itu, kerana orang seterusnya yang melihat alamat penyelesai di luar VPN akan membacanya sebagai kebocoran kecuali nota menyatakan sebaliknya. Nota itulah yang memisahkan sandaran yang didokumenkan daripada penemuan tanpa penjelasan dalam semakan suku tahun berikutnya.

Dua kes merumitkan keputusan. Nama peribadi mungkin memerlukan penyelesai dalaman yang dapat dicapai oleh terowong, dan pelayar atau aplikasi dengan DNS tersulit sendiri boleh memintas router sepenuhnya, jadi penyelesai yang anda konfigurasikan bukan selalu yang digunakan oleh aplikasi tertentu.

Uji kedua-dua laluan dan simpan hasil secara berasingan

Ujian DNS dalam pelayar menjawab soalan sempit: penyelesai mana yang digunakan oleh pelayar itu, dalam keadaan ujian itu. Ia tidak membuat inventori peranti dalam rangkaian dan tidak dapat melihat pertanyaan yang dijana router untuk dirinya sendiri. Anggap outputnya sebagai satu titik data dan bukan audit.

Dari klien LAN, minta router nama awam dan kemudian nama peribadi yang sepatutnya hanya dijawab oleh zon dalaman anda. Kegagalan hanya pada pertanyaan kedua menunjuk kepada pemajuan nama dan bukan terowong:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Kemudian jatuhkan terowong dan ulangi kedua-dua pertanyaan. Jawapan yang ditolak bermakna penyelesai menutup semasa kegagalan; jawapan berjaya menunjuk kepada penyelesai sandaran dan laluan yang digunakannya. Bandingkan itu dengan nota yang anda tulis dan dengan tangkapan pada antara muka WAN yang diambil pada minit yang sama.

Simpan pemerhatian secara berasingan dalam rekod: pertukaran klien dengan router, pertukaran router dengan huluan, dan konfigurasi yang menentukan yang kedua. Perubahan penghalaan kemudian akan melaksanakan pertukaran kedua itu tanpa amaran. Jawapan yang tiba dari tempat lain selain titik akhir VPN bukanlah kebocoran dengan sendirinya; ia menjadi kebocoran hanya apabila konfigurasi memilih laluan itu secara kebetulan.