OpenVPN ադապտերը Windows-ում թարթո՞ւմ է. ստուգեք կրկնակի IP-ը

Windows-ում OpenVPN ադապտերը, որը վերցնում է հասցե, գցում այն և կրկնում է դա յուրաքանչյուր մի քանի վայրկյանը մեկ, սովորաբար DHCP-ի սխալ չէ։ Ադապտերին ասում են օգտագործել այնպիսի հասցե, որին արդեն պատասխանում է մեկ այլ բան, ուստի Windows-ը նշում է այն որպես անօգտագործելի, և հաճախորդը սկսում է նորից։ Հաճախորդի մատյանը մնում է լուռ, որովհետև բախումը լուծվում է դրա տակ, հենց օպերացիոն համակարգի սեփական ցանցային կույտում։

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

Սկսեք Windows-ի իրադարձությունների մատյանից, ոչ թե հաճախորդի մատյանից

Windows-ը հասցեների բախումները գրանցում է համակարգի մատյանում՝ 4198 և 4199 իրադարձության ID-ներով։ Առաջինը հայտնում է հասցեի համար հայտնաբերված բախման մասին, երկրորդը՝ որ ինտերֆեյսը չի կարողացել օգտագործել այն հասցեն, որով կարգաբերված է եղել։ Ոչ մեկը OpenVPN չի հիշատակում, և հենց դրա համար էլ դրանք հեշտ է բաց թողնել։

Վերցրեք վերջին իրադարձությունները և համեմատեք դրանց ժամանակային նշանները ադապտերի թարմացման ցիկլի հետ՝ Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap։ Յուրաքանչյուր տասնհինգ վայրկյանը մեկ բախումը համապատասխանում է հաճախորդի, որը նույն հասցեն նորից փորձում է սեփականատիրոջ դեմ, որը շարունակում է պատասխանել դրան։ Միացման պահին մեկուսացված բախումը ավելի շուտ ցույց է տալիս միանվագ ընդհարման։ Ամեն դեպքում, հաջորդ հարցն այն է, թե ով դեռ ունի հասցեն։

Երեք դասավորություն երկու հոսթ դնում է մեկ հասցեի վրա

Հարցրեք սերվերին, թե ով է նրա կարծիքով ունի հասցեն, ապա հարցրեք ցանցին, թե ով է պատասխանում դրան։ grep -H ifconfig-push /etc/openvpn/ccd/* թվարկում է յուրաքանչյուր ամրագրված թունելային հասցե և այն վկայականը, որին այն պատկանում է։ ip -4 neigh show dev tap0 ցույց է տալիս, թե ինչ է սովորել կամուրջը երկրորդ շերտում։ Այս երկու ցանկերի համեմատությունը գտնում է կրկնակիների մեծ մասը մեկ րոպեից պակաս ժամանակում։

Երեք դասավորություն բացատրում է գրեթե բոլորին. client-config-dir-ի գրառումը մեկ հասցե ամրագրում է երկու վկայականի համար, կամուրջով միացված tap հատվածը մեքենային տալիս է հասցե, որը մեկ այլ հոսթ արդեն ստատիկ ունի, կամ հնացած վարձակալության ֆայլը վերադարձնում է հասցե, որը դեռ միացած հաճախորդը կարծում է, թե իրենն է։ Երրորդ դեպքն ամենանենգն է, որովհետև ifconfig-pool-persist միտումնավոր կրկին օգտագործում է հասցեները հայտնի հաճախորդների համար։

Հասցեն դարձրեք եզակի՝ դրա համար մրցելու փոխարեն

Բեռնարկման հերթականությունը միայն որոշում է, թե ով է հաղթում այսօր, ուստի վերագործարկման հաջորդականության վրա հիմնված ցանկացած ուղղում համարեք ժամանակավոր։ Տվեք յուրաքանչյուր հաճախորդի իր ifconfig-push տողը, կամ ստատիկ հասցեներ հատկացրեք այնպիսի միջակայքից, որին ոչ մի կամուրջ կամ սերվերային ինտերֆեյս չի դիպչում։ Ստուգեք նաև հաճախորդների ցանկը կրկնակի ընդհանուր անունների համար, որովհետև duplicate-cn թույլ է տալիս երկու սեսիայի կիսել մեկ ինքնություն և, հետևաբար, մեկ ամրագրված հասցե։ Եթե կամուրջով միացված սարքին իսկապես պետք է ֆիքսված հասցե, տեղափոխեք այն իր ենթացանց կամ պահուստավորեք լողավազանից այն տեղում, որը սերվերը գրանցում է։

Ջնջեք persist ֆայլը միայն այն բանից հետո, երբ իմանաք, թե ինչ վարձակալություններ է պարունակում, այլապես հաջորդ վերամիացումը նորից կբաշխի նույն հասցեները։

Վերագործարկեք ճիշտ հերթականությամբ և հաստատեք մեկ սեփականատեր յուրաքանչյուր հասցեի համար

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

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

Հետևեք ամբողջ թարմացման ցիկլին նախքան տոմսը փակելը

Մեկ մաքուր ընթերցում ոչինչ չի ապացուցում։ Հետևեք ադապտերին առնվազն տասը րոպե և մեջտեղում պարտադրեք վերամիացում՝ Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState։ Հասցեն պետք է վերապրի վերամիացումը և մնա նախընտրելի վիճակում։

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

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