Mengapa Balasan DNS Gagal pada Firewall Tepi VPN Tanpa Keadaan

Terowong sudah aktif, klien boleh mencapai hos VPN, tetapi hos tidak dapat menyelesaikan apa-apa. Pertanyaan keluar miliknya sendiri meninggalkan antara muka dengan bersih, jadi kegagalan berlaku pada laluan balik: pada tepi di hulu yang menapis trafik masuk tanpa mengingati apa yang baru dihantar oleh hos. Membenarkan port terowong sama sekali tidak menggambarkan pertukaran itu. Balasan kepada pertanyaan DNS ialah aliran berasingan, dan jika tepi itu tanpa keadaan, tiada apa yang memberinya kebenaran untuk kembali.

Dua pertukaran itu bukan pertukaran yang sama

Tuliskan tupel dan kesilapan menjadi jelas. Port destinasi permintaan menjadi port sumber balasan, iaitu bertentangan dengan apa yang dibayangkan oleh kebanyakan orang apabila menambah peraturan 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

Peraturan masuk yang memerlukan port destinasi 53 menggambarkan trafik yang dialamatkan kepada pendengar DNS yang berjalan pada hos, dan itu ialah perkhidmatan yang sama sekali berbeza. Alamat itu ialah contoh dokumentasi, dan port sumber dipilih oleh klien bagi setiap pertanyaan, jadi ia bukan nilai yang boleh disalin ke dalam peraturan dan diharapkan terus berfungsi.

Tepi tanpa keadaan berbanding firewall hos berkeadaan

Penapis tepi tanpa keadaan menilai setiap paket masuk terhadap senarai peraturannya tanpa jadual sambungan di belakangnya. Pertanyaan keluar yang berjaya keluar tidak mencipta sebarang kebenaran untuk balasan masuknya, kerana peranti tidak mempunyai rekod bahawa pertanyaan pernah berlaku. Firewall hos berkeadaan adalah sebaliknya: penjejakan sambungannya mengenali trafik balik bagi pertukaran yang dibenarkan dan meluluskannya tanpa peraturan untuk balasan. Kedua-dua sempadan wujud dalam laluan biasa, dan kedua-duanya mesti membenarkan paket yang dimaksudkan.

Perbandingan itu penting kerana kedua-dua peranti gagal secara berbeza. Firewall berkeadaan yang menolak balasan mencatatkan drop; tepi tanpa keadaan menolaknya secara senyap, sebab itulah hos hanya tamat masa.

Bina kebenaran di sekeliling protokol, bukan nombor port

Hadkan peraturan kepada alamat penyelesai sebenar, hos destinasi dan dasar port penerimaan yang disokong oleh produk. Ingat juga laluan TCP DNS, kerana balasan besar atau undur kerana pemotongan memindahkan pertukaran ke TCP dan peraturan UDP sahaja tidak akan meliputinya. Jika tepi menyokong pemeriksaan berkeadaan untuk aliran yang ditentukan, utamakan ia berbanding peraturan balasan yang ditulis tangan, kerana laluan berkeadaan mengikut port yang dipilih klien secara automatik.

Kemudian sahkan produk mana dalam laluan yang benar-benar menapis trafik. Skop tepi IPv4 yang didokumenkan tidak menetapkan dasar IPv6, dan trafik dalaman penyedia mungkin tidak pernah melalui penapis yang sama.

Mengapa membenarkan mana-mana port sumber 53 bukan pembetulan

Peraturan yang menerima apa sahaja yang mendakwa mempunyai port sumber 53 ialah peraturan yang menerima apa yang ditulis oleh penghantar dalam medan pengepala. Nombor port tidak mengesahkan penghantar dan tidak membuktikan muatan itu balasan yang sah, jadi peraturan itu meluaskan pendedahan hos tanpa menjadikan penyelesaian lebih boleh dipercayai. Kekalkan sekatan sumber dan kekalkan semakan balasan klien sendiri, termasuk pengacakan port sumber, daripada mematikannya untuk memudahkan senarai akses.

Jika penyelesai itu perkhidmatan yang anda kawal, mengehadkannya kepada alamatnya sudah memadai. Jika ia penyelesai awam, hadkan kepada alamat yang anda luluskan dan catatkannya dalam ulasan peraturan.

Sahkan pada sempadan yang betul, dalam arah yang betul

Tangkap pada hos dan pada tepi untuk pertanyaan yang sama, dan bandingkan tupel bukan kiraan paket. Pertanyaan yang kelihatan pada kedua-dua belah tanpa balasan kelihatan pada sebelah hos menunjukkan penapis masuk; pertanyaan yang kelihatan hanya pada sebelah hos menunjukkan penghalaan atau penyelesai itu sendiri. Ulangi dengan pertanyaan TCP jika anda hanya mempunyai kebenaran UDP, kerana itulah jurang yang tidak dapat dilihat oleh ujian pertama.

Membetulkan ini melengkapkan pertukaran DNS yang benar-benar diperlukan oleh hos. Ia tidak menjadikan hos sebagai penyelesai awam, tidak membenarkan aliran VPN yang diteruskan, dan tidak membuktikan bahawa DNS ialah punca sesuatu masalah terowong yang tidak berkaitan.