OpenVPN-ի ստատիկ IP յուրաքանչյուր հաճախորդի համար՝ ifconfig-push, ոչ ipp.txt
Կայունության ֆայլը պատմություն է, ոչ ամրագրում։ Ընտրեք ճիշտ հաճախորդի անունը, համապատասխանեցրեք տոպոլոգիային և ապացուցեք հասցեն նոր միացման վրա։
ipp.txt-ում տող խմբագրելը թվում է, թե հասցե եք ամրագրում, բայց այդպես չէ։ Այդ ֆայլը, որը անվանում է ifconfig-pool-persist-ը, գրանցում է, թե ընդհանուր անունը նախորդ անգամ որ հասցեն ուներ, որպեսզի լողավազանը կարողանա նույնը վերադարձնել, երբ դա հարմար է։ Դրանում ոչինչ չի կապում հաջորդ միացումը այդ թվին։
Կատարեք ստորև նշված ստուգումները հերթականությամբ։ Յուրաքանչյուրը կա՛մ հաստատում է մեխանիզմը, կա՛մ ասում է կանգ առնել և ուղղել մուտքային տվյալը։
Ինչի համար է կայունության ֆայլը
Ֆայլը գոյություն ունի, որպեսզի հասցեները կայուն մնան վերագործարկումների միջև, ինչը վերամիացումները դարձնում է ավելի հարմարավետ, իսկ մատյանները՝ ավելի ընթեռնելի։ Այն կարդացվում է որպես պատմություն և գրվում է որպես պատմություն, իսկ բաշխման ուղին ազատ է մնում ընտրելու այլ հասցե, երբ հուշումը չի համապատասխանում՝ այլ լողավազան, հակասող նշանակում կամ հաճախորդ, որը եկել է լողավազանը լցվելուց հետո։ Այդ պատճառով ձեռքով խմբագրումը կարող է ֆայլում կատարյալ երևալ և ոչինչ չփոխել միացման մեջ։ Վերաբերվեք դրան որպես անցյալ որոշումների քեշ, ոչ թե քաղաքականության աղբյուր։
Եթե ձեզ անհրաժեշտ է կոնկրետ հասցե կոնկրետ հաճախորդի համար, փաստաթղթավորված մեխանիզմը ifconfig-push-ն է, և այն պատկանում է այն կոնֆիգուրացիային, որը տիրապետում է այդ հաճախորդին։
Ստուգեք, որ ընտրված է ճիշտ հաճախորդը
Բացահայտ նշանակումը որոնվում է հաճախորդի ընդհանուր անունով, ուստի սխալ ինքնության համար անվանված ֆայլը պարզապես երբեք չի կարդացվում։ Հաստատեք, թե սերվերը ինչ է համարում այդ հաճախորդի անունը, հատկապես այնտեղ, որտեղ username-as-common-name-ը փոխում է այն նույնականացումից հետո։ Այնուհետև հաստատեք, որ ֆայլի անունը ճշգրիտ համապատասխանում է այդ արժեքին՝ ներառյալ տառերի մեծատառ-փոքրատառ լինելը։
Մինչ այստեղ եք, մտածեք զուգահեռականության մասին։ Եթե duplicate-cn-ը թույլատրված է, մի քանի սարքեր կարող են ներկայացնել նույն ինքնությունը, և մեկ հաստատուն հասցե չի կարող եզակի լինել բոլորի համար։ Որոշեք՝ արժե՞ արդյոք հաստատուն հասցեի համար հրաժարվել այդ ինքնության զուգահեռ սեսիաներից, քանի որ այդ երկու պահանջները միաժամանակ հնարավոր չէ բավարարել։
Ստուգեք, որ թվերը համապատասխանում են տոպոլոգիային
Փաստարկների իմաստը կախված է թունելի տոպոլոգիայից, և հենց այստեղ պատճենված օրինակն ամենամեծ վնասն է հասցնում։ Ավելի հին net30 դասավորության մեջ յուրաքանչյուր հաճախորդ զբաղեցնում է չորս հասցեից բաղկացած բլոկ, ուստի push-ը տալիս է զույգ հասցե։ Ենթացանցային տոպոլոգիայում հաճախորդը ստանում է մեկ հասցե գումարած լողավազանի դիմակը, և զույգի ձևը սխալ է։ Կարդացեք տոպոլոգիան գործող կոնֆիգուրացիայից նախքան տողը գրելը։
# /etc/openvpn/ccd/partner-a (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0Ստուգեք հասցեն այն ամենի դեմ, ինչը կարող է տիրապետել դրան՝ մեկ այլ բացահայտ նշանակում, դինամիկ լողավազանի տիրույթ և ցանկացած ստատիկ երթուղի, որը ենթադրում է հաստատուն հոսթ։ Լողավազանի հետ համընկնող հասցեն կաշխատի այնքան ժամանակ, քանի դեռ լողավազանը այն չի տվել մեկ ուրիշին, և այդ ձախողումը պատահական կթվա։
Ստուգեք արդյունքը նոր միացման վրա
Գոյություն ունեցող սեսիան պահպանում է իրեն տրված հասցեն, ուստի միակ իմաստալից փորձությունը նոր միացումն է։ Անջատեք հաճախորդին, նորից միացեք և կարդացեք այն հասցեն, որը նա իրականում ստացել է՝ դրա հետ եկած երթուղիների հետ միասին։ Եթե հասցեն դեռ դինամիկ է, նշանակումը չի կիրառվել, և հաջորդ քայլը կոնֆիգուրացիայի որոնումն է, այլ ոչ թե պատմության ֆայլի ևս մեկ խմբագրում։
Ապացույցները պահեք միասին՝ հաճախորդի անունը, համապատասխանած ֆայլը, նշանակված հասցեն և լողավազանը, որտեղից այն եկել է։
Վերջապես, հաստատուն թունելային հասցեն սարքի վկայագիր չէ։ Այն նշում է տեղ հասցեների պլանում, մինչդեռ նույնականացումը դեռ հենվում է վկայագրի և հաշվի վրա։ Երկուսի շփոթումը հասցեների կոնֆլիկտը վերածում է անվտանգության ենթադրության, որը ոչ ոք չի գրել։