A hotspot tűzfala a bérlet előtt blokkolja a DHCP-t

Egy új telefon csatlakozik a hotspotjához, nem mutat címet, és soha nem is kap. A hozzáférési pont rendben van, a DHCP-démon fut, és az írt tűzfalszabály összhangban lévőnek tűnik a címtervvel. Valójában azt követeli meg, hogy az ügyfél már rendelkezzen azzal a címmel, amelyet kér. Az első DHCP-csomagnak egyáltalán nincs címe, ezért a szabály soha nem lép működésbe.

Figyelje meg egy ügyfél csatlakozását

Kövessen végig egy társítást az ügyfél oldaláról. A rádió társul, az ügyfél DHCP-felderítést küld, a kiszolgáló ajánlatot ad, az ügyfél kér, a kiszolgáló nyugtáz, és csak ezután van az ügyfélnek bármi másra használható címe.

Minden, ami e végső nyugtázás előtt történik, miközben az ügyfél nem tudja használni az átjárót rendes forgalomra. Ez az az ablak, amelyről az alhálózati szabály megfeledkezik.

Mit tartalmaz valójában az első csomag

Az RFC 2131 előírja, hogy az ügyfél DHCP-sugárzásai a cím megszerzése előtt nulla forráscímet használnak. Az ügyféltől a kiszolgáló felé menő üzenetek az UDP 67-es portra, a kiszolgálótól az ügyfél felé menők az UDP 68-as portra mennek. A felderítés tehát 0.0.0.0 forrással érkezik, és az a szabály, amely az ügyfél alhálózatán belüli forrást követel, egyszerűen nem illeszkedik rá.

Ez nem az ügyfél hibás beállítása. Ez a protokoll a tervezett módon működik, az egyetlen ablakban, ahol ez lehetséges.

Melyik útvonal kezeli valójában

Ha maga a hozzáférési pont oszt bérleteket, ez helyi szolgáltatási beszélgetés, és az IP szerint szűrt helyi útvonalon a bemeneti és kimeneti házirendet érinti. A VPN-en át továbbított ügyfélforgalom más döntés, és az arra a forgalomra vonatkozó NAT megint más. A három összekeverése az, amitől egy szűk kivétel szélessé válik.

Az, hogy hol kezelik a csomagot, a démontól és a használt tűzfalcsaládtól függ. A nyers socketes megvalósítások, a híd-elrendezések és a korábbi szűrőhorgok teljesen máshová mozgathatják vagy blokkolhatják. A szabályok hozzáadása előtt erősítse meg a démon interfészkötését és az aktív horgokat.

Egy fórumról kimásolt általános bemeneti és kimeneti recept nem bizonyíték arra, hogy az Ön megvalósítása ugyanúgy halad át ezeken a láncokon.

A válasz nem mindig sugárzás

Az a kivétel is hibás, amely csak sugárzott válaszokat engedélyez. A DHCP-válasz célja az ügyfél állapotától és az üzenet mezőitől függ, és a protokoll a sugárzásos és az egycímzéses esetet is meghatározza. Ha a kiszolgálója egycímzéses választ ad arra a címre, amelyet épp kiosztani készül, a csak sugárzásra vonatkozó szabály blokkolja a munkát befejező lépést. A szabályt ahhoz az eszmecseréhez írja, amelyet a beállított kiszolgáló valóban végrehajt.

A későbbi bérlethosszabbítások más állapotban ismétlik meg az eszmecserét, ezért hagyjon nekik helyet, és ne csak az első csatlakozásnak.

Szűken javítson, aztán ellenőrizze a többit

Tartsa meg a meglévő házirendet, keresse meg a hiányzó DHCP-engedélyt, és szűkítse az ügyfél felé néző interfészre, a protokollra és a két portra. Bizonyítsa, hogy a kérés eléri a szolgáltatást, majd bizonyítsa, hogy a szolgáltatás válaszol. Ez két különböző megfigyelés, és a szolgáltatás vagy a címkészlet beállítása tökéletes szűrés mögött is hibás lehet.

Egy tábla ürítése nem DHCP-konfigurációs lépés. Az iptablesben a flush törli a szabályokat a kiválasztott láncból vagy táblából, és a NAT-tábla ürítése nem hoz létre fordítási szabályt. A széles ACCEPT-házirendek beállítása eltávolítja a bérbeadástól független védelmet, ezért egyik sem tartozik egy újrahasznosítható hotspot-javításhoz.

Amint az ügyfél bérlettel rendelkezik, ellenőrizze a DNS-t, a továbbítást és a VPN-kimenetet külön feladatként. A bérlet helyi címzést hoz létre, és semmi többet.