Таны хотспотын галт хана DHCP-г түрээсийн өмнө блоклодог
Үйлчлүүлэгчийн дэд сүлжээний дүрэм эхний DHCP хүсэлтэд хэзээ ч таарахгүй, учир нь тэр хүсэлт 0.0.0.0-ээс ирдэг. Оронд нь локал замыг зөвшөөрнө үү.
Шинэ утас таны хотспотод нэгдэж, ямар ч хаяг харуулахгүй, хэзээ ч авдаггүй. Холбогдох цэг хэвийн, 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 гаралтыг тусдаа ажлууд болгон шалгаарай. Түрээс нь локал хаяглалтыг тогтоодог, үүнээс илүү зүйл биш.