Մշտական երթուղիներ Mac VPN-ի համար՝ networksetup, թե՞ միացման hook:
Յուրաքանչյուր վերամիացումից հետո մուտքագրվող երթուղին քաղաքականություն չէ։ Որոշեք՝ նախածանցը պատկանում է VPN ծառայությանը, ժամանակավոր փորձարկմանը, թե hook-ի՝ միայն բանակցությունից հետո հայտնի հասցեների համար։
Յուրաքանչյուր միացումից հետո մուտքագրվող երթուղին լուծում է պահը, ոչ շաբաթը։ macOS-ում տեւական ընտրությունը սովորաբար VPN ծառայության հետ պահվող նախածանցն է, քանի որ ծառայությունը վերատեղադրում է այն ամեն միացման ժամանակ եւ հեռացնում, երբ ծառայությունն անջատված է։ Այլընտրանքներն են ժամանակավոր route add՝ փորձարկման համար, եւ միացման hook՝ միայն բանակցությունից հետո հայտնի հասցեների համար։
Որոշեք՝ երթուղին պատկանում է ծառայությանը, թե նստաշրջանին
Հարցրեք՝ ինչից է կախված նախածանցը։ Եթե դա բնիկ VPN ծառայության հետեւում գտնվող ֆիքսված մասնավոր ցանց է, երթուղին պատկանում է այդ ծառայությանը։ Եթե այն կախված է գործընկերոջ հասցեից, որը փոխվում է յուրաքանչյուր միացման ժամանակ, hook-ը կամ վիճակով ղեկավարվող աշխատանքը կարող է ավելի լավ սեփականատեր լինել։ Եթե դուք ստուգում եք ուղին միայն հաջորդ հինգ րոպեների համար, ժամանակավոր երթուղին բավարար է։
Ծառայությանը կապված երթուղին ունի ամենամաքուր կյանքի ցիկլը։ Այն հայտնվում է ծառայության հետ եւ անհետանում, երբ ծառայությունը միացված չէ, ուստի չի կարող ավելի երկար ապրել, քան այն թունելը, որին ցույց է տալիս։ Այդ հատկությունը արժե ավելի, քան մեկ տողանոց հրամանի հարմարավետությունը։
Նստաշրջանին կապված երթուղին պատկանում է ինտերֆեյսին, եւ այդ համարը փոխվում է առանց ծանուցման։ Վերամիացումը կարող է թունելին տալ այլ utun անուն, քան օգտագործել էր նախորդ նստաշրջանը, ինչը կոշտ կոդավորված հրամանը դարձնում է երթուղի, որը ոչ մի տեղ չի ցույց տալիս կամ, ավելի վատ, այլ թունելի։
Կարդացեք ընթացիկ երթուղու եւ ծառայության վիճակը
Սկսեք այն անուններից, որոնք համակարգն իրականում օգտագործում է։ Ցանցի կարգավորումներում ծառայության անունը ներքեւի հրամանների նույնացուցիչն է, եւ ընթացիկ երթուղիների աղյուսակը ցույց է տալիս, թե ինչ է տեղադրել միացված հաճախորդը։ Կարդացեք երկուսն էլ, մինչ թունելը միացված է։
scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5
Այդ որոնումը ցույց է տալիս, թե միջուկը այս պահին այս հասցեի համար որ դարպաս եւ ինտերֆեյս կընտրեր։ Եթե այն արդեն ընտրում է թունելը, նախածանցը ծածկված է, եւ նոր երթուղին ավելորդ կլիներ։ Եթե այն ընտրում է տեղական երթուղիչը, թունելին պակասում է այդ նախածանցը։
Միացված ժամանակ նշեք գործընկերոջ հասցեն։ Այն դառնում է դարպասի արժեքը ծառայությանը կապված երթուղու մեջ, եւ սովորաբար թունելի լռելյայն երթուղու համար ցուցադրվող նպատակակետն է netstat -rn-ում։
Պահեք նախածանցը networksetup-ով
networksetup գործիքը լրացուցիչ երթուղիներ է կցում ցանցային ծառայությանը։ OfficeVPN անունով ծառայության եւ թունելի գործընկերոջ միջոցով հասանելի մասնավոր նախածանցի համար ձեւը հետեւյալն է՝
sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN
Ծառայության անունից հետո յուրաքանչյուր եռյակ տալիս է նպատակակետ, դրա ցանցային դիմակը եւ թունելի գործընկերոջը՝ որպես դարպաս։ Մեկ կանչը կարող է կրել մի քանի նախածանց, իսկ դատարկ կանչը մաքրում է պահված ցանկը։ Ընթերցիչը ստուգման քայլն է. եթե ցանկը դատարկ է, կարգավորումը չի կիրառվել այն ծառայության վրա, որը դուք մտածում եք։
Դարպասը պետք է լինի թունելի գործընկերը, ոչ թե ֆիզիկական երթուղիչը։ Տեղական դարպասը նշող երթուղին մասնավոր նախածանցն ուղարկում է ֆիզիկական ինտերֆեյսով դուրս, ինչը սկզբնական ձախողումն է լրացուցիչ քայլերով։ Հնացած գործընկերը ամենատարածված պատճառն է, թե ինչու ճիշտ տեսք ունեցող երթուղին երբեք երթեւեկություն չի տեղափոխում։ Կրկին կարդացեք գործընկերոջը միացված վիճակից՝ հին գրառումից հասցե պատճենելու փոխարեն։
Օգտագործեք route add միայն փորձարկման համար
Ուղիղ երթուղին օգտակար է ապացուցելու, որ նախածանցն աշխատում է, նախքան այն մշտական դարձնելը։ Ինտերֆեյսի ձեւը խուսափում է դարպասի որոնումից՝
sudo route -n add -net 10.20.0.0/16 -interface utun4
Երթուղին անհետանում է հաջորդ վերամիացման ժամանակ եւ կախված է այն ինտերֆեյսի համարից, որը գոյություն ունի այսօր։ Դա այն դարձնում է ախտորոշում, ոչ տեղակայում։ Եթե փորձարկումն աշխատում է, իսկ ծառայությանը կապված երթուղին՝ ոչ, նախ համեմատեք դարպասի արժեքը. հենց այդ դաշտն է ամենից հաճախ սխալ։
Զգույշ եղեք խորհուրդներից, որոնք փոխարինում են VPN-ի լռելյայն երթուղին՝ բաժանումը պարտադրելու համար։ Լիարժեք թունել պարտադրող հաճախորդը կարող է վերամիացումից կամ քաղաքականության թարմացումից հետո վերատեղադրել իր երթուղիները, ուստի ձեռքով փոփոխությունը լուռ չեղարկվում է։ Մի քանի մասնավոր նախածանց երթուղավորման խնդիր է, իսկ ամբողջ ինտերնետ երթեւեկությունը տեղական պահելը լիարժեք թունելի քաղաքականության դեմ որոշում է սերվերի կողմից։
Ընտրեք hook միայն այն ժամանակ, երբ հասցեն բանակցվում է
PPP-ի վրա հիմնված կապերի համար, օրինակ՝ L2TP, macOS-ը կատարում է /etc/ppp/ip-up, հենց որ կապը հաստատվում է։ Սկրիպտը ստանում է ինտերֆեյսի անունը եւ բանակցված տեղական ու հեռավոր հասցեները, ուստի այն կարող է ավելացնել երթուղի, որը կախված է սերվերի կողմից նշանակված գործընկերոջից։ Սա հենց այն դեպքն է, որը ֆիքսված ծառայության երթուղին չի կարող արտահայտել։
Հնարավոր է, որ IKEv2-ը եւ մատակարարների հաճախորդները ընդհանրապես չօգտագործեն այդ PPP ուղին, ինչը նշանակում է, որ սկրիպտը կարող է լուռ մնալ ամբողջ նստաշրջանի ընթացքում։ Երբ դա տեղի է ունենում, launchd աշխատանքը, որը հարցնում է scutil --nc status-ը եւ արձագանքում վիճակի փոփոխությանը, համարժեք մեխանիզմն է՝ փոքր ուշացումով։
Ինչ hook էլ օգտագործեք, դարձրեք այն իդեմպոտենտ եւ թույլ տվեք հեռացնել միայն իր ստեղծած երթուղիները։ Սկրիպտը, որը ջնջում է թունելը հիշատակող բոլոր երթուղիները, ի վերջո կջնջի այն երթուղին, որը VPN սերվերը հասանելի է պահում, եւ կապը կընկնի հենց որ հաջողվի։
Ավարտեք՝ ստուգելով մասնավոր նպատակակետը, սովորական զննարկումը եւ վերամիացման կամ քնի ցիկլը։ Այնուհետեւ ստուգեք scutil --dns-ը, քանի որ անունների լուծումը առանձին քաղաքականություն է, եւ աշխատող երթուղին չի ապացուցում, որ մասնավոր անունները լուծվում են։