Firewall hotspot Anda memblokir DHCP sebelum sewa

Ponsel baru bergabung ke hotspot Anda, tidak menampilkan alamat, dan tidak pernah mendapatkannya. Titik akses baik-baik saja, daemon DHCP berjalan, dan aturan firewall yang Anda tulis tampak konsisten dengan rencana alamat. Yang sebenarnya dilakukannya adalah menuntut klien sudah memegang alamat yang dimintanya. Paket DHCP pertama tidak memiliki alamat sama sekali, jadi aturan itu tidak pernah aktif.

Amati klien bergabung

Ikuti satu asosiasi dari sisi klien. Radio berasosiasi, klien mengirim penemuan DHCP, server menawarkan, klien meminta, server mengakui, dan baru setelah itu klien memiliki alamat yang dapat dipakai untuk hal lain.

Semua yang terjadi sebelum pengakuan terakhir itu berlangsung saat klien tidak dapat memakai gateway untuk lalu lintas biasa. Itulah jendela yang dilupakan aturan subnet.

Apa isi paket pertama sebenarnya

RFC 2131 menetapkan bahwa siaran DHCP klien sebelum memperoleh alamat memakai alamat sumber nol. Pesan dari klien ke server menuju port UDP 67, dan pesan dari server ke klien menuju port UDP 68. Karena itu penemuan tiba dengan 0.0.0.0 sebagai sumber, dan aturan yang menuntut sumber di dalam subnet klien Anda tidak cocok dengannya.

Ini bukan kesalahan konfigurasi di pihak klien. Ini protokol yang bekerja sebagaimana dirancang, di satu-satunya jendela tempat ia bisa.

Jalur mana yang sebenarnya menanganinya

Jika titik akses sendiri yang menyajikan sewa, ini percakapan layanan lokal, dan pada jalur lokal yang difilter IP hal ini menyangkut kebijakan masukan dan keluaran. Lalu lintas klien yang diteruskan melalui VPN adalah keputusan lain, dan NAT untuk lalu lintas itu berbeda lagi. Mencampur ketiganya adalah cara pengecualian sempit menjadi lebar.

Di mana paket ditangani bergantung pada daemon dan keluarga firewall yang dipakai. Implementasi soket mentah, penataan jembatan, dan kait penyaringan yang lebih awal dapat memindahkan atau memblokirnya di tempat yang sama sekali lain. Pastikan pengikatan antarmuka daemon dan kait yang aktif sebelum menambahkan aturan.

Resep masukan dan keluaran umum yang disalin dari forum bukan bukti bahwa implementasi Anda melewati rantai itu dengan cara yang sama.

Balasan tidak selalu berupa siaran

Pengecualian yang hanya mengizinkan balasan siaran juga salah. Tujuan balasan DHCP bergantung pada status klien dan bidang pesan, dan protokol menetapkan kasus siaran maupun unicast. Jika server Anda membalas unicast ke alamat yang akan segera diberikannya, aturan hanya-siaran memblokir langkah yang menyelesaikan pekerjaan. Tulis aturan sesuai pertukaran yang benar-benar dilakukan server yang dikonfigurasi.

Pembaruan sewa berikutnya mengulang pertukaran dalam status berbeda, jadi beri ruang untuk itu, bukan hanya untuk penggabungan pertama.

Perbaiki secara sempit, lalu periksa sisanya

Pertahankan kebijakan yang ada, temukan izin DHCP yang hilang, dan batasi pada antarmuka yang menghadap klien, protokol, dan dua port. Buktikan permintaan mencapai layanan, lalu buktikan layanan menjawab. Itu dua pengamatan berbeda, dan konfigurasi layanan atau kumpulan alamat masih bisa salah di balik penyaringan yang sempurna.

Mengosongkan tabel bukan langkah konfigurasi DHCP. Di iptables, flush menghapus aturan dari rantai atau tabel yang dipilih, dan mengosongkan tabel NAT tidak membuat aturan penerjemahan. Menetapkan kebijakan ACCEPT yang lebar menghapus perlindungan yang tidak terkait dengan sewa, sehingga keduanya tidak termasuk dalam perbaikan hotspot yang dapat dipakai ulang.

Setelah klien memegang sewa, periksa DNS, penerusan, dan jalan keluar VPN sebagai tugas terpisah. Sewa menetapkan pengalamatan lokal dan tidak lebih dari itu.