OpenVPN-ի client-connect կեռիկը. ուր է իրականում գնում ձեր հասցեն

client-connect սկրիպտից հասցե վերադարձնելը կարծես պետք է սահմանի հաճախորդի IP-ն։ Բայց դա այդպես չէ. կեռիկի միակ ալիքը դեպի սերվեր ժամանակավոր ֆայլն է, որի ուղին գալիս է որպես սկրիպտի վերջին արգումենտ, և հասցեն պետք է գրվի այնտեղ ifconfig-push շարահյուսությամբ։ Սկրիպտը, որը տպում է հասցեն կամ դուրս է գալիս զրոյով՝ ոչինչ չգրելով, ստեղծում է միացված հաճախորդ՝ լողավազանից վերցված հասցեով, և սերվերի մատյանը կատարյալ առողջ տեսք ունի։

Շփոթմունքը հասկանալի է, որովհետև մի քանի այլ կեռիկներ իսկապես պատասխանում են ելքի կոդերով կամ միջավայրի փոփոխականներով։ Այս մեկն ունի իր պայմանագիրը, և պայմանագիրը սկսվում է ֆայլի անունով։

Կեռիկը գրում է ֆայլ, ոչ թե վերադարձվող արժեք

Հայտարարությունը երկու տող է. script-security 2՝ կանչը թույլատրելու համար, ապա client-connect /etc/openvpn/server/assign-address.sh։ Երբ հաճախորդը նույնականացվում է, սերվերը գործարկում է այդ սկրիպտը՝ ավելացնելով ստեղծված ֆայլի ուղին որպես վերջին արգումենտ, որը $1 է միայն այն դեպքում, երբ հայտարարությունը չի փոխանցում իր սեփական լրացուցիչ արգումենտները։ Այդ հաճախորդի վրա կիրառվող ամեն ինչ գրվում է այդ ֆայլում որպես սովորական հրահանգներ՝ մեկը յուրաքանչյուր տողում, ճիշտ այնպես, ինչպես դրանք կհայտնվեին կարգաբերման մեջ։ Իր սեփական պարամետրերն ավելացնող փաթաթան տեղաշարժում է դիրքը, և դասական ախտանիշը սկրիպտն է, որը գրում է --verbose-ի նման ուղու մեջ։

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

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

Մուտքերը գալիս են միջավայրի փոփոխականներով. common_name, trusted_ip, ifconfig_pool_remote_ip և մնացածը։ Վերաբերվեք բոլորին ինչպես սերվերից դուրս եկող տողերի, երբեք ինչպես shell-ի հատվածների։

Հասցեների քարտեզագրումը քաղաքականություն է, ոչ թվաբանություն

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

Ով վերահսկում է անունը, վերահսկում է հասցեն, ուստի որոշեք, թե ինչ է իրականում ներկայացնում common_name-ը այս տեղակայման մեջ։ username-as-common-name-ի միացված վիճակում ինքնությունը մուտքագրումն է, ոչ թե վկայագրի սուբյեկտը։ Երբեք չփոխանցեք այդ արժեքը shell-ի գնահատմանը, և երբեք թույլ չտաք, որ հաճախորդը ազդի ֆայլի ուղու վրա։

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

Տոպոլոգիան որոշում է, թե ինչ է նշանակում ifconfig-push

10.77.0.0/24-ի վրա topology subnet-ով ifconfig-push 10.77.0.20 255.255.255.0-ը հասցե է գումարած դրա ցանցային դիմակը։ topology net30-ի ներքո երկրորդ արգումենտը բոլորովին դիմակ չէ, այլ զուգընկերոջ հասցեն, ուստի ենթացանցի ձևը net30 սերվերի վրա պատճենելը ձեզ տալիս է հաճախորդ, որը միանում է և չի կարող տրաֆիկ անցկացնել։ Փոխեք տոպոլոգիան դիտավորությամբ, երբեք ոչ թե որպեսզի օրինակը հետևողական տեսք ունենա։ Արդեն net30-ով աշխատող սերվերն ունի կենդանի հաճախորդներ հին հասցեավորման վրա, ուստի անցումը սպասարկման պատուհանով միգրացիա է, ոչ թե մեկ տողի խմբագրում։

Ստատիկ հասցեները պետք է լինեն դինամիկ լողավազանից դուրս և յուրաքանչյուր այլ ստատիկ նշանակումից դուրս, ներառյալ սովորական client-config-dir ֆայլերով տրվողները։ Եթե երկու մեխանիզմ կարող են տարբեր հաճախորդների համար նույն հասցեն արտադրել, դրանցից մեկը վերջիվերջո կանի դա։

Փորձարկեք չորս դեպք նախքան դրան վստահելը

Գործարկեք նույն ստուգումները քարտեզագրված ինքնության, չքարտեզագրվածի, վերամիացման և մոդելավորված գրանցամատյանի խափանման վրա։ openvpn --config client.ovpn --verb 4-ը ցույց է տալիս նշանակված հասցեն push պատասխանում, իսկ սերվերի վրա grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log-ը հաստատում է, թե ինչ է իրականում ուղարկվել։ Չքարտեզագրված ինքնության համար ակնկալվող արդյունքը մերժված կապն է, ոչ թե լողավազանի հասցեն։

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

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