OpenVPN-ի հաճախորդը կանգ է առնում, երբ նրա սերվերը աշխատում է նույն հոսթում

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

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

Կարդացեք ախտանիշը հակառակ ուղղությամբ

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

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

Մեկ սոկետ և մեկ սարք յուրաքանչյուր օրինակի համար

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

lport 1195
nobind
dev tun1

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

nobind-ը պատկանում է հաճախորդի կողմին։ Սերվերը դեռ պետք է կապի և լսի, ուստի չպատճենեք տողը սերվերի կարգավորման մեջ և մի անջատեք կապումը այն հաճախորդի վրա, որի զուգընկերը զտում է ֆիքսված աղբյուրի պորտով։

Ընտրեք մեկ սեփականատեր լռելյայն երթուղու համար

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

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

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

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

Ստուգեք աղյուսակով, ոչ թե կարգավիճակի տողով

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

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

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

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