iPhone дээр Always On VPN ба VPN On Demand: юу байрлуулах вэ

On Demand дүрэм тохирох үед туннель нээдэг; удирдлагатай Always On хяналттай төхөөрөмжид хамрах хүрээг албадан хадгалдаг. Аль нэгийг сонгож, ажиллаж байгааг нотлох гарын авлага.

Хоёр iPhone хоёулаа VPN гэж хэлж болох ч огт өөрөөр ажилладаг. On Demand дүрэм тохирох үед туннель нээдэг бөгөөд хэрэглэгч үүнийг Тохиргооноос унтрааж болно. Удирдлагатай Always On нь хяналттай төхөөрөмж дээр туннель босч чадахгүй мөчид ч хамрах хүрээг албадан хадгална. Хэрэглэгч юу ч хийхгүй үед юу үнэн байх ёстойг асууж сонгоод, дараа нь тогтвортой байдлыг бус шилжилтүүдийг шалгаарай. Доорх алхмууд байрлуулалт үнэхээр бүтэлгүйтдэг дарааллаар явна.

1-р алхам: төхөөрөмж юуг албадан хийж чадахыг тодорхойлох

Always On нь хяналттай төхөөрөмжид зориулсан функц юм. Хэрэв парк хяналтад байхгүй бол хэлэлцүүлэг эхлэхээс өмнө дуусч, ямар ч payload түлхүүр хяналтгүй утсыг албадан болгодоггүй. Хяналтыг удирдлагын талаас болон төхөөрөмжөөс баталгаажуулж, дараа нь профайлыг хэн гарын үсэг зурсныг баталгаажуулна уу.

Утсан дээр: Тохиргоо, дараа нь Ерөнхий, дараа нь VPN болон Төхөөрөмжийн удирдлага. Профайлын бичлэг эзэмшигчийг нэрлэдэг бөгөөд гараар суулгасан хувийн профайл нь удирдлагын үйлчилгээнээс ирсэнээс өөр харагдана. Албадлагыг профайлын нэр эсвэл нийлүүлэгчийн маркетингийн шошгоноос бүү дүгнэ; шошго нь платформын бодлого биш.

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

2-р алхам: функцийн нэрийг бус on-demand дүрмийг унш

On Demand нь дарааллаар үнэлэгдэх дүрмийн жагсаалт юм. Дүрэм бүр үйлдэл болон түүнийг сонгох нөхцлийг нэрлэдэг бөгөөд нөхцөл нь сонирхолтой хэсэг: интерфейсийн төрөл, Wi-Fi SSID, DNS домэйн дагавар эсвэл шалгах URL. Хэзээ ч тохирохгүй дүрмийн багц бол хэзээ ч холбогддоггүй функц юм.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

Бүх массивыг уншаад дүрэм бүрээс хоёр асуулт асуу: энэ нөхцөл энэ парк дээр хэзээ нэгэн цагт үнэн байж чадах уу, ямар ч дүрэм тохирохгүй үед юу болох вэ? Аж ахуйн нэгжийн сүлжээ нэвтрэх цэгийг өөр нэрлэж, SSID-г нэгтгэж, DNS дагаврыг өөрчилдөг бөгөөд эдгээр өөрчлөлт бүр дүрмийг бодит байдлаас чимээгүй салгадаг.

DNS дагаврын нөхцөл нь талбарт хамгийн их алдаатай байдаг, учир нь зочны сүлжээнд утас мэдээлдэг дагавар нь корпорацийн шийдвэрлэгчийн үйлчилдэг дагавар биш. Дүрэмд итгэхээс өмнө төхөөрөмжийн үнэхээр шийддэг нэрийг шалга.

3-р алхам: статик холболтыг бус шилжилтийг шалга

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

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

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

4-р алхам: бүтэлгүйтлийн хоёр хэлбэрийг мэд

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

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

Captive portal хоёрын дунд байдаг: туннель үүсэхээс өмнө холболт хэрэгтэй тул туннель босох хүртэл бүгдийг хаадаг бодлогод порталаар дамжих баримтжуулсан зам хэрэгтэй. Үүнийг загварт шийд, тусламжийн ширээн дээр биш.

5-р алхам: баталгаажуулаад буцаалтыг давт

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

Дараа нь үйлдвэрлэлд хэрэгтэй болохоос өмнө туршилтын төхөөрөмж дээр устгалыг давт. Профайлыг устгах нь төхөөрөмжийг өмнөх төлөвт нь буцаадаг бөгөөд хэр удаан үргэлжлэх, хэрэглэгч юу харахыг мэдэх нь runbook-ийн хэсэг юм. Apple-ийн VPN аюулгүй байдлын гарын авлага нь платформ эдгээр бодлогын талаар юу баримтжуулдгийн лавлагаа бөгөөд платформаас илүү мэдэгдэх тохиргоо бичихээс өмнө унших нь зүйтэй.

Эхний алхмын гурван баримтыг дүрмийн багц болон туршилтын үр дүнгийн дэргэд байлга. Дараагийн хүн утас яагаад нэг сүлжээнд холбогдож нөгөөд холбогдохгүй гэж асуухад эдгээр тэмдэглэл дахин бүтээхийн оронд нэг минутад хариулна.

Холбоотой нийтлэлүүд