1194 պորտն արդեն օգտագործվում է։ ո՞ւմն է այս OpenVPN սոքեթը։

Միևնույն սերվերի պրոֆիլը գործարկեք երկու անգամ, և երկրորդ գործընթացը դուրս է գալիս «հասցեն արդեն օգտագործվում է» սխալով 1194 պորտի համար։ Սովորական դեպքում կոնֆլիկտը ստեղծել է ախտորոշիչ գործարկումը, և սկզբնական օրինակը դեռ լիովին նորմալ սպասարկում է հաճախորդներին։ Այս պատմությունը բացատրում է այս հաղորդումների մեծ մասը, և արժե այն ճանաչել նախքան որևէ բան վերագործարկելը։ Սա նաև լուծման ամենաէժան տարբերակն է։

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

Կարդացեք ճշգրիտ միացման սխալը

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

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

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

Թվարկեք սոքեթը, ոչ թե պորտը

Պորտի համարը թերի թվարկում է։ Վերջնակետը փոխադրում է, հասցեների ընտանիք, տեղական հասցե և պորտ, բոլորը մեկ ցանցային անվանատարածքի ներսում։ UDP լսողը և TCP լսողը նույն համարի վրա տարբեր սոքեթներ են, և նույն համարի վրա երկու գործընթաց տարբեր անվանատարածքներում երբեք չեն հանդիպում։

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

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

Պարզեք, թե որ գործընթացն է տիրապետում դրան

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

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

Համեմատեք գտածը ծառայությունների կառավարչի, կոնտեյների գործարկման միջավայրի կամ նախորդ թեստից մնացած տերմինալային գործընթացի հետ։ Գործընթացի մանրամասների բացակայությունը ապացույց չէ, որ սոքեթը սեփականատեր չունի՝ սովորաբար դա նշանակում է, որ հարցումը կատարվել է առանց բավարար թույլտվության։ Նույնպես, միայն TCP-ի ցանկը չի վերացնում UDP կոնֆլիկտը, ուստի ստուգեք սխալում նշված փոխադրումը։ Միայն գործընթացի անվանումը երբեք չի ասում, թե որ պրոֆիլն է բեռնվել, և հենց պրոֆիլն է որոշում վերջնակետը։

Մեկ սեփականատեր, թե երկու նախագծված օրինակ

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

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

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

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

Ստուգեք միացումը նախքան ամեն ինչ

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

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

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