Weka kikomo cha shiriki la Samba kwa mtumiaji mmoja na anwani moja ya VPN

Vigezo valid users na hosts allow vya Samba havioanishi mtu na anwani: majina mawili ya shiriki yanaweza kudhihirisha jozi hilo, na majaribio ya jozi zilizovukana yanathibitisha hilo.

Katika muundo huu ruhusa mbili tofauti zinachanganywa: nani anaweza kutumia saraka, na anwani zipi zinaweza kuunganishwa kabisa. Kuandika orodha ya akaunti kando ya orodha ya vyanzo huonekana kama uoanishaji, lakini Samba hutathmini orodha hizo mbili kama masharti huru. Yeyote anayetimiza yote mawili hukubaliwa, na hiyo ni kanuni pana kuliko inavyokusudiwa na wasimamizi wengi. Suluhisho ni mpangilio mwingine wa shiriki au tabaka la sera linaloweza kudhihirisha jozi hilo.

Hadithi: orodha mbili hutengeneza kanuni moja

Rejea ya smb.conf hufafanua valid users na hosts allow kama vigezo viwili visivyohusiana, na kuweka vyote viwili kwenye shiriki moja ndiko kunakoanzisha mkanganyiko. Weka valid users = mira, tomas na hosts allow = 10.77.0.21, 10.77.0.22 na michanganyiko minne hukubaliwa: Mira kutoka anwani yoyote, Tomas kutoka anwani yoyote. Hakuna chochote katika usanidi kinachofunga jina la kwanza na anwani ya kwanza, na mpangilio wa majina kuonekana hauna maana. Kuyapanga upya, kuongeza mstari wa pili wa hosts allow au kuweka jina moja kwa mstari hakubadilishi chochote. Matokeo ni zao la orodha mbili, si ramani kati yao.

Kile ambacho watu wengi wanataka kwa kweli ni chembamba zaidi: Mira kutoka anwani moja tu, Tomas kutoka nyingine tu. Ufafanuzi mmoja wa shiriki hauna sintaksia ya ufungaji huo, na hakuna mpangilio werevu unaouunda. Hiyo ni aina ya sera ambayo Samba haidhihirishi ndani ya shiriki moja, na hapo ndipo hadithi inaendelea kuishi.

Samba hutathmini nini, na kwa mpangilio gani

Hatua hupita kwa mpangilio maalum, na mpangilio mbaya hutoa utambuzi mbaya. Mteja hufungua muunganisho; ukaguzi wa jumla wa mwenyeji hufanyika ikiwa umesanidiwa; usanidi wa kikao huthibitisha akaunti; kisha mteja huunganishwa na shiriki, ambapo orodha yake ya wenyeji, valid users na mpangilio wa kusoma tu hutumika; na ni pale faili inapofunguliwa tu ndipo ruhusa za mfumo wa faili za utambulisho uliothibitishwa huamua. Kila hatua inaweza kukataa ombi yenyewe, na kupita moja haisemi chochote kuhusu inayofuata. Matokeo muhimu ni kwamba akaunti inajulikana tayari wakati orodha ya wenyeji ya shiriki inatathminiwa, na orodha ya wenyeji bado haina njia ya kutaja akaunti hiyo.

Ndiyo sababu shiriki haliwezi kufunga mtumiaji mmoja na anwani moja: hosts allow na valid users ni masharti tofauti yanayotumika katika hatua moja ya muunganisho wa mti, na kila moja hujibu swali lake. Sharti la mwenyeji huchukui jina la akaunti kama ingizo kamwe, kwa hivyo haliwezi kuandikwa kwa mtumiaji. Jozi hilo linaweza kudhihirishwa tu na shiriki la pili au tabaka la sera nje ya Samba.

Thamani za jumla ni muhimu kwa sababu ya namna zinavyorithiwa. Shiriki linaloacha hosts allow hurithi thamani ya jumla, na shiriki linaloweka yake mwenyewe hutumia thamani hiyo badala ya ile ya jumla, si kwa nyongeza. Hivyo orodha pana ya jumla hupanua shiriki zisizoweka kigezo kamwe, na haifanyi chochote kwa shiriki linalofafanua lake. Endesha testparm -s na usome thamani kwa kila shiriki inazochapisha, kwa sababu matokeo hayo ni sera inayofanya kazi, na faili iliyo kwenye diski siyo.

Kupunguza upana wa shiriki moja pia hakufanyi chochote kwa sehemu nyingine ya seva. Shiriki nyingine, foleni za kuchapisha na muunganisho wa IPC huhifadhi kanuni zao, kwa hivyo muundo unaotegemea orodha ya anwani za shiriki moja hulinda njia moja, si mwenyeji.

Majina mawili ya shiriki juu ya saraka moja

Wakati saraka hiyo hiyo inapaswa kufikiwa na watu wawili kutoka anwani mbili, iweke wazi mara mbili kwa majina tofauti. Kila kizuizi hubeba akaunti moja na chanzo kimoja, jambo linalofanya jozi hilo kuwa kitu ambacho usanidi unaweza kulazimisha. Gharama ni kwamba kila mtu hutumia jina tofauti la shiriki kufikia faili zile zile, na hilo lazima liwe badiliko la kusudi upande wa mteja.

[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

Lango la shiriki si ruhusa ya mfumo wa faili. Vitambulisho vyote viwili bado vinahitaji ufikiaji wa saraka kupitia ACL ya msingi, na mpangilio wa kusoma tu ni tabaka la pili, si la pekee. Toa ruhusa ya kuandika tu ikiwa mtiririko wa kazi unahitaji, kisha hakikisha faili zilizoundwa na utambulisho mmoja zinabaki zitumike kwa mwingine.

Vizuizi vyote viwili vinaelekeza kwenye njia moja, kwa hivyo badiliko katika saraka huathiri shiriki zote mbili. Kwa kawaida hilo ndilo lengo, lakini pia inamaanisha kosa la ruhusa linaonekana kwa watumiaji wote wawili kwa wakati mmoja.

Anwani ya chanzo inaweza kuthibitisha nini

Anwani ambayo Samba huiona ni anwani iliyofika kwenye seva, si ile ambayo mteja anadhani anayo. Lango la VPN linalotafsiri kila mteja kuwa anwani moja ya chanzo huondoa tofauti hiyo: wateja wote hufika kama mwenyeji mmoja na orodha ya vyanzo haiwezi kuwatofautisha tena. Ugawaji thabiti kwa kila mteja na lango linalohifadhi chanzo ni masharti ya awali ya kutumia anwani kama sera kabisa. Bila yote mawili, kikomo hupima lango, si mtumiaji.

Hata hivyo, anwani si kifaa. Kompyuta mpakato mbili nyuma ya anwani moja ya handaki, ukodishaji uliogawiwa upya na kituo cha kazi kinachoshirikiwa zote zinakanusha dhana kwamba chanzo humtambua mtu. Chukulia kikomo kama wigo wa mtandao na uendelee kuweka akaunti za SMB zilizothibitishwa kama tabaka la utambulisho, pamoja na kitambulisho cha kifaa kama cheti ikiwa unahitaji idhini ya kifaa.

Ndiyo sababu muundo hufunga shiriki na si seva. Jozi lililokataliwa bado linaweza kufungua kikao, kufikia shiriki lingine au kuorodhesha seva, ambayo ni matokeo tofauti na kushindwa kwa uthibitishaji wakati wa kuunganisha. Ikiwa hitaji ni kukataa kabla ya uthibitishaji, vigezo vya shiriki vya Samba ni chombo kisichofaa.

Thibitisha kwa jozi zilizovukana

Thibitisha usanidi, kisha jaribu michanganyiko minne kwa miunganisho mipya badala ya kikao kilichotumika tena. Jozi lililokusudiwa linapaswa kufikia saraka, na jozi zote mbili zilizovukana zinapaswa kushindwa. Kikao kilichohifadhiwa kutoka jaribio la awali kitajibu kwa furaha kwa michanganyiko isiyo sahihi na kufanya kanuni iliyovunjika ionekane sahihi.

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

Ukaguzi wa sintaksia huthibitisha tu kwamba faili inachanganuliwa. Vitambulisho, ACL na uamuzi wa mwenyeji hufanyiwa majaribio kwa muunganisho halisi, kwa hivyo endesha amri ya mteja kutoka anwani unayotaka kujaribu na uangalie hatua ipi inaikataa. Ikiwa jozi lililovukana linafanikiwa, orodha inayofanya kazi ya wenyeji ni pana kuliko kizuizi kinavyodokeza, na testparm -s ndicho kitu cha kwanza kusoma. Ikiwa jozi lililovukana linashindwa kwa sababu isiyo sahihi, akaunti au ACL ndiyo inayoshukiwa.

Kufuatilia vikao kwa smbstatus na kuvimaliza ni hatua ya majibu baada ya ufikiaji kuanza, si udhibiti wa kuingia. Kuzuia anwani nzima iliyozingatiwa kunaweza pia kukata watumiaji wasiohusiana nyuma ya NAT moja, ndiyo sababu uamuzi ni wa ufafanuzi wa shiriki na ufuatiliaji ni wa mchakato wa majibu. Weka mawili hayo tofauti na muundo unabaki mwaminifu kuhusu kile unacholazimisha.

Makala zinazohusiana