Hotspot firewallunuz DHCP-ni icarədən əvvəl bloklayır

Yeni telefon hotspotunuza qoşulur, heç bir ünvan göstərmir və heç vaxt ünvan almır. Giriş nöqtəsi qaydasındadır, DHCP demonu işləyir və yazdığınız firewall qaydası ünvan planına uyğun görünür. Amma o, əslində müştərinin artıq soruşduğu ünvanı daşımasını tələb edir. İlk DHCP paketinin ümumiyyətlə ünvanı yoxdur, ona görə də qayda heç vaxt işə düşmür.

Müştərinin qoşulmasını izləyin

Bir assosiasiyanı müştəri tərəfindən izləyin. Radio assosiasiya edir, müştəri DHCP kəşfi göndərir, server təklif edir, müştəri sorğu göndərir, server təsdiqləyir və yalnız bundan sonra müştərinin başqa bir şey üçün yararlı ünvanı olur.

Son təsdiqdən əvvəlki hər şey müştərinin şlüzü adi trafik üçün istifadə edə bilmədiyi vaxt baş verir. Alt şəbəkə qaydasının unutduğu pəncərə budur.

İlk paketin əslində nə ehtiva etdiyi

RFC 2131 müəyyən edir ki, müştərinin ünvan almadan əvvəlki DHCP yayımları sıfır mənbə ünvanından istifadə edir. Müştəridən serverə mesajlar UDP 67 portuna, serverdən müştəriyə mesajlar isə UDP 68 portuna gedir. Buna görə kəşf mənbə olaraq 0.0.0.0 ilə gəlir və mənbənin müştəri alt şəbəkənizdə olmasını tələb edən qayda ona sadəcə uyğun gəlmir.

Bu, müştəri tərəfində səhv konfiqurasiya deyil. Bu, protokolun nəzərdə tutulduğu kimi işləməsidir, mümkün olan yeganə pəncərədə.

Bunu əslində hansı yol idarə edir

Əgər giriş nöqtəsi özü icarələri verirsə, bu yerli xidmət söhbətidir və IP ilə filtrlənən yerli yolda giriş və çıxış siyasətinə aiddir. VPN vasitəsilə yönləndirilən müştəri trafiki başqa qərardır, həmin trafik üçün NAT isə yenə başqadır. Bu üçünü qarışdırmaq dar istisnanın geniş istisnaya çevrilmə üsuludur.

Paketin harada idarə olunduğu demondan və istifadə edilən firewall ailəsindən asılıdır. Xam soket tətbiqləri, körpü qurğuları və daha erkən filtrləmə qarmaqları onu tamamilə başqa yerə köçürə və ya bloklaya bilər. Qaydalar əlavə etməzdən əvvəl demonun interfeys bağlamasını və işləyən qarmaqları təsdiqləyin.

Forumdan köçürülmüş ümumi giriş/çıxış resepti sizin tətbiqinizin həmin zəncirərdən eyni şəkildə keçdiyinə sübut deyil.

Cavab həmişə yayım olmur

Yalnız yayım cavablarına icazə verən istisna da səhvidir. DHCP cavabının təyinatı müştərinin vəziyyətindən və mesaj sahələrindən asılıdır və protokol həm yayım, həm də təkərim hallarını müəyyən edir. Əgər serveriniz təyin etmək üzrə olduğu ünvana təkərim cavab verirsə, yalnız yayıma icazə verən qayda işi bitirən addımı bloklayır. Qaydanı konfiqurasiya edilmiş serverin həqiqətən etdiyi mübadiləyə uyğun yazın.

Sonrakı icarə yeniləmələri mübadiləni başqa vəziyyətdə təkrarlayır, ona görə yalnız ilk qoşulma üçün deyil, onlar üçün də yer buraxın.

Dar düzəldin, sonra qalanını yoxlayın

Mövcud siyasəti saxlayın, çatışmayan DHCP icazəsini tapın və onu müştəriyə baxan interfeys, protokol və iki portla məhdudlaşdırın. Sorğunun xidmətə çatdığını sübut edin, sonra xidmətin cavab verdiyini sübut edin. Bunlar iki fərqli müşahidədir və xidmət və ya hovuz konfiqurasiyası mükəmməl filtrləmənin arxasında hələ də səhv ola bilər.

Cədvəli boşaltmaq DHCP konfiqurasiya addımı deyil. iptables-da flush seçilmiş zəncirdən və ya cədvəldən qaydaları silir və NAT cədvəlini boşaltmaq tərcümə qaydası yaratmır. Geniş ACCEPT siyasətləri qurmaq icarə ilə əlaqəsi olmayan qorunmanı aradan qaldırır, buna görə də heç biri təkrar istifadə edilə bilən hotspot düzəlişinə aid deyil.

Müştəri icarəni aldıqdan sonra DNS-i, yönləndirməni və VPN çıxışını ayrı vəzifələr kimi yoxlayın. İcarə yerli ünvanlamanı qurur və ondan başqa heç nəyi.