Абмежаваць агульны рэсурс 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, таму рашэнне належыць вызначэнню рэсурсу, а маніторынг — працэсу рэагавання. Трымайце іх асобна, і дызайн застанецца сумленным адносна таго, што ён забяспечвае.