StrongSwan Mac хүрч чадахгүй DNS хаягийг илгээдэг

Хэн нэгэн MacBook нээх хүртэл бүх зүйл ажилладаг. Туннель тогтоогдож, дотоод хост хаягаар хариулж, нэрийн шийдэл үхдэг. iPhone дээр ижил профайл ижилхэн ажилладаг бол Windows болон Linux клиентүүд хэвийн байна. Ихэвчлэн илгээсэн DNS шинж чанар нь буруутай: сервер өөрийн нийтийн интерфейсийн хаягийг тараадаг бөгөөд Apple-ийн IKEv2 клиент туннелиэр дамжуулан тэнд асуулга илгээдэггүй. Resolver-ийг pool дотор зөөхөд шинж тэмдэг клиентэд хүрэхгүйгээр алга болно.

Шинж тэмдэг нь илгээсэн хаягийг заана

Зөвхөн зарим платформ бүтэлгүйтвэл туннель болон нэвтрэх мэдээлэл бараг лавтай зөв, учир нь тэдгээр нь нийтлэг. Ялгаа нь клиент бүр хүлээн авсан тохиргооны ачааллыг, дотоод DNS серверийг оролцуулан, хэрхэн хэрэглэхэд байна. Хаягийг хүлээн авч, гэхдээ асуулгыг туннелийн гадна чиглүүлдэг клиент харж болох ч ашиглаж чадахгүй resolver-тай үлддэг.

Нийтийн хаяг бол ерийн сонголт, учир нь администраторын аль хэдийн мэддэг цор ганц хаяг нь тэр. Энэ нь мөн туннелийн өөрийн префиксээс гадуур байх баталгаатай цор ганц хаяг бөгөөд яг энэ шинж чанар Apple клиентүүдийг эвддэг.

Ямар нэг зүйлийг өөрчлөхөөс өмнө утгыг хараарай. Илгээсэн resolver нь серверийн WAN хаяг бол асуудлын хэлбэрийг олсон тул үлдсэн таамаглалыг алгасаж болно. Үүнийг pool-ийн префикстэй харьцуулаарай, учир нь pool дотор боловч түрээсийн хүрээнээс гадуур байрлах хаяг нь засварын яг дүр төрх юм. Тохиргоотой хоёр минут клиент дээр өдөржин пакет барихаас дээр.

Resolver-ийг түрээсийн хүрээнээс салгаж ав

Туннельд resolver нь pool-ийн өөрийн дэд сүлжээний гишүүн байх хаягийн төлөвлөгөө өгөөд, дараа нь тэр хаягийг ямар ч клиентэд түрээслэхгүй байхаар нөөцөл. Энэ жишээнд pool нь 10.180.7.0/24, сервер 10.180.7.1-ийг барьж, түрээсүүд 10.180.7.2-оос эхэлдэг.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Pool-ийн префикс болон resolver нэг дэд сүлжээг хуваалцдаг тул туннелийн урсгалыг аль хэдийн зөөдөг зам нь асуулгыг ч зөөнө. Яг энэ нэг шинж чанар засварыг клиентүүдийн хооронд зөөх боломжтой болгодог. swanctl тохиргоонд мөн эдгээр хоёр баримт нь ipsec.conf синтакс дотор биш, pool-ийн тодорхойлолт болон холболт дээрх DNS тохиргоо болж гарч ирдэг.

Серверт үүнд шинэ физик интерфейс хэрэггүй. 10.180.7.1-ийг loopback интерфейс дээр нэмэхэд resolver холбогдож, хариулах боломжтой, учир нь клиентүүд аль хэдийн байгаа pool-ийн замаар түүнд хүрдэг. Хаягийг түрээсийн хүрээнээс гадуур байлгаж, ямар ч клиент санамсаргүйгээр авахгүй байх болтугай. Хэрэв pool-ыг гадаад DHCP эсвэл RADIUS үйлчилгээ удирддаг бол хаягийг тэнд ч нөөцөл, эс бөгөөс хамгийн түрүүнд асуусан клиент үүнийг авна.

Resolver-ийг холбож, 53 портыг хаа

Хаяг хуваарилах нь түүн дээр сонсохтой ижил биш. Зөвхөн LAN хаяг дээр сонсдог resolver нь pool-ийн хаяг руу илгээсэн асуулгыг татгалзах эсвэл үл тоомсорлож, клиент чиглүүлэлтийн алдаа мэт харагдах таймаут хардаг.

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

Энэ unbound хэсэг нь туннелийн pool-оос ирсэн асуулгыг хүлээн авч, бусад бүгдийг татгалздаг бөгөөд энэ нь ихэнх корпорацийн resolver-үүдийн хүсдэг бодлого юм. Хэрэв ижил инстанц LAN клиентүүдэд ч хариулдаг бол сонсогчийг бүх эх сурвалж руу өргөтгөхийн оронд LAN префиксыг тодорхой нэмээрэй.

Дараа нь галт ханын дүрмүүд resolver-ийн өөрийн хандалтын хяналттай нийцэх ёстой. Pool-оос 53 портыг хүлээн авч, бусад бүх газраас хая, гэхдээ эхлээд гинжин хэлхээний дарааллыг шалгаарай.

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

Өмнөх, илүү өргөн хүлээн авах дүрэм сүүлийн хоёр мөрийг чимэглэл болгож, resolver интернэтээс хүрэх боломжтой хэвээр үлддэг. Зориулсан дараалладаа итгэхийн оронд тоолууртайгаар бодит дүрмийн багцыг уншаарай. Өөр бодлого, өөрөөр хэлбэл нийтийн хаягийг илгээж, аль ч эх сурвалжаас асуулгыг зөвшөөрөх нь олон клиентэд ажилладаг боловч resolver-ийг интернэтэд гаргаж, өөрийн хурдны хязгаарлалт, хяналт шаарддаг.

Клиент үнэхээр юу хүлээн авсныг шалга

Эхлээд серверийн харц, дараа нь клиентийн харцыг шалга, учир нь хоёулаа мэдээлэлтэйгээр зөрдөг. Pool-ийн жагсаалт аль хаяг түрээслэгдсэнийг харуулж, аюулгүй байдлын холбоодын жагсаалт холболт хүлээгдэж буй таних тэмдэгтэй байгаа эсэхийг харуулна.

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

Шууд асуулга нь resolver pool-ийн хаяг дээр түүнд хүрч чадах хостод хариулж байгааг нотолно. Энэ нь Mac яг тэр серверийг сонгосныг нотлохгүй. macOS дээр scutil --dns resolver-үүдийг хамрах хүрээтэй үйлчилгээ бүрээр жагсаадаг бөгөөд хураангуй панелаас илүү мэдээлэлтэй; Windows дээр Get-DnsClientServerAddress туннелийн адаптер илгээсэн утгыг хүлээн авсан эсэхийг харуулна.

Хэрэв клиент pool-ийн хаягийг харуулж, асуулгууд таймаут хэвээр байвал, буруу нь туннелийн зам эсвэл галт ханын гинжин хэлхээ. Ямар ч resolver мэдээлдэггүй клиент нь тохиргооны ачаал эзгүй ирсэн гэсэн үг тул сүлжээнд биш, тэр платформ илгээсэн тохиргоог хэрхэн хэрэглэдэг талд хараарай. Өөр зүйлийг өөрчлөхөөс өмнө эдгээр хоёр тохиолдлын алийг нь ажигласнаа бичиж аваарай. Эдгээр хоёр гэмтэл тусламжийн тасалбар дээр ижил харагдаж, эсрэг засварт хүргэдэг.