Beheine in Samba-dieling ta ien brûker en ien VPN-adres

Yn dit ûntwerp wurde twa ferskillende rjochten trochinoar helle: wa't in map brûke mei en hokker adressen oeral ferbine meie. In akkountlist njonken in boarnelist skriuwe fielt as in keppeling, mar Samba beoardielet de beide listen as ûnôfhinklike predikaten. Elkenien dy't beide befettet, wurdt talitten, en dat is in bredere regel as de measte behearders bedoele. De oplossing is of in oare yndieling fan 'e dieling of in beliedslaach dy't it pear útdrukke kin.

De myte: twa listen meitsje ien regel

De smb.conf-referinsje definiearret valid users en hosts allow as twa ûnferbûne parameters, en it is by it setten fan beide op ien dieling dat de betizing begjint. Set valid users = mira, tomas en hosts allow = 10.77.0.21, 10.77.0.22 en fjouwer kombinaasjes wurde talitten: Mira fan beide adressen, Tomas fan beide adressen. Neat yn 'e konfiguraasje bûcht de earste namme oan it earste adres, en de folchoarder wêryn't de nammen ferskine hat gjin betsjutting. Se opnij oarderje, in twadde hosts allow-rige tafoegje of ien namme per rige sette feroaret neat. It resultaat is it produkt fan twa listen, gjin ôfbylding tusken har.

Wat de measte minsken eins wolle, is smeller: Mira allinnich fan ien adres, Tomas allinnich fan in oar. Ien dielingsdefinysje hat gjin syntaksis foar dy bining, en gjin betûft oarderjen makket ien. Dat is in foarm fan belied dy't Samba net binnen ien dieling útdrukt, en dêr oerlibbet de myte.

Wat Samba beoardielet, en yn hokker folchoarder

De stadia rinne yn in fêste folchoarder, en in ferkearde folchoarder jout de ferkearde diagnoaze. In klant iepenet in ferbining; in globale hostkontrôle rint as ien konfigurearre is; de sesje-opset ferifiearret it akkount; dêrnei ferbynt de klant him mei in dieling, dêr't de eigen hostlist fan dy dieling, valid users en de allinnich-lêze-ynstelling tapast wurde; en pas as in bestân iepene wurdt, beslute de bestânsysteemrjochten fan 'e ferifiearre identiteit. Elk stadium kin it fersyk sels ôfwize, en it passearjen fan ien seit neat oer de folgjende. It wichtige gefolch is dat it akkount bekend is foardat de hostlist fan 'e dieling beoardiele wurdt, en de hostlist hat noch altyd gjin manier om dat akkount te neamen.

Dêrom kin in dieling ien brûker net oan ien adres bine: hosts allow en valid users binne aparte predikaten dy't yn itselde beam-ferbining-stadium tapast wurde, en elk beantwurdet syn eigen fraach. It hostpredikaat nimt nea de akkountnamme as ynfier, dus it kin net per brûker skreaun wurde. Allinnich in twadde dieling, of in beliedslaach bûten Samba, kin it pear útdrukke.

Globale wearden binne wichtich fanwegen de wize wêrop't se erfd wurde. In dieling dy't hosts allow weilitten, erft de globale wearde, en in dieling dy't syn eigen set, brûkt dy wearde yn 'e stee fan 'e globale, net derby. Sa ferbreedt in brede globale list de dielingen dy't de parameter nea sette, en docht neat oan in dieling dy't syn eigen definiearret. Fier testparm -s út en lês de wearden per dieling dy't it printsje, want dy útfier is it effektive belied, en it bestân op 'e skiif net.

It ferfinen fan ien dieling docht ek neat foar de rest fan 'e tsjinner. Oare dielingen, printerswachten en de IPC-ferbining hâlde har eigen regels, dus in ûntwerp dat op 'e adreslist fan ien dieling fertrout, beskermet ien paad ynstee fan 'e host.

Twa dielingsnammen oer ien map

As deselde map foar twa minsken fan twa adressen berikber wêze moat, stel it dan twa kear bleat ûnder ferskillende nammen. Elk blok draacht ien akkount en ien boarne, wat it pear ta iets makket dat de konfiguraasje ôftwinge kin. De kosten binne dat elk persoan in oare dielingsnamme brûkt om by deselde bestannen te kommen, en dat moat in bewuste feroaring oan 'e klantkant wêze.

[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

In dielingspoarte is gjin bestânsysteemrjocht. Beide identiteiten hawwe noch altyd tagong ta de map fia de ûnderlizzende ACL, en de allinnich-lêze-ynstelling is in twadde laach, net de iennichste. Jou skriuwtagong allinnich as de wurkstream it fereasket, en kontrolearje dan dat bestannen dy't troch ien identiteit oanmakke binne, foar de oare brûkber bliuwe.

Beide blokken wize nei ien paad, dus in feroaring yn 'e map rekket beide dielingen. Dat is meastentiids it doel, mar it betsjut ek dat in rjochtenflater foar beide brûkers tagelyk sichtber is.

Wat it boarne-adres bewize kin

It adres dat Samba sjocht, is it adres dat de tsjinner berikt hat, net it adres dat de klant tinkt dat er hat. In VPN-gateway dy't elk klant oerset nei ien boarne-adres lit it ûnderskied ferdwine: alle klanten komme as deselde host en de boarnelist kin se net mear útinoar hâlde. Stabile tawizing per klant en in gateway dy't de boarne behâldt, binne betingsten om adressen oeral as belied te brûken. Sûnder beide mjit de beheining de gateway ynstee fan 'e brûker.

Sels dan is in adres gjin apparaat. Twa laptops efter ien tunneladres, in opnij tawiisd hierkontrakt en in dielde wurkstasjon ûntkrêftsje allegear de oanname dat in boarne in persoan identifisearret. Behannelje de beheining as netwurkberik en hâld ferifiearre SMB-akkounts as de identiteitslaach, mei in apparaatbewiis lykas in sertifikaat as jo apparaatautorisisaasje nedich hawwe.

Dêrom ek beheint it ûntwerp dielingen en net de tsjinner. In wegere pear kin noch altyd in sesje iepenje, in oare dieling berikke of de tsjinner listje, wat in oare útkomst is as in ferifikaasjeflater by it ferbinen. As de eask ôfwizing foar ferifikaasje is, binne Samba syn dielingsparameters it ferkearde ark.

Bewiis it mei kruse pearen

Falidearje de konfiguraasje en test dan de fjouwer kombinaasjes mei nije ferbiningen ynstee fan in werbrûkte sesje. It bedoelde pear moat de map berikke, en beide kruse pearen moatte mislearje. In bewarre sesje fan in eardere test sil de ferkearde kombinaasje graach beantwurdzje en in brutsen regel korrekt lykje litte.

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

In syntakskontrôle bewize allinnich dat it bestân parsearre wurdt. Oanmeldgegevens, ACL's en de hostbeslissing wurde troch in echte ferbining útoefene, dus fiere de klantopdracht út fan it adres dat jo testje wolle en sjoch hokker stadium it ôfwiist. As in krús pear slagget, is de effektive hostlist breder as it blok suggerearret, en testparm -s is it earste dat lêzen wurde moat. As in krús pear om 'e ferkearde reden mislearret, is it akkount of de ACL de fertochte.

Sesjes monitorje mei smbstatus en se deadzje is in reaksje-aksje nei't tagong begon is, gjin talittingskontrôle. It blokkearjen fan in hiel observearre adres kin ek net-relatearre brûkers efter deselde NAT loskeppelje, en dêrom heart de beslissing yn 'e dielingsdefinysje en it monitoaren yn it reaksje-proses. Hâld de beide apart en it ûntwerp bliuwt earlik oer wat it ôftwingt.