Mengapa DNS milik router sendiri melewati terowongan VPN?
Pencarian klien dan kueri hulu router adalah dua aliran berbeda. Tangkap keduanya, pilih jalan keluar resolver, lalu uji kasus terputusnya terowongan.
Pencarian klien mengikuti terowongan, sedangkan pencarian milik router sendiri keluar melalui WAN, dan aturan firewall yang mengatur yang satu tidak berpengaruh pada yang lain. Alasannya bukan bug: permintaan yang diteruskan dan permintaan yang dibuat router sendiri adalah dua aliran terpisah, dan masing-masing dicocokkan dengan bagian konfigurasi yang berbeda. Menangkap hanya separuh klien menghasilkan jawaban yakin tentang jalur yang tidak pernah dipakai separuh kedua. Perbaikannya adalah mengarahkan resolver router secara sengaja, lalu menguji kedua jalur secara terpisah.
Aliran mana yang sebenarnya menjadi milik tangkapan paket
Satu pencarian melibatkan dua pertukaran. Klien LAN mengirim kueri ke resolver router, dan kueri itu tiba sebagai lalu lintas diteruskan pada antarmuka LAN, sehingga rute kebijakan atau aturan NAT yang ditulis untuk paket diteruskan dapat mencocokkannya. Router lalu menjawab dari cache atau, jika tidak ada, membuka kuerinya sendiri ke server hulu.
Kueri kedua itu bersumber dari router sendiri dan tujuannya juga dirinya sendiri, dan platform memilih jalurnya dari blok konfigurasi yang berbeda. Kedua pertukaran membawa nama yang sama, dan tidak satu pun merupakan salinan yang lain. Karena itu tangkapan yang diambil di sisi LAN membuktikan ke mana paket klien pergi dan tidak mengatakan apa pun tentang paket keluar.
Pemeriksaan praktisnya adalah mengamati kedua sisi sekaligus. Di router, daftarkan soket resolver, tanyakan secara lokal, dan tangkap antarmuka WAN:
sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53Jika daftar soket menunjukkan pendengar yang terikat ke alamat loopback atau LAN, router menjawab secara lokal alih-alih meneruskan ke host lain. Tangkapan lalu menunjukkan apakah kueri hulu yang dihasilkan keluar melalui antarmuka terowongan atau melalui WAN, dan itulah jawaban yang tidak akan pernah diberikan aturan rute kebijakan.
Mengapa rute kebijakan tidak pernah melihat kueri kedua
Aturan firewall ditulis terhadap antarmuka, sumber, tujuan, dan port, dan dinilai untuk paket yang melewati kotak. Kueri yang dibuat router tidak melewati apa pun, karena proses lokal menyerahkannya langsung ke tabel perutean. Perutean kebijakan dan NAT karena itu hanya berlaku pada jalur yang diteruskan, dan itulah sebabnya sekumpulan aturan bisa tampak lengkap namun tetap meninggalkan DNS router di luar terowongan.
Perbedaan itu bertahan setelah setiap penulisan ulang firmware karena berasal dari jalur paket, bukan dari fitur. Semua yang dibuat kotak untuk dirinya sendiri, baik kueri resolver, sinkronisasi waktu, pemeriksaan pembaruan, maupun akses cermin paket, berasal dari lokal dan jatuh ke titik buta yang sama. Itu juga sebabnya pengujian dari laptop tidak membuktikan apa pun tentang router.
Di mana resolver pfSense memutuskan jalur hulunya sendiri
pfSense membuat pemisahan itu terlihat. Lalu lintas klien dapat dirutekan berdasarkan kebijakan melalui gateway VPN sementara lalu lintas firewall sendiri mengikuti pengaturan keluar resolver alih-alih aturan LAN. Di antarmuka web, pengaturan itu berada di bawah Services > DNS Resolver > Outgoing Network Interfaces, dan nilainya adalah daftar antarmuka yang boleh digunakan resolver untuk kueri hulu.
Menyebut antarmuka terowongan di sana, dan hanya antarmuka itu, adalah yang membuat pencarian router sendiri mengikuti terowongan. Jika dibiarkan pada bawaan, resolver memilih jalan keluar dari tabel perutean, yang pada host dengan dua WAN atau VPN sering kali WAN.
Firmware lain menampilkan keputusan yang sama dengan label berbeda: daftar server hulu yang terikat ke alamat sumber, mode hanya meneruskan, atau kebijakan rute yang terdokumentasi. Pengaturan yang harus dicari selalu yang memilih jalan keluar atau sumber untuk kueri yang dibuat secara lokal. Referensi konfigurasi resolver mendokumentasikan opsi itu untuk pfSense dan layak dibaca sebelum perubahan.
Pilih perilaku kegagalan sebelum pengaturan
Saat terowongan jatuh, dua perilaku dapat dipertahankan: hentikan kueri hulu agar tidak ada yang bocor, atau beralih ke resolver yang disetujui pada jalur yang diketahui. Keduanya kebijakan, dan tidak satu pun yang didapat secara bawaan. Putuskan mana yang dibutuhkan jaringan sebelum menyentuh daftar antarmuka.
Menutup saat gagal lebih mudah dipertahankan, tetapi mengubah terputusnya terowongan menjadi terputusnya resolusi nama bagi setiap perangkat di belakang router. Cadangan menjaga kantor tetap bisa dipakai, dengan biaya pertukaran hulu di luar terowongan yang harus dapat diterima secara sengaja bukan kebetulan. Tuliskan pilihannya, karena orang berikutnya yang melihat alamat resolver di luar VPN akan membacanya sebagai kebocoran kecuali catatan mengatakan sebaliknya. Catatan itulah yang memisahkan cadangan terdokumentasi dari temuan tanpa penjelasan dalam tinjauan kuartal berikutnya.
Dua kasus mempersulit keputusan. Nama privat mungkin memerlukan resolver internal yang dapat dijangkau terowongan, dan peramban atau aplikasi dengan DNS terenkripsi sendiri dapat melewati router sepenuhnya, jadi resolver yang Anda konfigurasikan tidak selalu yang dipakai aplikasi tertentu.
Uji kedua jalur dan simpan hasilnya terpisah
Pengujian DNS berbasis peramban menjawab pertanyaan sempit: resolver mana yang dipakai peramban itu, dalam kondisi pengujian itu. Pengujian itu tidak menginventarisasi perangkat di jaringan dan tidak dapat melihat kueri yang dibuat router untuk dirinya sendiri. Perlakukan keluarannya sebagai satu titik data, bukan sebagai audit.
Dari klien LAN, minta router sebuah nama publik lalu nama privat yang seharusnya hanya dijawab zona internal Anda. Kegagalan hanya pada kueri kedua menunjuk ke penerusan nama, bukan ke terowongan:
dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lanLalu jatuhkan terowongan dan ulangi kedua kueri. Jawaban yang ditolak berarti resolver menutup saat gagal; jawaban yang berhasil menunjuk ke resolver cadangan dan jalur yang dipakainya. Bandingkan itu dengan catatan yang Anda tulis dan dengan tangkapan pada antarmuka WAN yang diambil pada menit yang sama.
Simpan pengamatan secara terpisah dalam catatan: pertukaran klien dengan router, pertukaran router dengan hulu, dan konfigurasi yang memutuskan yang kedua. Perubahan perutean nanti akan menjalankan pertukaran kedua itu tanpa peringatan. Jawaban yang datang dari tempat lain selain titik akhir VPN tidak dengan sendirinya merupakan kebocoran; jawaban itu menjadi kebocoran hanya ketika konfigurasi memilih jalur itu secara kebetulan.