Жаңы телефон хотспотуңузга кошулат, эч кандай дарек көрсөтпөйт жана эч качан албайт. Кирүү чекити тартипте, 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 чыгуусун өзүнчө тапшырмалар катары текшериңиз. Ижара жергиликтүү даректөөнү орнотот, андан ары эч нерсе эмес.

Тектеш макалалар