Սահմանափակել Samba-ի համօգտագործումը մեկ օգտատիրոջ և մեկ VPN հասցեի

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

Առասպելը. երկու ցանկ մեկ կանոն են կազմում

smb.conf-ի հղումը valid users և hosts allow-ը սահմանում է որպես երկու անկապ պարամետր, և հենց երկուսն էլ մեկ համօգտագործման վրա դնելն է, որտեղից սկսվում է շփոթությունը։ Սահմանեք valid users = mira, tomas և hosts allow = 10.77.0.21, 10.77.0.22, և ընդունվում են չորս համադրություն՝ Միրան ցանկացած հասցեից, Թոմասը ցանկացած հասցեից։ Կարգավորման մեջ ոչինչ առաջին անունը չի կապում առաջին հասցեին, և անունների հայտնվելու հերթականությունը իմաստ չունի։ Դրանք վերադասավորելը, երկրորդ hosts allow տող ավելացնելը կամ յուրաքանչյուր տողում մեկ անուն դնելը ոչինչ չի փոխում։ Արդյունքը երկու ցանկերի արտադրյալն է, ոչ թե նրանց միջև քարտեզում։

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

Ինչ է գնահատում Samba-ն, և ինչ հերթականությամբ

Փուլերը ընթանում են ֆիքսված հերթականությամբ, և սխալ հերթականությունը տալիս է սխալ ախտորոշում։ Հաճախորդը բացում է կապ. գլոբալ հոսթի ստուգումը կատարվում է, եթե այն կարգավորված է. սեսիայի կարգավորումը նույնականացնում է հաշիվը. այնուհետև հաճախորդը միանում է համօգտագործման, որտեղ կիրառվում են այդ համօգտագործման սեփական հոսթերի ցանկը, valid users և միայն-կարդալու կարգավորումը. և միայն երբ ֆայլ է բացվում, որոշում են նույնականացված ինքնության ֆայլային համակարգի թույլտվությունները։ Յուրաքանչյուր փուլ կարող է ինքնուրույն մերժել հարցումը, և մեկն անցնելը ոչինչ չի ասում հաջորդի մասին։ Կարևոր հետևանքն այն է, որ հաշիվը հայտնի է դեռ այն ժամանակ, երբ գնահատվում է համօգտագործման հոսթերի ցանկը, և հոսթերի ցանկը դեռևս որևէ եղանակ չունի անվանելու այդ հաշիվը։

Այդ պատճառով համօգտագործումը չի կարող մեկ օգտատիրոջ կապել մեկ հասցեի հետ. hosts allow և valid users-ը առանձին պայմաններ են, որոնք կիրառվում են ծառի միացման նույն փուլում, և յուրաքանչյուրը պատասխանում է իր հարցին։ Հոսթի պայմանը երբեք հաշվի անունը որպես մուտք չի վերցնում, ուստի այն հնարավոր չէ գրել ըստ օգտատիրոջ։ Զույգը կարող է արտահայտել միայն երկրորդ համօգտագործումը կամ Samba-ից դուրս քաղաքականության շերտը։

Գլոբալ արժեքները կարևոր են ժառանգման ձևի պատճառով։ Համօգտագործումը, որը բաց է թողնում hosts allow-ը, ժառանգում է գլոբալ արժեքը, իսկ համօգտագործումը, որը սահմանում է իրենը, օգտագործում է այդ արժեքը գլոբալի փոխարեն, ոչ թե դրան ի հավելումն։ Այսպիսով լայն գլոբալ ցանկը լայնացնում է այն համօգտագործումները, որոնք երբեք չեն սահմանում պարամետրը, և ոչինչ չի անում այն համօգտագործմանը, որը սահմանում է իրենը։ Կատարեք testparm -s և կարդացեք նրա տպած՝ յուրաքանչյուր համօգտագործման արժեքները, որովհետև հենց այդ արտածումն է արդյունավետ քաղաքականությունը, և ոչ թե սկավառակի ֆայլը։

Մեկ համօգտագործումը նեղացնելը նույնպես ոչինչ չի անում սերվերի մնացած մասի համար։ Այլ համօգտագործումները, տպիչների հերթերը և IPC կապը պահում են իրենց կանոնները, ուստի այն ձևավորումը, որը հենվում է մեկ համօգտագործման հասցեների ցանկի վրա, պաշտպանում է մեկ ուղի, ոչ թե հոսթը։

Երկու համօգտագործման անուն մեկ պանակի վրա

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

[shared-mira]
    path = /srv/shared
    guest ok = no
    read only = yes
    valid users = mira
    hosts allow = 10.77.0.21
    hosts deny = ALL

[shared-tomas]
    path = /srv/shared
    guest ok = no
    read only = yes
    valid users = tomas
    hosts allow = 10.77.0.22
    hosts deny = ALL

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

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

Ինչ կարող է ապացուցել աղբյուրի հասցեն

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

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

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

Ապացուցեք խաչված զույգերով

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

testparm -s
smbclient //fileserver/shared-mira -U mira -c 'ls'
smbclient //fileserver/shared-tomas -U tomas -c 'ls'
smbstatus --shares

Շարահյուսության ստուգումը միայն ապացուցում է, որ ֆայլը վերլուծվում է։ Հավատարմագրերը, ACL-ները և հոսթի որոշումը կիրառվում են իրական կապով, ուստի գործարկեք հաճախորդի հրամանը այն հասցեից, որը ցանկանում եք փորձարկել, և հետևեք, թե որ փուլն է մերժում այն։ Եթե խաչված զույգը հաջողվում է, արդյունավետ հոսթերի ցանկը ավելի լայն է, քան հուշում է բլոկը, և testparm -s-ն առաջինն է, որ պետք է կարդալ։ Եթե խաչված զույգը ձախողվում է սխալ պատճառով, կասկածելի են հաշիվը կամ ACL-ը։

Սեսիաները smbstatus-ով դիտարկելը և դրանք սպանելը գործողություն է արձագանքի, որը կատարվում է հասանելիությունը սկսվելուց հետո, ոչ թե ընդունելության վերահսկում։ Ամբողջ դիտարկված հասցեն արգելափակելը կարող է նաև անջատել նույն NAT-ի հետևում գտնվող անկապ օգտատերերին, այդ պատճառով որոշումը պատկանում է համօգտագործման սահմանմանը, իսկ դիտարկումը՝ արձագանքի գործընթացին։ Պահեք երկուսը առանձին, և ձևավորումը մնում է ազնիվ այն մասին, ինչ պարտադրում է։