Always On VPN թե VPN On Demand iPhone-ում՝ ինչ տեղակայել

Երկու 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 անվտանգության ուղեցույցը հղումն է այն բանի, ինչ պլատֆորմը փաստաթղթավորում է այս քաղաքականությունների մասին, և արժե կարդալ այն նախքան կոնֆիգուրացիա գրելը, որը պնդում է ավելին, քան պլատֆորմը։

Պահեք առաջին քայլի երեք փաստերը կանոնների հավաքածուի և փորձարկումների արդյունքների կողքին։ Երբ հաջորդ մարդը հարցնի, թե ինչու հեռախոսը մի ցանցում միանում է, իսկ մյուսում՝ ոչ, այս նշումները պատասխանում են մեկ րոպեում՝ վերակառուցելու փոխարեն։