Սերվեր կամ հաճախորդ. որը OpenVPN միավորն է երկակի դերով Pi-ի վրա

Pi-ի վրա աշխատում են երկու OpenVPN գործընթաց, որը միաժամանակ ընդունում է թափառող օգտատերերին և հասնում վերին մատակարարին, և նրանք բաժանում են գրեթե ոչինչ, բացի սարքավորումից։ Մեկը լսում է մուտքային թունելներին, մյուսը զանգահարում է դուրս։ Յուրաքանչյուրը կարդում է իր պանակը, և յուրաքանչյուրն ունի իր ձախողման ռեժիմը։ Սխալ միավորը վերագործարկելը ամենատարածված ձևն է, որով հաճախորդի ուղղումը փոխարենը ցնցում է լսողին։

Համապատասխանեցրեք միավորի անունը այն պանակին, որն այն բեռնում է

Upstream 2.6-ը մատակարարում է երկու ձևանմուշ միավոր՝ [email protected] և [email protected]։ Սերվերի ձևանմուշը սկսվում է /etc/openvpn/server-ում և այնտեղից բեռնում %i.conf-ը։ Հաճախորդի ձևանմուշը սկսվում է /etc/openvpn/client-ում։ roaming անունով օրինակը կարող է գոյություն ունենալ միաժամանակ երկու տեղում՝ որպես սերվեր և որպես հաճախորդ, երկու անկապ կոնֆիգուրացիաներով և նրանց միջև որևէ կապ չունենալով, բացի տողից։

Հարցրեք systemd-ին, ոչ թե ֆայլային համակարգին, քանի որ փաթեթավորողները ավելացնում են լրացուցիչ ֆայլեր, որոնք կարող են փոխել աշխատանքային պանակը կամ այն արգումենտները, որոնք ստանում է բինար ֆայլը։

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

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

Որոշեք փաթեթի ուղղությամբ, ոչ թե ինտերֆեյսի անունով

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

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

Նայեք սոքեթներին նախքան տեսություն կառուցելը։ udp/1194-ին կապված սերվերը ցույց է տալիս լսող սոքեթ։ Հաճախորդը ցույց է տալիս կապ մատակարարի հասցեի հետ և ոչինչ, որ լսի։

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Մեկ օրինակի լռելյայն ուղին կարող է որսալ մյուսի պատասխանները

Վերին հաճախորդի կողմից հրող redirect-gateway-ը տեղադրում է լռելյայն ուղի, որը մրցում է մեքենայի վրա մնացած ամեն ինչի հետ, ներառյալ այն պատասխանները, որոնք սերվերը ուղարկում է թափառող օգտատերերին։ OpenVPN-ը բացառություն է անում իր զուգընկերոջ հասցեի համար, որպեսզի թունելը մնա հասանելի, բայց այդ բացառությունը ոչինչ չի ասում հյուրանոցային ցանցում նստած հեռախոսի մասին։

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

Փորձարկեք տեղական որոշումը, ոչ թե թունելի վիճակը, քանի որ միջուկը ընտրում է աղբյուրն ու ինտերֆեյսը նախքան OpenVPN-ը կտեսնի փաթեթը։

ip route get 203.0.113.44
ip rule show

Վերագործարկեք մեկ դեր և ապացուցեք, որ մյուսը ողջ մնաց

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

Գրեք կանգառի պայմանը նախքան փոփոխությունը՝ արդյոք վերին թունելի կորուստը արգելափակում է թափառող օգտատերերին, թե վերադառնում է Pi-ի սեփական վերին կապուղուն։ DNS-ը և IPv6-ը նույնպես հստակ պատասխան են պահանջում, քանի որ հրող լուծիչը հաճախ ապրում է ավելի երկար, քան այն ուղին, որն այն օգտակար դարձրեց։

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

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