SSH-ը վերագործարկումից հետո չի լսում. VPN հասցեն ուշանում է

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

Ինչ է իրականում ասում կապման սխալը

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

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

Որ գործընթացն է տիրում պորտին

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

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

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

Դարձրեք պատրաստականությունը բացահայտ, ոչ թե քուն

Ֆիքսված ուշացումը գուշակություն է, որը արագ սարքավորումն ու դանդաղ ցանցերը նույնությամբ է վերաբերվում։ Փոխարենը արտահայտեք կախվածությունը. սպասեք հասցեին, ապա սկսեք։

ip -4 addr show dev tun0
systemctl edit ssh.service

Ավելացրեք ExecStartPre հրաման, որը կրկնվում է մինչև հասցեի հայտնվելը, կամ դասավորեք միավորը ինտերֆեյսին պատկանող կոնկրետ ցանցային թիրախից հետո։ Երկու մոտեցումներն էլ կախվածությունը գրանցում են մի տեղ, որտեղ հաջորդ ադմինիստրատորը կարող է կարդալ։ Օղակին պետք է ժամանակային սահմանափակում, այլապես ձախողված VPN-ը թողնում է կախված միավոր՝ խափանման մասին հաղորդելու փոխարեն։ Այնուհետև հաստատեք, որ դեմոնը կապում է թունելի հասցեն, մինչ սովորական ինտերֆեյսը մնում է ձեր զտիչ կանոնների ներքո։

Փորձարկեք մաքուր բեռնարկում և վերակապակցում

Ձեռքով վերագործարկումը այն բանից հետո, երբ ամեն ինչ առցանց է, ոչինչ չի ապացուցում բեռնարկման հերթականության մասին։ Վերագործարկեք մեքենան՝ թունելը ավտոմատ բարձրանալու կարգավորումով, և հետևեք՝ արդյոք լսողը հայտնվում է առանց միջամտության։

systemctl status ssh.service
ss -ltnp 'sport = :22'

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

Հաջողության չափանիշը լսողն է, որը հայտնվում է իր փաստաթղթավորված կախվածության ներքո, այլ ոչ այն մեկը, որի վերագործարկումը ինչ-որ մեկը հիշել է։