Огнениот ѕид на вашиот хотспот го блокира DHCP пред закупот

Нов телефон се поврзува со вашиот хотспот, не покажува адреса и никогаш не ја добива. Пристапната точка е во ред, DHCP демонот работи, а правилото на огнениот ѕид што го напишавте изгледа складно со планот за адреси. Она што всушност го прави е да бара клиентот веќе да ја има адресата што ја бара. Првиот DHCP пакет воопшто нема адреса, така што правилото никогаш не се активира.

Гледајте како се поврзува клиент

Следете една асоцијација од страната на клиентот. Радиото се асоцира, клиентот испраќа DHCP откривање, серверот нуди, клиентот бара, серверот потврдува, и само тогаш клиентот има адреса употреблива за нешто друго.

Сѐ пред таа последна потврда се случува додека клиентот не може да го користи порталот за обичен сообраќај. Тоа е прозорецот што правилото за подмрежа го заборава.

Што всушност содржи првиот пакет

RFC 2131 определува дека DHCP емитувањата на клиентот пред да добие адреса користат изворна адреса нула. Пораките од клиентот кон серверот одат на UDP порта 67, а од серверот кон клиентот на UDP порта 68. Затоа откривањето пристигнува со 0.0.0.0 како извор, а правилото што бара извор внатре во вашата клиентска подмрежа едноставно не се совпаѓа со него.

Ова не е погрешна конфигурација од страната на клиентот. Ова е протоколот што работи како што е проектиран, во единствениот прозорец каде што тоа е можно.

Која патека всушност го обработува

Ако пристапната точка самата дава закупи, ова е локален разговор со услуга, и во локална патека филтрирана по IP се однесува на политиката за влез и излез. Клиентскиот сообраќај препратен преку VPN е друга одлука, а NAT за тој сообраќај е повторно друг. Мешањето на тие три е начинот на кој тесниот исклучок станува широк.

Каде се обработува пакетот зависи од демонот и од семејството огнен ѕид што се користи. Имплементациите со сурови сокети, мостните поставки и поранешните куки за филтрирање можат целосно да го преместат или блокираат на друго место. Потврдете го поврзувањето на интерфејсот на демонот и активните куки пред да додадете правила.

Општ рецепт за влез и излез копиран од форум не е доказ дека вашата имплементација ги поминува тие синџири на ист начин.

Одговорот не е секогаш емитување

Исклучокот што дозволува само емитувани одговори е исто така погрешен. Одредиштето на DHCP одговорот зависи од состојбата на клиентот и полињата на пораката, а протоколот ги определува и емитуваниот и едноадресниот случај. Ако вашиот сервер одговара едноадресно на адреса што треба да ја додели, правилото само за емитување го блокира чекорот што ја завршува работата. Напишете го правилото според размената што конфигурираниот сервер навистина ја изведува.

Подоцнежните обновувања на закупот ја повторуваат размената во друга состојба, затоа оставете место и за нив, а не само за првото поврзување.

Поправете тесно, потоа проверете го остатокот

Задржете ја постојната политика, пронајдете го дозволувањето за DHCP што недостига и ограничете го на интерфејсот свртен кон клиентот, протоколот и двете порти. Докажете дека барањето стигнува до услугата, потоа докажете дека услугата одговара. Тоа се две различни набљудувања, а конфигурацијата на услугата или базенот на адреси сѐ уште може да биде погрешна зад совршено филтрирање.

Празнењето табела не е чекор од DHCP конфигурацијата. Во iptables flush брише правила од избраниот синџир или табела, а празнењето на NAT табелата не создава правило за превод. Поставувањето широки ACCEPT политики отстранува заштита што не е поврзана со закупот, затоа ниту едното ниту другото не припаѓа во повеќекратно употреблива поправка на хотспот.

Откако клиентот ќе добие закуп, проверете DNS, препраќањето и излезот преку VPN како одделни задачи. Закупот воспоставува локално адресирање и ништо повеќе.