OpenVPN-ը դեռ հին երթուղինե՞ր է մղում. ստուգեք՝ ինչ է բեռնել
Կամ սերվերը երբեք չի կարդացել ձեր փոփոխությունը, կամ հաճախորդը երբեք չի տեղադրել ստացածը։ Համեմատեք ընթացող պրոցեսը, մղված ցանկը և վերադարձի երթուղին։
Ավելացնում եք երթուղի, վերագործարկում ծառայությունը, նորից միանում, և հաճախորդի աղյուսակը ճիշտ նույնն է, ինչ առաջ։ Երկու տարբեր բան կարող է ճիշտ լինել՝ սերվերը չի բեռնել ձեր փոփոխությունը, կամ հաճախորդը չի տեղադրել ստացածը։ Բացի ախտանշից նրանց միջև ոչինչ ընդհանուր չկա, ուստի առաջին քայլը պարզելն է, թե որ դեպքն ունեք։
Ստորև համեմատությունը գնում է պրոցեսից դուրս, քանի որ պրոցեսն է միակ հեղինակությունը, թե որ ֆայլն է գործում։
Ֆայլը, որը խմբագրել եք, և ֆայլը, որը կարդում է պրոցեսը
Սկսեք unit-ից և նրա ստեղծած հրամանի տողից։ systemd հոսթի վրա systemctl cat openvpn@server-ը տպում է ExecStart տողը, իսկ instance unit-ը սովորաբար իր կոնֆիգուրացիայի ուղին ածանցում է instance-ի անունից, ուստի openvpn@office անունով գործարկված դեմոնը կարդում է այլ ֆայլ, քան openvpn@server անունով գործարկվածը։ Համեմատեք դա ընթացող պրոցեսի argv-ի հետ։ Կոնֆիգուրացիայի կառավարման գործիքը ավելացնում է փոփոխությունը կորցնելու ևս մեկ եղանակ՝ այն կարող է ճիշտ ֆայլ գրել մի տեղ, որը unit-ը երբեք չի նշում, և այդ ժամանակ հաջող տեղակայումը ոչինչ չի թվում։
Ժամանակի դրոշմանիշերը արագ լուծում են՝ եթե ֆայլը նոր է պրոցեսի մեկնարկի ժամանակից, պրոցեսը չէր կարող կարդալ այն։ Երթուղիչի firmware-ը ավելացնում է երրորդ դեպքը, քանի որ շատ մոդելներ իրենց կարգավորումները պահում են flash-ում և բեռնման ընթացքում նորից կառուցում կոնֆիգուրացիան, ինչը սկավառակի ֆայլի խմբագրումը դարձնում է բոլորովին սխալ շերտ։
Ինչ է մղում սերվերը և ինչ է տեղադրում հաճախորդը
Մղված երթուղին պետք է անցնի երկու զտիչ։ Սերվերի վրա այն պետք է լինի բեռնված կոնֆիգուրացիայում, ոչ մեկնաբանված բլոկում և ոչ էլ հաճախորդին հատուկ ֆայլում, որի անունը չի համընկնում։ Հաճախորդի վրա pull-ը պետք է միացված լինի, և ոչ մի pull-filter չպետք է դեն նետի այդ ընտրանքը։ Միացեք verbosity 4-ով և կարդացեք մղված ընտրանքները, որոնց մասին հայտնում է հաճախորդը՝ եթե երթուղին այդ ցանկում է, սերվերն արել է իր գործը, և հաճախորդն է ընտրում չտեղադրել այն։
Հաճախորդին հատուկ ֆայլերը հաճախակի շփոթության աղբյուր են։ Վկայագրի common name-ով անվանված ֆայլը ընտրանքներ է մղում միայն այդ հաճախորդին, և մեկ նշանի տարբերությունը լուռ կանգնեցնում է մղումը՝ առանց սխալի ոչ մի կողմում։ Սերվերը գրանցում է այն common name-ը, որը տեսել է միացման պահին, ուստի այդ արժեքը համեմատեք ֆայլի անվան հետ, ոչ թե նրա հետ, ինչ դուք կարծում եք հաճախորդի անունն է։
Մղված նախածանցը և վերադարձի երթուղին տարբեր խնդիրներ են
Այն հաճախորդը, որը դիտավորյալ անտեսում է redirect-gateway-ը՝ պահպանելու իր տեղական ինտերնետ ուղին, ստեղծում է երկրորդ՝ անկապ բացվածք։ Սերվերի զոնդերը հասնում են թունելի հասցեին, իսկ պատասխանները երբեք չեն հասնում, քանի որ սերվերի թունելի IP-ին ուղղված պատասխանը երթուղավորվում է հաճախորդի սովորական լռելյայն դարպասով։ Մղված ենթացանցի երթուղին այստեղ մեղավոր չէ՝ բացակայում է այն երթուղին, որը սերվերի թունելային ցանցի թրաֆիկը հետ է ուղարկում թունելային սարքով։
Այդ երթուղին հաճախորդի վրա ավելացնելը շտկում է սերվերի նախաձեռնած զոնդերի պատասխանները։ Այն չի փոխարինում մղված ենթացանցի երթուղուն, և հակառակն էլ ճիշտ է, քանի որ երկուսը նկարագրում են շարժման հակառակ ուղղություններ։
Համեմատեք աղյուսակները երկու ծայրերում
Ցանկացած փոփոխությունից հետո նորից միացեք և կարդացեք հաճախորդի աղյուսակը մղված նախածանցի և թունելային սարքի համար։ Այնուհետև փորձարկեք երկու ուղղությամբ՝ հաճախորդից դեպի մղված ենթացանցի հոսթ, և այդ հոսթից հետ դեպի հաճախորդ։ Գոյություն ունեցող, բայց թրաֆիկ չկրող երթուղին նշանակում է երեքից մեկը՝ հեռավոր կողմը չի փոխանցում, firewall-ը գցում է հոսքը, կամ պատասխանը վերադարձի ճանապարհ չունի։
Երեք նույնացուցիչ պահեք միասին՝ կոնֆիգուրացիայի ուղին, unit-ի կամ instance-ի անունը, և այն հաճախորդի ինքնությունը, որով փորձարկել եք։
Այս երեքը հաջորդ դեպքը դարձնում են հինգ րոպեի ստուգում՝ կրկնվող հետաքննության փոխարեն, և հենց դրանք են պետք գործընկերոջը, երբ թունելը դառնում է ուրիշի խնդիրը։
Վերագործարկումը վերապրած երթուղու խնդիրը հաճախ ամենևին էլ երթուղավորման խնդիր չէ՝ անսարքությունը գտնվում է ձեր անդադար կարդացած աղյուսակից վերև։