OpenWrt-ийн бодлогын маршрутлал: локал DNS-ийг барьдаг гинжин хэлхээ

LAN дахь клиентүүд туннелээр шийддэг бол маршрутизаторын өөрийн хайлтууд чимээгүйхэн тэгдэггүй. Багцын шинэчлэл, цаг синхрончлол, динамик DNS бүгд ердийн uplink-ээр гардаг бол дамжуулагдсан хүсэлт бүр VPN-ийг авдаг, интерфэйсэд хоёр өөр зам байгааг юу ч илрүүлэхгүй. Тайлбар нь бодлогын алдаа биш, харин аль дэгээ багцыг хардаг гэсэн асуулт юм. Хоёр урсгал, нэг шийдэгчийн хаяг, тэдгээрийн зөвхөн нэг нь маршрутизаторыг гатална. Тэдгээрийг салгах нь бүх засвар юм.

Хоёр урсгал, нэг шийдэгчийн хаяг

Эхний урсгал бол хүмүүсийн төсөөлдөг урсгал юм. Клиент маршрутизаторын шийдэгчээс асууна, шийдэгч дээш дамжуулна, тэр дамжуулагдсан багц гарахдаа маршрутизаторыг дайрна. Тэр багц нь дамжуулагдсан урсгалыг ажиглаж буй бүхэнд харагдана.

Хоёр дахь урсгал хаанаас ч хэзээ ч ирдэггүй. Маршрутизатор үүнийг үүсгэдэг тул орж ирэх багц ч, тааруулах дамжуулалтын алхам ч байхгүй.

Хоёулаа нэг шийдэгчийн хаягийг зорьж болох бөгөөд яг ийм учраас ялгааг анзаарахгүй байх амархан. Ижил очих газар, өөр гарал үүсэл, өөр гинжин хэлхээ. Гарал үүслийг хармагц оношилгооны үлдсэн хэсэг үргэлжилнэ.

Дамжуулагдсан болон локал үүсгэсэн багцууд өөрөөр ордог

Дамжуулагдсан урсгал нь өөр интерфэйсээс ирэх үед үнэлэгддэг. Бодлогын маршрутлалын багцууд үүнийг prerouting гинжин хэлхээ хэлбэрээр илчилдэг бөгөөд тэнд тавьсан дүрэм маршрутизаторыг дайрч буй багц бүрийг хардаг. Тиймээс клиентийн хайлтууд бодлогын тодорхойлсноор яг ажилладаг бөгөөд тиймээс маршрутизатор үүнийг үл тоомсорлодог. Дүрэм буруу биш, зүгээр л маршрутизатор хэзээ ч хүрдэггүй дэгээнд бэхлэгдсэн. Үүнийг зөө, тэгэхэд ижил таарц ажиллаж эхэлнэ.

Локал үүсгэсэн урсгалыг маршрутизатор дээрх процесс үүсгэдэг бөгөөд гарцын замд ордог. Үүнийг маршрутизаторын өөрийн шийдвэр маршрутладаг бөгөөд бодлого тэр гинжин хэлхээг хамарсан тохиолдолд л бодлоготой таарна. Тааруулах орж ирэх интерфэйс ч, ажиглах дамжуулалтын шийдвэр ч байхгүй.

Энэ нь багцууд хаана төрдөг тухай шинж чанар бөгөөд тодорхой нэг багцынх биш. Нэг гинжин хэлхээнд зориулж бичсэн дүрэм нөгөөгийн талаар энгийнээр саналгүй. Ямар ч дүрмийн тохируулга үүнийг өөрчлөхгүй.

Гарцын гинжин хэлхээг сонгоод дараа нь таарцыг нарийсга

Засвар бол ижил санааг гарцын гинжин хэлхээнд мөн холбох, эсвэл маршрутизаторын өөрийн хүсэлтүүд чухал бол дүрмийг тэнд зөөх юм. Бодлогын маршрутлалын багц дээр бүтээсэн OpenWrt тохиргоонд энэ нь дүрмийн гинжин хэлхээний тохиргоонд prerouting-ийн оронд output сонгохыг хэлнэ. Хоёр популяцид хамрах хэрэгтэй бол хоёр дүрмийг хоёуланг нь хадгал.

Дараа нь дүрэм юутай таарахыг нарийсга. Шийдэгч бодитоор ашигладаг порт дээрх очих газрын шийдэгчийн хаягууд нь маршрутизаторын үүсгэсэн бүхнийг туннелд илгээхээс хамаагүй бага шийдвэр юм.

Хоёр гинжин хэлхээг хамардаг нэгийг бичихийг оролдохын оронд хоёр дүрмийг тодорхой байлга. Тусдаа дүрмүүд уншихад хялбар бөгөөд дибаг хийх үед клиентийн урсгалыг саатуулахгүйгээр маршрутизаторын замыг идэвхгүй болгох боломж олгодог. Мөн тоолуурыг нэг нэгээр нь утга учиртай болгодог.

Туннелийн өөрийн тээврийг дүрмээс гадуур байлга

Туннелийн гадаад холболтыг мөн маршрутизатор үүсгэдэг. Локал үүсгэсэн бүх урсгалыг туннелд илгээдэг дүрэм туннелийг өөрөөр дамжуулан маршрутлаж, туннель огт босохгүй.

Удирдлагын хандалт бол хоёр дахь хохирол. Маршрутизатороос үүссэн захиргааны сессүүд эсвэл тэдгээрт өгөх хариултууд хэт өргөн локал дүрмээр туннелд татагдаж, LAN-аас хүрэх боломжгүй болж болно.

Туннелийн төгсгөлийн цэгийг таарцаас хасаж, дүрмийг шийдэгчийн хаягуудад хязгаарла. Энэ нь DNS шаардлагад хангалттай бөгөөд тухай бодоход хангалттай бага.

Нэг биш хоёр популяцийг шалга

Маршрутизатор өөрийн хүсэлтийг хийж буйг ажиглаж, аль интерфэйс түүнийг зөөснийг тэмдэглэ. Хайлтыг LAN хостноос давтаж, аль замаар явсныг тэмдэглэ. Бодлогын дүрмүүд дээрх тоолуурууд хоёр хариултыг таамаглалгүйгээр харагдуулна.

Үр дүнг хоёр тусдаа нээлт гэж үз. Туннелээр шийддэг клиент маршрутизаторын талаар юу ч хэлэхгүй, зөв шийддэг маршрутизатор өөр сонсогч дээрх клиентийн талаар юу ч хэлэхгүй. Тэдгээрийг өөрчлөлтийн бүртгэлд тусдаа мөр болгон бич.

Портыг ч шалга: очих газрын порт 53-тай таардаг дүрэм 853 дээр DNS over TLS эсвэл HTTPS төгсгөлийн цэгээр хүрдэг шийдэгчийг алгасдаг. Тохируулсан upstream бодитоор ашигладаг тээвэртэй тааруул, тэгвэл алдагдал зөв шалтгаанаар хаагдана.