Hotspot güvenlik duvarınız DHCP'yi kiralama öncesinde engelliyor

Yeni bir telefon hotspot'unuza bağlanır, hiçbir adres göstermez ve asla alamaz. Erişim noktası sağlam, DHCP sunucusu çalışıyor ve yazdığınız güvenlik duvarı kuralı adres planıyla tutarlı görünüyor. Kural aslında istemcinin istediği adrese zaten sahip olmasını şart koşuyor. İlk DHCP paketinde hiç adres yok, bu yüzden kural hiç devreye girmiyor.

Bir istemcinin bağlanmasını izleyin

Bağlantıyı istemci tarafından takip edin. Radyo ilişkilenir, istemci bir DHCP keşfi gönderir, sunucu teklif eder, istemci talep eder, sunucu onaylar ve ancak bundan sonra istemcinin başka herhangi bir şey için kullanılabilir bir adresi olur.

O son onaydan önceki her şey, istemci ağ geçidini normal trafik için kullanamazken gerçekleşir. Alt ağ kuralının unuttuğu pencere tam olarak budur.

İlk paket gerçekte ne içeriyor

RFC 2131, bir istemcinin adres almadan önceki DHCP yayınlarının sıfır kaynak adresi kullandığını belirtir. İstemciden sunucuya giden mesajlar UDP 67 numaralı bağlantı noktasına, sunucudan istemciye gidenler UDP 68 numaralı bağlantı noktasına gider. Bu nedenle keşif 0.0.0.0 kaynağıyla gelir ve istemci alt ağınızın içinde bir kaynak isteyen kural onunla basitçe eşleşmez.

Bu, istemci tarafında yanlış bir yapılandırma değil. Bu, protokolün tasarlandığı gibi çalışmasıdır; bunu yapabildiği tek pencerede.

Bunu gerçekte hangi yol ele alıyor

Kiraları erişim noktasının kendisi dağıtıyorsa bu yerel bir hizmet görüşmesidir ve IP ile filtrelenen yerel bir yolda giriş ve çıkış politikasıyla ilgilidir. VPN üzerinden iletilen istemci trafiği başka bir karardır ve o trafik için NAT yine başkadır. Bu üçünü karıştırmak, dar bir istisnanın geniş bir istisnaya dönüşme yoludur.

Paketin nerede ele alındığı, sunucu sürecine ve kullanılan güvenlik duvarı ailesine bağlıdır. Ham soket uygulamaları, köprü düzenleri ve daha eski filtreleme kancaları onu tamamen başka bir yere taşıyabilir veya engelleyebilir. Kural eklemeden önce sunucu sürecinin arayüz bağlamasını ve etkin kancaları doğrulayın.

Bir forumdan kopyalanan genel giriş ve çıkış tarifi, uygulamanızın o zincirlerden aynı şekilde geçtiğinin kanıtı değildir.

Yanıt her zaman yayın değildir

Yalnızca yayın yanıtlarına izin veren istisna da yanlıştır. DHCP yanıtının hedefi istemcinin durumuna ve mesajın alanlarına bağlıdır ve protokol hem yayın hem de tek adres durumunu tanımlar. Sunucunuz atamak üzere olduğu adrese tek adresle yanıt veriyorsa, yalnızca yayına izin veren kural işi bitiren adımı engeller. Kuralı, yapılandırılmış sunucunun gerçekte gerçekleştirdiği alışverişe göre yazın.

Sonraki kiralama yenilemeleri alışverişi başka bir durumda tekrarlar, bu yüzden yalnızca ilk bağlantıya değil onlara da yer bırakın.

Dar biçimde düzeltin, sonra geri kalanı denetleyin

Mevcut politikayı koruyun, eksik DHCP iznini bulun ve bunu istemciye bakan arayüzle, protokolle ve iki bağlantı noktasıyla sınırlayın. İsteğin hizmete ulaştığını kanıtlayın, ardından hizmetin yanıt verdiğini kanıtlayın. Bunlar iki farklı gözlemdir ve kusursuz filtrelemenin arkasında hizmet veya havuz yapılandırması hâlâ yanlış olabilir.

Bir tabloyu boşaltmak DHCP yapılandırma adımı değildir. iptables'ta flush, kuralları seçili zincirden veya tablodan siler ve NAT tablosunu boşaltmak bir çeviri kuralı oluşturmaz. Geniş ACCEPT politikaları belirlemek kiralamayla ilgisi olmayan korumayı kaldırır, bu yüzden ikisi de yeniden kullanılabilir bir hotspot düzeltmesine ait değildir.

İstemci bir kiralamaya sahip olduğunda DNS, yönlendirme ve VPN çıkışını ayrı görevler olarak denetleyin. Kiralama yerel adreslemeyi kurar ve fazlasını değil.