Mengapa Balasan DNS Gagal di Firewall Tepi VPN Tanpa Status

Tunnel sudah aktif, klien dapat mencapai host VPN, tetapi host tidak dapat me-resolve apa pun. Kueri keluar miliknya sendiri meninggalkan antarmuka dengan bersih, jadi kegagalannya ada di jalur kembali: pada tepi di hulu yang memfilter lalu lintas masuk tanpa mengingat apa yang baru saja dikirim host. Mengizinkan port tunnel sama sekali tidak menggambarkan pertukaran itu. Balasan atas kueri DNS adalah aliran terpisah, dan jika tepinya tanpa status, tidak ada yang memberinya izin untuk kembali.

Kedua pertukaran itu bukan pertukaran yang sama

Tuliskan tuple-nya dan kesalahannya menjadi jelas. Port tujuan pada permintaan menjadi port sumber pada balasan, yang merupakan kebalikan dari yang dibayangkan kebanyakan orang saat menambahkan aturan masuk untuk port 53:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

Aturan masuk yang mewajibkan port tujuan 53 menggambarkan lalu lintas yang dialamatkan ke pendengar DNS yang berjalan di host, dan itu adalah layanan yang sama sekali berbeda. Alamat-alamat itu adalah contoh dokumentasi, dan port sumber dipilih klien untuk setiap kueri, jadi itu bukan nilai yang dapat Anda salin ke dalam aturan dan harapkan terus berfungsi.

Tepi tanpa status versus firewall host dengan status

Filter tepi tanpa status mengevaluasi setiap paket masuk terhadap daftar aturannya tanpa tabel koneksi di belakangnya. Kueri keluar yang berhasil keluar tidak menciptakan izin apa pun bagi balasan masuknya, karena perangkat tidak memiliki catatan bahwa kueri pernah terjadi. Firewall host dengan status adalah kebalikannya: pelacakan koneksinya mengenali lalu lintas balik dari pertukaran yang diizinkan dan meneruskannya tanpa aturan untuk balasan. Kedua batas ada di jalur yang lazim, dan keduanya harus mengizinkan paket yang dimaksud.

Perbandingan itu penting karena kedua perangkat gagal dengan cara berbeda. Firewall dengan status yang menolak balasan mencatat drop; tepi tanpa status menolaknya secara diam-diam, itulah sebabnya host sekadar kehabisan waktu.

Bangun izinnya di sekitar protokol, bukan nomor port

Batasi aturan ke alamat resolver yang sebenarnya, host tujuan, dan kebijakan port penerima yang didukung produk. Ingat juga jalur TCP DNS, karena balasan besar atau fallback karena pemotongan memindahkan pertukaran ke TCP dan aturan khusus UDP tidak akan mencakupnya. Jika tepi mendukung inspeksi dengan status untuk aliran tertentu, utamakan itu daripada aturan balasan yang ditulis tangan, karena jalur dengan status mengikuti port yang dipilih klien secara otomatis.

Lalu pastikan produk mana di jalur yang benar-benar memfilter lalu lintas. Cakupan tepi IPv4 yang terdokumentasi tidak menetapkan kebijakan IPv6, dan lalu lintas internal penyedia mungkin tidak pernah melewati filter yang sama.

Mengapa mengizinkan port sumber 53 apa pun bukan perbaikan

Aturan yang menerima apa pun yang mengaku memiliki port sumber 53 adalah aturan yang menerima apa yang ditulis pengirim di kolom header. Nomor port tidak mengautentikasi pengirim dan tidak membuktikan bahwa muatannya adalah balasan yang sah, jadi aturan itu memperluas paparan host tanpa membuat resolusi lebih andal. Pertahankan pembatasan sumber dan pertahankan pemeriksaan balasan milik klien sendiri, termasuk pengacakan port sumber, alih-alih mematikannya untuk menyederhanakan daftar akses.

Jika resolver adalah layanan yang Anda kendalikan, membatasinya ke alamatnya saja sudah cukup. Jika itu resolver publik, batasi ke alamat yang Anda setujui dan catat di komentar aturan.

Verifikasi di batas yang tepat, dengan arah yang tepat

Tangkap di host dan di tepi untuk kueri yang sama, lalu bandingkan tuple-nya, bukan jumlah paketnya. Kueri yang terlihat di kedua sisi tanpa balasan yang terlihat di sisi host menunjuk ke filter masuk; kueri yang hanya terlihat di sisi host menunjuk ke perutean atau resolvernya sendiri. Ulangi dengan kueri TCP jika Anda hanya punya izin UDP, karena itulah celah yang tidak dapat dilihat pengujian pertama.

Memperbaiki ini menuntaskan pertukaran DNS yang benar-benar dibutuhkan host. Ini tidak mengubah host menjadi resolver publik, tidak mengizinkan aliran VPN yang diteruskan, dan tidak membuktikan bahwa DNS adalah penyebab masalah tunnel yang tidak terkait.