Samba-ն VPN հասցեի վրա՝ ինչու է լսորդը անհետանում

Ընդհանուր ռեսուրսը աշխատում է ամբողջ առավոտ, թունելը կրկին միանում է կեսօրին, և նույն UNC ուղին այժմ ժամանակի սպառման է հանդիպում, մինչդեռ սերվերին ping-ը դեռ պատասխանում է։ Բաժանման սահմանման մեջ ոչինչ չի փոխվել, և VPN-ը միացված է։ Փոխվել է այն լոկալ հասցեն, որին Samba-ն կապված էր, և որը չկա ինտերֆեյսը նորից ստեղծելուց հետո։ Այդ խափանման ձևը լսորդի կենսացիկլի խնդիր է, ոչ թե թույլտվությունների խնդիր։

Ընդհանուր ռեսուրսը աշխատում է մինչև թունելի վերագործարկումը

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

ping-ը դեռ կարող է հաջողվել, եթե նոր հասցեն պատասխանում է ICMP-ին, և դրա համար հասանելիությունը լավ է թվում, մինչ ռեսուրսը մեռած է։ Հենց այդ մեկ մոլորեցնող հաջողությունն է մարդկանց ուղարկում դեպի firewall։

Հասանելիությունը կապման հասցե չէ

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

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

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

Փոխարենը կապվեք կայուն հասցեին

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

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

ss -ltnp | grep ':445'

Փորձեք վերամիացումը, ոչ թե կանաչ լույսը

Ստուգեք լսորդը վերամիացումից հետո, ոչ միայն ծառայության մեկնարկից հետո։ Նորից ստեղծեք թունելը, ապա կարդացեք լսման աղյուսակը և հաստատեք, որ սոքեթը գոյություն ունի այն հասցեում, ուր ուղղորդվում են հաճախորդները։ Կանաչ թունելի ցուցիչը և հաջող կոնֆիգուրացիայի ստուգումը ոչ մեկը ոչ մյուսը չեն ապացուցում։

smbclient -L //files.corp.example -U alice

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