Хотспотыңыздың брандмауэры 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 шығысын бөлек тапсырмалар ретінде тексеріңіз. Жалдау жергілікті мекенжайлауды орнатады, одан артық емес.