Apple VPN On Demand-ийн домэйн дүрмүүд туннелийг хэрхэн эхлүүлдэг

Та нэг дотоод нэрийг хүсэх үед туннель нээгдэж, дараагийн апп-д яг л тэгтлээ хэрэгтэй үед хаалттай хэвээр үлддэг. Энэ нь апп-ын алдаа биш; энэ нь домэйн дүрмийн хэлбэр юм. Apple-ийн on-demand тохиргоо холболт үүсгэх нөхцлийг тодорхойлдог бөгөөд эдгээр нөхцлийн домэйн хэлбэр нь нэг ч пакет хөдлөхөөс өмнө системийн шийдэгчээс асуулт асуудаг. Хоёр асуулт байнга холилддог: туннель хэзээ өргөгдөх ёстой, туннель оршин байгаа үед юу зөөдөг. Эхнийх нь триггер, хоёр дахь нь маршрут ба шийдэгчийн бодлого бөгөөд нэг профайл ихэвчлэн хоёуланг нь нэг payload-д тохируулдаг тул зөв домэйн дүрэм ч таныг буруу сүлжээнд үлдээж болно.

Триггер ба урсгалын сонголт өөр өөр давхаргад байдаг

On-demand дүрэм нь VPN payload-ын on-demand толь бичигт амьдардаг: эрэмбэлсэн дүрмүүдийн жагсаалт, тус бүр үйлдэл болон тохирлын нөхцлийн багцтай. Холболт өөрчлөгдөх үед эсвэл ямар нэг зүйл сүлжээнд хүрэхийг оролдох үед систем тэдгээрийг үнэлж, үйлдэл нь туннелийг өргөх, үнэлэх, салгах эсвэл үл тоомсорлохыг шийддэг. Энэ бүгд платформын сүлжээний давхаргад, таны апп-д socket авахаас өмнө болдог.

Үүний дараа ирэх нь тусдаа түлхүүрүүдийн бүлэг: туннелийн IPv4 ба IPv6 тохиргоо, түүний оруулсан болон хассан маршрутууд, DNS серверийн хаягууд, мөн iOS ба iPadOS дээр аль апп-ууд туннель ашиглаж болохыг тодорхойлдог апп тус бүрийн зураглал. Профайл өргөн триггерийг нарийн маршруттай, эсвэл нарийн триггерийг өгөгдмөл маршруттай хослуулж болно. Зөвхөн нэг талыг уншаарай, нөгөө тал нь гэмтэл мэт харагдана.

Надад дотоод домэйны доор ямар нэг зүйл хүсэгдэх бүрт холбогддог, гэхдээ туннель руу зөвхөн нэг /16 чиглүүлдэг лабораторийн профайл байна. Энэ нь өөрийн payload-д бичсэнийг яг хийдэг бөгөөд энэ нь тасалбар үүсгэдэг профайлын төрөл юм: хүмүүс холбогдсон туннель гэдэг нь тэдний урсгал дотор нь байна гэж боддог.

Домэйн дүрэм шийдэгчээс юу асуудаг

Дүрмийн домэйн хэлбэрийг ихэвчлэн connect-if-needed гэж нэрлэдэг бөгөөд энэ нь пакетын payload-ыг шалгадаггүй, URL-ыг ажигладаггүй. Нэр шийдэгдэх үед систем түүнийг дүрэм дэх домэйнүүдтэй харьцуулж, тохирвол тухайн нэрийг туннелийн өгдөг DNS серверүүдээр шийдэж болох эсэхийг асуудаг. Туннелийн шийдэгч хариулбал нэрийг дотоод гэж үзэж холболт эхэлдэг. Харин орон нутгийн шийдэгч хариулбал нэрийг гадаад гэж үзэж туннель гарч ирэхгүй. Apple-ийн байршуулалтын тойм үүнийг сүлжээ илрүүлэх, дараа нь холболт үнэлэх гэж тайлбарладаг.

Хоёр үр дагавар гарна. Профайл туннелийн дотор DNS серверүүдийг нэрлэх ёстой; туннелийн шийдэгчгүй домэйн дүрэмд харьцуулах зүйл байхгүй тул үнэлгээ таны хүлээж буй тохирлыг өгч чадахгүй. Мөн хайлт системийн шийдэгчид хүрэх ёстой. Өөрийн шифрлэсэн DNS-ийг ажиллуулдаг апп эсвэл хөтөч, орон нутгаас хариулдаг өргөтгөл, эсвэл шууд хаяг руу холболт нь дүрмийн хүлээж байсан нэрийн шийдлийг хэзээ ч үүсгэхгүй. Миний хамгийн урт үдээс хойшхийн нэг туннелийн өмнөх клиент DNS over HTTPS ашиглаж байгааг олж мэдэхэд дууссан.

Кэш нь триггерийг ч арилгадаг. Кэшэд байгаа нэрэнд туннель эхлүүлэх байсан шалгалтгүйгээр хариулж болох тул өчигдөр ажилласан дүрэм дахин ачаалсны дараа эсвэл туннель хэсэг хугацаанд өргөгдсөний дараа бүтэлгүйтдэг. macOS дээр sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder төлвийг сэргээдэг; iOS дээр нисэх онгоцны горимыг асаах, унтраах эсвэл төхөөрөмжийг дахин ачаалах нь харьцуулахуйц цэвэр эхлэл өгдөг.

Тохирлын хамрах хүрээ: нэрс, апп-ууд ба сүлжээнүүд

Домэйн тохирол нь хэд хэдэн төрлийн нэг юм. Дүрэм интерфэйсийн төрөл (Wi-Fi, үүрэн, Ethernet) болон тодорхой SSID-тай ч тохирч болох бөгөөд апп тус бүр эсвэл Safari домэйны бичлэгүүд туннелийг нэг ажлын урсгалтай холбодог. Энэ холбоо нь зөвхөн нэг апп бусад бүхнээс өөрөөр ажилладаг хачирхалтай туршлагыг тайлбарладаг: бусад апп-ууд туннелийн хамрах хүрээнээс гадна байдаг тул туннелийн дүрс холбогдсон гэж хэлсэн ч тэд орон нутгийн замыг үргэлжлүүлэн ашигладаг.

Дараалал хүмүүсийн хүлээж байгаагаас илүү чухал. Дүрмүүд дараалан үнэлэгдэж, хамгийн түрүүнд тохирсон нь үйлдлийг өгдөг тул нарийн домэйн дүрмийн дээр тавьсан өргөн «аль ч Wi-Fi-д холбогдох» дүрэм чимээгүй ялаад домэйн дүрмийг шалгах боломжгүй болгоно. Домэйнуудын жагсаалтыг дахин бичихийн өмнө өмнөх ямар ч дүрэм аль хэдийн тохироогүй гэдгийг баталгаажуулаарай.

Тиймээс always-on нь зөвхөн илүү хатуу on-demand дүрэм биш юм. always-on-ыг хэрэгжүүлэх нь тусдаа байршуулалтын горим бөгөөд өөрийн хяналт, удирдлагын шаардлагатай; энэ нь нэрэнд хариу үйлдэл хийхийн оронд туннелийг нээлттэй барина. Хэрэв танд хэзээ ч унахгүй туннель хэрэгтэй бол домэйн дүрэм буруу хэрэгсэл юм.

Эвдэрсэн дүрэм мэт харагдах гэмтлүүд

Домэйн дүрэм ажиллахгүй байна гэсэн мэдээллийн ихэнх нь таван газрын нэгэнд унадаг бөгөөд зөвхөн сүүлийнх нь дүрмийн текст юм.

Captive порталууд өөрийн гэсэн мөрөнд хүртэх ёстой, учир нь зочид буудал, нисэх онгоцны буудлын Wi-Fi нь дүрмээс хамаардаг хайлтыг яг таг таслан зогсоодог. Портал төхөөрөмжийг оруулах хүртэл туннелийн DNS серверт хүрэх боломжгүй, шалгалт бүтэлгүйтэж, гэмтэл нь буруу бичигдсэн домэйн мэт харагдана. Баталгаажуулалт нь өөр нэг чимээгүй тохиолдол: дүрэм ажиллаж, туннель холбоглож эхэлж болох боловч холболт нь хугацаа дууссан гэрчилгээ эсвэл өөр дэлгэц дээр гарч ирсэн хүсэлтээр үхдэг.

IPv6 нь буруу оношлоход хялбар хувилбарыг үүсгэдэг. Хоёр хаягийн гэр бүлтэй нэрэнд эхлээд AAAA бичлэгээс хариулж болох бөгөөд туннелийн маршрутын жагсаалтад зөвхөн IPv4 байдаг. Нэг хөтөч амжилттай, нөгөө нь бүтэлгүйтдэг, домэйнуудын жагсаалт бүрэн гэмгүй.

Бодит хүсэлтээр, энэ дарааллаар туршина уу

Таамаглахаас өмнө бодлогыг уншина уу. macOS дээр sudo profiles show -type configuration VPN payload-ыг оруулаад суулгасан профайлуудыг хэвлэдэг, scutil --nc list үйлчилгээний төлвийг харуулдаг, scutil --nc show <service> системийн ашигладаг on-demand толь бичгийг хэвлэдэг. Удирдлагатай iPhone эсвэл iPad дээр ижил payload удирдлагын консол эсвэл MDM тайлангаас ирдэг. Сүлжээний бүртгэлүүд macOS дээр log stream --predicate 'subsystem == "com.apple.networkextension"'-аар, утас холбогдсон үед төхөөрөмжийн консолоор дамжин боломжтой.

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

Туннель өргөгдсөний дараа хоёр давхаргыг тусад нь шалгана уу. netstat -rn -f inet ба netstat -rn -f inet6 префикс бүр хаашаа чиглэж байгааг харуулна, scutil --dns шийдэгчдийн дараалал ба аль интерфэйс аль шийдэгчийг эзэмшиж байгааг харуулна, nettop -m route аль интерфэйс байтуудыг зөөснийг харуулна. Туннель өргөгдсөн, шийдэгч зөв боловч нөөц нь бүтэлгүйтсээр байвал дүрмийг засварыг зогсоож, серверийн талын зөвшөөрөл болон буцах маршрутыг шалгана уу.

Дүрэм өөр хүнийх байх үед

Салгасны дараа туннель дахин гарч ирвэл дүрэм нь ихэвчлэн апп-д биш, профайлд хамаардаг: MDM-ээр илгээсэн тохиргоо, үлдсэн хувийн профайл эсвэл өөр клиентийн суулгасан профайл. sudo profiles show -type configuration болон on-demand түлхүүрүүдийн хайлт үүнийг нарийсгаж, устгах зам нь профайл бөгөөд цэсний мөрний унтраалга биш. Үйлчилгээний бичлэг эсвэл апп-ыг устгахад дүрэм үлдэж, дараагийн суулгалт түүнийг дахин өвлөнө.

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

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