OpenVPN TAP macOS-ում. ստուգեք հաճախորդը վրիպազերծումից առաջ

Հին պրոֆիլը հայտնվում է ժամանակակից Mac-ում, հաճախորդը ներմուծում է այն առանց բողոքի, և կապը կտրվում է կամ երբեք երթևեկություն չի անցնում։ Նախքան ամբողջ կեսօրը սերտիֆիկատների վրա ծախսելը, կարդացեք պրոֆիլի սարքի տողը։ Եթե այնտեղ գրված է dev tap, դուք հաճախորդից պահանջում եք Ethernet-ի նման ինտերֆեյս, և macOS-ում այս նստաշրջանների մեծ մասը ավարտվում է հենց այդ պահանջով։

Քայլ 1. հաստատեք, որ պրոֆիլն իսկապես TAP է պահանջում

Պրոֆիլները վերանվանվում են, փաթեթավորվում և նորից արտահանվում, ուստի ստուգեք այն ֆայլը, որն իրոք ներմուծել եք։ Փնտրեք սարքի հրահանգը և ցանկացած include, որը կարող է փոխարինել այն։ Երկու տող արդյունքը լուծում է հարցը շատ դեպքերում։ Երբ հայտնվում են և՛ dev, և՛ dev-type, հաղթում է ավելի ուշ հրահանգը, և դա հենց այն մանրամասնությունն է, որը թաքցնում է պատճենված պրոֆիլը։

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

Եթե ֆայլը պարունակում է dev tap կամ dev tap0, հաճախորդը պետք է իրականացնի TAP ինտերֆեյս։ Եթե այն պարունակում է dev tun, այս հոդվածի մնացած մասը չի կիրառվում, և խափանումը այլ տեղ է։

Գրեք հաճախորդի անունն ու տարբերակը, macOS-ի տարբերակը և այն, թե որտեղից է եկել պրոֆիլը։ Այս երեք փաստերը որոշում են, թե ստորև նշված երկու ուղիներից որն է ընդհանրապես հնարավոր։

Քայլ 2. իմացեք, թե սարքի ռեժիմն իրականում ինչ է փոխում

TUN ինտերֆեյսը փոխանցում է IP փաթեթներ։ Հաճախորդը կարդում և գրում է IP գործընկերոջը հասցեագրված փաթեթներ, և օպերացիոն համակարգը դրանք երթուղավորում է ինչպես ցանկացած այլ ինտերֆեյս։

TAP ինտերֆեյսը փոխանցում է Ethernet շրջանակներ, ներառյալ հեռարձակումը և ARP-ն։ Սա է, որ թույլ է տալիս կամրջով սերվերին DHCP-ով հասցեներ բաժանել, իսկ հաճախորդին՝ բարձրաձայնելով սարքեր գտնել, և դրա համար են որոշ հին լուծումներ կախված դրանից։

Գինը այն է, որ TAP-ին պետք է վարորդ, որը համակարգին ներկայացնում է Ethernet ինտերֆեյս։ Apple-ը դադարեցրել է միջուկի ընդլայնման մոդելը, որի վրա հիմնված էին Mac-ի հին TAP վարորդները, և դրա փոխարինող API-ն կախարդական կերպով չի հայտնվում այն հաճախորդներում, որոնք երբեք չեն թարմացվել այն օգտագործելու համար։ Հարթակի հնարավորությունը և առաքված արտադրանքը տարբեր բաներ են։

Քայլ 3. ընտրեք համատեղելի հաճախորդի և միգրացիայի միջև

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

Երկրորդը ծառայությունը TUN-ի տեղափոխելն է, ինչը սերվերի փոփոխություն է նույնքան, որքան հաճախորդի։ Դրա համար պետք են երթուղավորված տոպոլոգիա, հասցեների լողավազան, հեռավոր ցանցերի համար մղված երթուղիներ և վերադարձի ուղի այդ ցանցերից դեպի լողավազան։

Ինչ չի աշխատում, դա ձեր տեղական պատճենում tap-ը tun-ով փոխարինելն ու հույս դնելն է։ Սերվերը դեռ կամուրջ է կազմում, հաճախորդը հիմա IP է խոսում, և ոչինչ չի համընկնում։

Քայլ 4. փաստերը հավաքեք նախքան աշխատող ծառայությունը փոխելը

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

Երեք հարց տվեք դարպասի տիրոջը։ Սերվերն աշխատում է կամրջով, թե երթուղավորված տոպոլոգիայով։ Ո՞ր հեռավոր նախածանցները պետք է հասանելի լինեն։ Եվ արդյոք կոնֆիգուրացիայի փոփոխության համար սպասարկման պատուհան կա, թե՞ ակնկալվում է, որ այն կաշխատի առանց սերվերին դիպչելու։

Այդ հարցերի պատասխանները որոշում են՝ այսօր կեսօրին լուծում եք հաճախորդի խնդիր, թե՞ հաջորդ շաբաթ ցանցի փոփոխություն եք պլանավորում։

Քայլ 5. ստուգեք միգրացիան երկու ծայրերից

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

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

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

Երբ դեռ չի ստացվում, կարդացեք առաջին սխալը

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

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