iPhone Always On VPN. երկու թունել կարող են կիսել մեկ վիրտուալ IP
Ինտերֆեյսով Always On թունելները ձախողված rekey չեն։ Համեմատեք երկու SA-ները սերվերի վրա, ապա որոշեք՝ արդյոք մեկ ինքնությունը կարող է պահել երկու ներքին հասցե։
Կառավարվող Always On պրոֆիլով հսկվող iPhone-ում հեռախոսը թունել է պահում յուրաքանչյուր ակտիվ IP ինտերֆեյսի համար, ուստի բջջայինը և Wi-Fi-ն յուրաքանչյուրը ստանում է իրենը։ Այնուհետև սերվերը ցուցադրում է երկու IKE անվտանգության ասոցիացիա մեկ սարքի համար, հաճախ կիսելով մեկ վիրտուալ հասցե, և առաջին ազդակն է դա անվանել rekey հանգույց և սկսել փոխել ժամաչափերը։ Այդ ազդակը սովորաբար սխալ է։ Անցեք ստորև բերված քայլերը այն հերթականությամբ, որով ապացույցները հայտնվում են սերվերի վրա, և թողեք հեռախոսի կարգավորումները հանգիստ, քանի դեռ սերվերը չի ասել, թե որ դեպքն ունեք։
Սկսեք այն երկու տողերից, որոնք սերվերն արդեն ունի
Թվարկեք ասոցիացիաները swanctl --list-sas-ով և կարդացեք չորս դաշտ երկու գրառումներում՝ հեռավոր հասցեն, նույնականացված ինքնությունը, հատկացված վիրտուալ IP-ն և ստեղծման ժամանակը։ Մեկ ինքնությամբ և մեկ վիրտուալ IP-ով երկու տարբեր արտաքին հասցեներ այն ձևն է, որով սկսվել է այս հարցը, և արժե այն գրի առնել ցանկացած փոփոխությունից առաջ։ Այնուհետև ստուգեք յուրաքանչյուրին կցված զույգ ասոցիացիաները, որովհետև տրաֆիկի ընտրիչներն են որոշում, թե արդյոք նպատակակետի որոնումը երբևէ կարող է տարբերել երկու թունելները։ Մի քանի վայրկյանում հայտնվող և անհետացող զույգը այլ կենդանի է, քան ժամեր շարունակ ապրող զույգը։
Նախքան եզրակացություն անելը ցանկը դասավորեք ստեղծման ժամանակով։ Արդյունքի մեջ հարևանությունը ոչինչ չի նշանակում, և աղյուսակային ցանկը հենց այդ սխալին է հրավիրում։
Որոշեք, թե որ համընկնումն եք նայում
IKEv2 rekey-ը և make-before-break վերաինքնականացումը դիտավորությամբ կարճ համընկնում են ստեղծում՝ նոր ասոցիացիան հաստատելով հինը ջնջելուց առաջ։ Ժամանակի դրոշմները լուծում են հարցը, որովհետև հին SA-ն, որը անհետանում է նորի հայտնվելուց մեկ-երկու վայրկյան անց, նորացում է, որն անում է իր գործը։ Անկախ ինտերֆեյսային թունելները երբեք այդպես չեն երևում, քանի որ յուրաքանչյուրը պահպանվում է այնքան ժամանակ, քանի դեռ իր ինտերֆեյսը միացված է, և մեկի ջնջումը չի բխում մյուսի ստեղծումից։
Apple-ի կառավարվող Always On վարքը ինտերֆեյսով է, այդ պատճառով հսկվող սարքը կարող է օրինականորեն ավելի զբաղված երևալ, քան ձեռքով կարգավորված պրոֆիլը։ Մատակարարի հավելվածի ավտոմատ միացման անջատիչը նույնը չի նշանակում, և սովորական on-demand կանոնը նույնպես։ Apple-ի տեղակայման ակնարկը նկարագրում է ինտերֆեյսով մոդելը՝ համեմատեք ձեր երկու տողերը դրա հետ նախքան հանգույց ենթադրելը։ Երկու ձևերն էլ սնվում են նույն սերվերային պահոցից, ուստի համընկնումը ձեր միակ վաղ ազդանշանն է։
Տեսեք, թե ինչու է մեկ վիրտուալ հասցեն երկու թունելի համար կոտրում պատասխանները
Հեռախոսին ուղղված պատասխանը հասցեագրվում է ներքին հասցեին, և միջուկն ընտրում է ելքային թունելը ըստ նպատակակետի և քաղաքականության, ոչ ըստ այն ինտերֆեյսի, որն օգտագործել է հեռախոսը։ Նույն վիրտուալ IP-ն պահող և համընկնող քաղաքականություններով երկու միաժամանակյա ասոցիացիաներ երթուղային որոշումը թողնում են առանց ասելու միջոցի, թե որ սեսիային է պատկանում պատասխանը։ Որոշ պատասխաններ սխալ թունել են վերցնում, և հեռախոսը ցույց է տալիս միակողմանի աշխատող կամ Wi-Fi-ի բարձրանալիս մահացող կապ։ Երկու հրամանի ելք ապացուցում են վիճակը՝ swanctl --list-sas ցույց է տալիս նույն վիրտուալ IP-ն երկու SA-ներում, և ip xfrm policy ցույց է տալիս երկու նույնական ընտրիչ։
Հենց այդ ելքերի զույգն եք տեղադրում փոփոխության գրառման մեջ։ Դրանցից ոչ մեկը միայնակ համոզիչ չէ, որովհետև յուրաքանչյուրը կարող է առանձին հավանական թվալ։
Սա սերվերի կողմի հասցեավորում և քաղաքականություն է, ոչ թե հեռախոսի սխալ վարք, և ոչ մի հաճախորդի կարգավորում չի բաժանում երկու նույնական ներքին հասցե։ Պահոցը նույն արժեքը տվել է երկու անգամ, և քաղաքականության տեղադրիչն այն ընդունել է։ Նախքան հաճախորդին մեղադրելը արդյունքը կարդացեք սերվերի կողմից։
Փոխեք պահոցը կամ զուգահեռության մոդելը, ոչ rekey ժամաչափը
swanctl կարգավորումներում եզակիությունը միացման վրա հստակ քաղաքականություն է՝ unique = replace-ը հեռացնում է հին միացումը, երբ նորը հաստատվում է, և unique = keep-ը մերժում է նորեկին։ Երկու արժեքներն էլ գործում են միացումը կարգավորելիս, ոչ դրա ներսի զույգ SA-ների վրա։
connections {
ios-alwayson {
unique = replace
}
}
Ոչ մի արժեք չեզոք չէ ինտերֆեյսային հաճախորդի համար։ keep-ը վերականգնում է կոկիկ կարգավիճակի էկրանը՝ մերժելով երկրորդ թունելը, և կոտրում է կառավարվող ձևավորումը, մինչդեռ replace-ը քանդում է հին թունելը և նույն փոխզիջումն է հակառակ ուղղությամբ։ Եթե իսկապես անհրաժեշտ են երկու թունելները, պահոցի հետնամասը պետք է տարբեր վարձակալություններ տա մեկ ինքնության համար, և նրա վարձակալության բանալին պետք է տարբերի հարցումները։ Ստատիկ ինքնություն-հասցե աղյուսակը սիրով նույն հասցեն երկու անգամ կվերադարձնի և կվերարտադրի սկզբնական խնդիրը ավելի շատ կարգավորումներով։ Նախքան երկրորդ ստատիկ քարտեզագրում ավելացնելը ստուգեք, թե ինչպես է հետնամասը բանալիացնում վարձակալությունները։
Փորձարկեք այն անցումները, որոնք իսկապես տեղադրում եք
Ակտիվ սեսիայով դուրս եկեք Wi-Fi-ի սահմաններից, ապա վերադարձեք, և ստուգեք, որ պատասխանները գալիս են երկու ուղղությամբ։ Արեք դա երկու անգամ, որովհետև երկրորդ անցումն է, որտեղ սովորաբար հայտնվում է հնացած քաղաքականությունը։ Փորձարկեք ծառայությամբ, որը պատասխանում է ձեր բացած միացման վրա, և կրկնեք դուրս գալը, մինչ թունելը տրաֆիկ է կրում, ոչ թե պարապ կանգնած է։ Հեռախոսը, որը կարող է ուղարկել, բայց ոչ ստանալ, ձեռքսեղմման մատյանում առողջ է երևում, իսկ զննարկիչում՝ կոտրված։
Մեկ տողի հասցված կարգավիճակի էկրանը աշխատող ձևավորման ապացույց չէ, միայն ապացույց է, որ մեկ թունելը գնացել է։ Երկու ուղղություններն էլ պետք է աշխատեն, նախքան անցումը կանցնի։ Գրեք, ինչ դիտել եք, համընկնման ստուգման երկու ելքերի հետ միասին, որպեսզի հաջորդ ինժեները կարողանա համեմատել, այլ ոչ թե կրկնել քայլքը։