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-ის უკან მყოფი უკავშირო მომხმარებლებიც გათიშოს, ამიტომ გადაწყვეტილება გაზიარების განსაზღვრებას ეკუთვნის, ხოლო მონიტორინგი რეაგირების პროცესს. ეს ორი ცალ-ცალკე გქონდეთ და დიზაინი პატიოსანი დარჩება იმაში, რასაც ახორციელებს.