Ինչպես մեկ հավելվածը VPN-ով անցկացնել առանց ամբողջ մեքենայի
Ոչ մի չկառավարվող աշխատասեղան չի առաջարկում VPN անջատիչ յուրաքանչյուր պրոցեսի համար։ Ընտրեք այն շերտը, որը ընտրում է երթևեկությունը՝ կապված սոկետ, UID կանոն, firewall պրոֆիլ կամ SOCKS ցատկ։
Հաճախորդի պատկերակն ասում է կապված է, ինտերֆեյսը գոյություն ունի, և հավելվածը դեռ ոչնչի չի հասնում։ Այդ համակցությունը տարածված է, որովհետև վիրտուալ ինտերֆեյսը կարող է մնալ առկա, մինչդեռ նրա հեռավոր զույգը, հասցեները կամ երթուղիները բացակայում են։ ip link ճիշտ առաջին գործիքն է, և միաժամանակ ամենահեշտը՝ չափից ավելի կարդալու համար։ Դրոշները և հաշվիչները նկարագրում են մեկ շերտ, իսկ դրանցից վերև գտնվող շերտերը ձախողվում են ինքնուրույն։ Դա նաև այն գործիքն է, որը մարդիկ մեջբերում են, երբ ուզում են ապացուցել, որ թունելը միացած է, և հենց այն պնդումը, որը այն ինքնուրույն չի կարող պահել։
Կարդացեք ինտերֆեյսը նախքան պատկերակը
Սկսեք ip -details link show dev tun0-ով, ինչպես նկարագրված է ip-link ձեռնարկում, փոխարինելով սովորական անվան փոխարեն այն ինտերֆեյսը, որն իրականում պատկանում է ձեր հաճախորդին։ Դրոշները, տեսակը, MTU-ն և ինտերֆեյսի ինքնությունը օգտակար դիտարկումներ են։ Վիրտուալ ինտերֆեյսի վիճակի ձևակերպումը պարտավոր չէ վարվել ինչպես ֆիզիկական մալուխի կրիչի ցուցիչ, ուստի UP-ը ընդունեք որպես հայտարարություն ինտերֆեյսի մասին, ոչ թե թունելի։
Այդ տարբերությունը բացատրում է ամենաշփոթեցնող դեպքը՝ ինտերֆեյս, որը մնում է առկա, մինչդեռ հեռավոր կողմը վերամիանում է կամ անհասանելի է։
Պերսիստենտության կարգավորումները կարող են պահել կապը հենց որպեսզի վերամիացումը այն նորից չկառուցի, ինչը նշանակում է, որ առկայությունը առողջություն չէ։
Ավելացրեք հաշվիչներ և հարցում, որը պետք է օգտագործի դրանք
Օգտագործեք աջակցվող վիճակագրության տեսքը՝ ip -s link show dev tun0, և նշեք փաթեթների ու բայթերի հաշվիչները երկու ուղղություններով։ Այնուհետև ստեղծեք անվնաս հարցում, որը պետք է անցնի ինտերֆեյսով, և համեմատեք համապատասխան ուղղությունը։ Այն հարցումը, որը գնացել է այլ հավելվածի ուղիղ երթուղով, այդ հաշվիչները չի շարժի, և դա է վարժության իմաստը։
Եթե փոխանցման հաշվիչը շարժվում է, իսկ ընդունմանը՝ ոչ, փաթեթը գնաց և ոչինչ չվերադարձավ։ Սա այլ խնդիր է, քան ինտերֆեյսը, որը երբեք ոչինչ չի տեղափոխել։ Եթե երկու հաշվիչներն էլ շարժվում են, և հավելվածը դեռ ձախողվում է, խափանումը ինտերֆեյսից վեր է, ինչը առաջընթաց է, ոչ թե փակուղի։
Ընթերցեք երկու անգամ՝ մեկը առաջ, մեկը հետո, փոխարենը մեկ պատկերին վստահելու։
Հասցեները և երթուղիները առանձին քայլեր են
Կապը կարող է գոյություն ունենալ առանց նախածանի, resolver-ի կարգավորման կամ հավելվածին անհրաժեշտ երթուղու։ Ստուգեք հասցեն ip address show dev tun0-ով, ապա ստուգեք, թե որ երթուղին կընտրի նպատակակետը ip route get-ով իրական թիրախի համար։ Այդ երեք դիտարկումները պատասխանում են երեք տարբեր հարցերի, և միայն վերջինն է վերաբերում փոխանցմանը։
IPsec-ի դեպքում անվտանգության քաղաքականությունը և ասոցիացիայի վիճակը նույնպես կարող են կարևոր լինել, և ամեն IPsec նախագիծ չէ, որ հայտնվում է որպես պարզ tun ինտերֆեյս։ Փնտրել tun սարք, որը երբեք չպետք է գոյություն ունենար, սխալ եզրակացության հասնելու արագ ճանապարհ է։
Գրանցեք ճշգրիտ անունը, անվանատարածքը և ժամանակը ձեր պահած ցանկացած արդյունքի հետ, որովհետև նույն անունը մեկ այլ կոնտեյներում կամ վերականգնված նստաշրջանում ներկայացնում է բոլորովին այլ համատեքստ։
Մի ջնջեք այն, ինչը չեք նույնականացրել
Անծանոթ ինտերֆեյսը ինքնաբերաբար հնացած չէ։ Նույնականացրեք դրա սեփականատիրոջը նախքան որևէ բան հեռացնելը, և երբ հեռացումն իսկապես մտադրված է, օգտագործեք հաճախորդի փաստաթղթավորված ապամոնտաժումը կամ կառավարվող կարգավորումը։ Կենդանի թունել ջնջելը՝ տեսնելու, թե ինչ կլինի, փորձարկում է, որը պատասխանում է մի հարցի, որը ոչ ոք չի տվել։
Եթե ինտերֆեյսը պատկանում է կոնտեյներային runtime-ին կամ ձեր չստեղծած ցանցային անվանատարածքին, սեփականատերը մեկ հրաման հեռու է, և արժե նախ գտնել այն։
Այդ զգուշությունը վերաբերում է նաև ip link set down-ին, որը թվում է շրջելի և հաճախ այդպիսին չէ։
Ինչ պետք է ձեզ թողնի ստուգումը
Լավ ստուգումն ավարտվում է չորս փաստով՝ ինտերֆեյսի անունը և անվանատարածքը, դրա դրոշները և MTU-ն, իրական հարցումից հաշվիչների տարբերությունը, և այն երթուղին ու հասցեն, որն իսկապես անհրաժեշտ է հավելվածին։ Երբ դրանք գրված են, հաջորդ քայլն ակնհայտ է և պատկանում է կոնկրետ շերտի։ Առանց դրանց յուրաքանչյուր հետագա փոփոխություն գուշակություն է՝ հետադարձ պլանով։
Համեմատեք այդ չորս փաստերը աշխատող նստաշրջանի նույն չորս փաստերի հետ։ Եթե ինտերֆեյսի անունը և անվանատարածքը համընկնում են, բայց հաշվիչների տարբերությունը զրո է, հարցումը երբեք չի հասել թունել։ Եթե հաշվիչների տարբերությունը առողջ է, իսկ երթուղին այլ տեղ է ցույց տալիս, թունելը լավն է, իսկ երթուղավորումը՝ ոչ։ Այդ համեմատությունն է, որ արդյունքների կույտը դարձնում է որոշում։
Պահեք արդյունքը տոմսի հետ, որովհետև ավելի ուշ համեմատությունն օգտակար է միայն այն դեպքում, երբ տեսնում եք, թե ինչ փոխվեց։
Ապա փակեք շրջանը՝ կրկին փորձարկելով հավելվածը, որովհետև ինտերֆեյսը երբեք այն չէր, ինչը հոգ էր օգտատիրոջը։