Firewall hotspot anda menyekat DHCP sebelum pajakan

Telefon baharu menyertai hotspot anda, tidak menunjukkan alamat dan tidak pernah mendapatnya. Titik akses baik, daemon DHCP berjalan, dan peraturan firewall yang anda tulis kelihatan selaras dengan pelan alamat. Apa yang sebenarnya dilakukannya ialah menuntut klien sudah memiliki alamat yang dimintanya. Paket DHCP pertama tidak mempunyai alamat sama sekali, jadi peraturan itu tidak pernah tercetus.

Perhatikan klien menyertai

Ikuti satu persekutuan dari sisi klien. Radio bersekutu, klien menghantar penemuan DHCP, pelayan menawarkan, klien meminta, pelayan mengesahkan, dan hanya selepas itu klien mempunyai alamat yang boleh digunakan untuk apa-apa lagi.

Segala-galanya sebelum pengesahan akhir itu berlaku semasa klien tidak boleh menggunakan get laluan untuk trafik biasa. Itulah tetingkap yang dilupakan oleh peraturan subnet.

Apa yang sebenarnya terkandung dalam paket pertama

RFC 2131 menetapkan bahawa siaran DHCP klien sebelum memperoleh alamat menggunakan alamat sumber sifar. Mesej dari klien ke pelayan pergi ke port UDP 67, dan dari pelayan ke klien ke port UDP 68. Oleh itu penemuan tiba dengan 0.0.0.0 sebagai sumber, dan peraturan yang menuntut sumber di dalam subnet klien anda tidak sepadan dengannya.

Ini bukan salah konfigurasi di pihak klien. Ini protokol yang berfungsi seperti yang direka, dalam satu-satunya tetingkap yang membolehkannya.

Laluan mana yang sebenarnya mengendalikannya

Jika titik akses sendiri menyediakan pajakan, ini perbualan perkhidmatan tempatan, dan pada laluan tempatan yang ditapis IP ia melibatkan dasar input dan output. Trafik klien yang diteruskan melalui VPN ialah keputusan lain, dan NAT untuk trafik itu berbeza lagi. Mencampurkan ketiga-tiganya ialah cara pengecualian sempit menjadi luas.

Di mana paket dikendalikan bergantung pada daemon dan keluarga firewall yang digunakan. Pelaksanaan soket mentah, susunan jambatan dan cangkuk penapisan terdahulu boleh memindahkan atau menyekatnya di tempat yang sama sekali berbeza. Sahkan pengikatan antara muka daemon dan cangkuk yang aktif sebelum menambah peraturan.

Resipi input dan output umum yang disalin dari forum bukan bukti bahawa pelaksanaan anda melalui rantaian itu dengan cara yang sama.

Balasan tidak selalu siaran

Pengecualian yang hanya membenarkan balasan siaran juga salah. Destinasi balasan DHCP bergantung pada keadaan klien dan medan mesej, dan protokol menetapkan kedua-dua kes siaran dan unicast. Jika pelayan anda membalas unicast ke alamat yang akan diperuntukkannya, peraturan siaran sahaja menyekat langkah yang menyelesaikan kerja. Tulis peraturan berdasarkan pertukaran yang benar-benar dilakukan oleh pelayan yang dikonfigurasikan.

Pembaharuan pajakan kemudian mengulangi pertukaran dalam keadaan berbeza, jadi beri ruang untuknya dan bukan hanya untuk penyertaan pertama.

Betulkan secara sempit, kemudian periksa selebihnya

Kekalkan dasar sedia ada, cari kebenaran DHCP yang hilang dan hadkannya kepada antara muka menghadap klien, protokol dan dua port. Buktikan permintaan sampai ke perkhidmatan, kemudian buktikan perkhidmatan membalas. Itu dua pemerhatian berbeza, dan konfigurasi perkhidmatan atau kumpulan alamat masih boleh salah di sebalik penapisan sempurna.

Mengosongkan jadual bukan langkah konfigurasi DHCP. Dalam iptables, flush memadam peraturan daripada rantaian atau jadual yang dipilih, dan mengosongkan jadual NAT tidak mencipta peraturan terjemahan. Menetapkan dasar ACCEPT yang luas membuang perlindungan yang tidak berkaitan dengan pajakan, sebab itu kedua-duanya tidak tergolong dalam pembaikan hotspot yang boleh diguna semula.

Setelah klien memegang pajakan, periksa DNS, penghantaran dan jalan keluar VPN sebagai tugas berasingan. Pajakan menetapkan pengalamatan tempatan dan tiada lagi.