Mac-ի VPN-ը միանում է մեկ անգամ, ապա ժամկետը լրանում է. մաքրեք IKE դեմոնը

Վերագործարկումից հետո առաջին միացումն աշխատում է։ Դրանից հետո յուրաքանչյուր փորձ կախվում է միացման փուլում և ի վերջո ժամկետը լրանում է, և միակ հուսալի միջոցը ևս մեկ վերագործարկումն է։ Այս օրինաչափությունը պրոֆիլի խնդիր չէ և հավատարմագրերի խնդիր էլ չէ։ Ինչ-որ բան հետին պլանում դեռ պահում է նախորդ փորձի վիճակը, և հաջորդ փորձը բախվում է դրան։

macOS-ում այդ ինչ-որ բանը սովորաբար IKE դեմոնն է։

Օրինաչափությունը՝ մեկ միացում, ապա ժամկետի լրացում

Միացումը, որն աշխատում է ճիշտ մեկ անգամ յուրաքանչյուր բեռնման ընթացքում, ցույց է տալիս վիճակ, որը դիմանում է անջատմանը, բայց ոչ վերագործարկմանը։ Պրոֆիլները դիմանում են երկուսին էլ, ուստի պրոֆիլը փոփոխականը չէ։ Հավատարմագրերը նույնպես դիմանում են երկուսին էլ, եթե սերվերը չկողպի հաշիվը։ Այն, ինչ փոխվում է վերագործարկման ժամանակ, աշխատող դեմոնների հավաքածուն և նրանց պահած սոքեթներն են։

Սա նեղացնում է հետաքննությունը նույնիսկ մեկ մատյան բացելուց առաջ։ Հարցը դառնում է, թե որ պրոցեսն է տիրապետում IKE պորտին և ինչ է կարծում, թե անում է։

Երկու դեմոն, մեկ պորտ

Համակարգը գործարկում է racoon երբ միացումը խոսում է IKE 1 տարբերակով։ Ընթացիկ թողարկումները նաև բերում են iked IKEv2-ի և ավելի նոր IPsec փաթեթի համար։ Երկուսն էլ կարող են զբաղեցնել UDP 500-ը և UDP 4500-ը, և երկուսն էլ կարող են պահել կիսաբաց անվտանգության միավորում այն բանից հետո, երբ միացման փորձը չեղարկվել է գաղտնաբառի հարցման պահին կամ ընդհատվել ցանցի փոփոխությամբ։

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

Գտեք տիրոջը նախքան ինչ-որ բան սպանելը, որովհետև պատասխանը որոշում է, թե որ ծառայությունը կվերագործարկեք և որ մատյանը կկարդաք հետո։

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

Կարդացեք ելքը որպես երկու փաստ՝ որ պրոցեսն է պահում պորտը և արդյոք մեկից ավելին կա։ Նույն սոքեթի համար մրցող երկու IKE դեմոն բացատրում են շատ ընդհատվող վարք, որը թվում է անկայուն սերվեր։

Վերագործարկեք աշխատանքը, ոչ թե պրոցեսը

Հին համակարգերում բավական է սպանել պրոցեսը և թույլ տալ, որ հաջորդ միացումը նորից գործարկի այն։ Ընթացիկ թողարկումներում դեմոնը կառավարվում է launchd-ի կողմից, և միայն պրոցեսին ազդանշան ուղարկելը կարող է աշխատանքը թողնել վիճակում, երբ այն ոչ աշխատում է, ոչ էլ նախատեսված է սկսելու։ Փոխարենը կանգնեցրեք և սկսեք աշխատանքը։

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

Եթե launchd-ը գրառում չունի աշխատանքի մասին, պրոցեսը անունով սպանելը դեռ ստիպում է նոր բանակցություն հաջորդ փորձի ժամանակ։ Փորձարկումը նույնն է երկու դեպքում էլ՝ ոչ մի պրոցես չպետք է պահի պորտը, երբ նորից փորձեք միանալ։ Հաստատեք դա նույն հրամանով lsof փոխարենը ենթադրելու, որ վերագործարկումն աշխատեց։

Ապա միացեք մեկ անգամ և կարդացեք հաճախորդի մատյանը սկզբից։ Բանակցությունը, որն անցնում է 1-ին փուլից և հետո հաղորդում է փոխանցման ձախողում, կրկնում է տեղական սոքեթի խնդիրը; գործընկերոջ կողմից մերժված բանակցություն բոլորովին այլ տոմս է։

Երբ սերվերն է հրաժարվում

Ամեն երկրորդ միացում չէ, որ տեղում ձախողվում է։ Սերվերը կարող է հրաժարվել նոր մուտքից անջատումից հետո որոշակի պատուհանի ընթացքում, և հաճախորդի ժամկետի լրացումը նույն տեսքն ունի, ինչ կախված դեմոնը։ Տարբերակիչը էժան է՝ եթե դեմոնի վերագործարկումը չի օգնում, բայց մեկ այլ հաշիվ անմիջապես միանում է, պատուհանը սերվերի կողմում է, և Mac-ը երբեք խնդիրը չի եղել։

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

Կարդացեք գործընկերոջ մատյանը նախքան հաճախորդը նորից փոխելը։ Մերժումը, քաղաքականության անհամապատասխանությունը և լուռ գցումը երեք տարբեր պատճառներ են, որոնք Mac-ի էկրանին բոլորը նման են «միանում է»։

Հին հաճախորդներ և 64-բիթ միջուկ

Հին Cisco IPSec հաճախորդը բեռնում է միջուկի ընդլայնում, որը կառուցված է 32-բիթ և PowerPC համակարգերի համար։ 64-բիթ միջուկով բեռնված Mac-ում այդ ընդլայնումը չի կարող բեռնվել, և հաճախորդը վաղ ձախողվում է 51 սխալով, որովհետև ընդհանրապես չի հասնում VPN ենթահամակարգին։ Դեմոնի ոչ մի քանակի վերագործարկում չի ուղղի սխալ ճարտարապետությամբ միջուկի ընդլայնումը։

Ընդլայնումը նորից բեռնելը կարող է որոշ ժամանակ աշխատել, ապա նորից ձախողվել հաջորդ բեռնման ժամանակ։ Կայուն պատասխաններն են՝ գործարկել հին միջուկը այնտեղ, որտեղ դեռ աջակցվում է, կամ անցնել համակարգի հետ եկող ներկառուցված հաճախորդին։ Ստուգեք ճարտարապետությունը նախքան երեկոն ծախսելը երրորդ կողմի հաճախորդի վրա, որը չի բեռնվում։

• Վերարտադրեք մեկ անգամ, ապա նախքան պրոֆիլին դիպչելը ստուգեք, թե որ դեմոնն է տիրապետում UDP 500-ին։
• Կարդացեք 1-ին փուլից հետո առաջին ձախողումը՝ փոխանցման սխալը մատնանշում է տեղական սոքեթը։
• Վերագործարկեք launchd աշխատանքը, ոչ միայն պրոցեսը, և հաստատեք, որ պորտն ազատ է։
• Փորձեք երկրորդ հաշիվ՝ սերվերի կողմի վերահաստատման պատուհանը հաճախորդի խափանումից տարանջատելու համար։
• Գրանցեք միջուկի ճարտարապետությունը նախքան հաճախորդին մեղադրելը։

Ճիշտ մեկ անգամ աշխատող VPN-ը վիճակի խնդիր է, քանի դեռ հակառակը չի ապացուցվել։ Դեմոնը մաքրելը ավելի արագ է, քան վերագործարկումը, և պահպանում է մատյանի ապացույցները, որոնք վերագործարկումը կշպրտեր։