محدود کردن یک اشتراک 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 را نیز قطع کند، به همین دلیل تصمیم به تعریف اشتراک تعلق دارد و پایش به فرایند واکنش. این دو را جدا نگه دارید تا طراحی درباره آنچه اعمال می‌کند صادق بماند.