یک ورود VPN روی رایانه مشترک: چه کس دیگری مسیر را می‌گیرد؟
ورود VPN یک نفر را احراز هویت می‌کند؛ مسیری که نصب می‌کند دامنهٔ دیگری است. تونل‌های سراسر میزبان، هر کاربر و هر برنامه را روی ماشین مشترک مقایسه کنید.
اشتراک یک ایستگاه کاری پرسشی را پیش می‌آورد که لپ‌تاپ تک‌کاربره هرگز مجبور نیست به آن پاسخ دهد: وقتی یک نفر تونل را احراز هویت کرد، چه کس دیگری می‌تواند از آن استفاده کند؟ ورود یک سوژه را شناسایی می‌کند و مسیری که نصب می‌کند دامنه‌ای را توصیف می‌کند، و این دو یک شیء نیستند. میان آن‌ها سیستم‌عامل، پیکربندی کارخواه و آنچه سرویس خصوصی خودش می‌طلبد قرار دارد. مقایسهٔ نقاط اجرا تنها راه پاسخ به این پرسش بدون حدس زدن است.
یک ورود، چندین دامنه
احراز هویت پاسخ می‌دهد چه کسی پذیرفته شد. مسیر پاسخ می‌دهد کدام بسته‌ها می‌توانند از تونل خارج شوند. مجوزدهی پاسخ می‌دهد کدام سرویس اتصال حاصل را می‌پذیرد، و هیچ‌یک از این سه دیگری را ایجاب نمی‌کند.
تونل سراسر میزبان پیش‌فرض رایج است و شکاف را آشکار می‌کند. مسیر در جدول هسته قرار دارد، پس هر فرایندی که از آن جدول استفاده می‌کند می‌تواند به شبکهٔ خصوصی برسد، حتی فرایندی که کاربری آغاز کرده که هرگز پنجرهٔ VPN را ندیده است. این نقص تونل نیست؛ معنای مسیر در سطح سیستم همین است. سرویس خصوصی هنوز می‌تواند اتصال را رد کند، و به همین دلیل دسترس‌پذیری و اجازه به پاسخ‌های جداگانه نیاز دارند.
نوشتن چهار پرسش پیش از آزمایش مانع از آن می‌شود که بازبینی به یکی از آن‌ها فروبکاهد.
مرز در واقع کجاست
چهار چیدمان بیشتر ماشین‌ها را پوشش می‌دهد: تونل سراسر میزبان، اتصال هر کاربر، فهرست مجاز هر برنامه و فضای نام شبکه یا ماشین مجازی جداگانه.
هر یک نقطهٔ اجرا را جای دیگری می‌گذارد و تفاوت‌ها از برچسب‌ها مهم‌ترند. اتصال هر کاربر با مجوزهای نمایه اجرا می‌شود، نه با صفحهٔ ورود رومیزی. فهرست مجاز هر برنامه درون کارخواه اجرا می‌شود که تصمیم می‌گیرد چه چیزی را حمل کند. فضای نام یا ماشین مجازی در مرز واسط اجرا می‌کند، پس فرایندی درون آن اصلاً مسیر میزبان را نمی‌بیند. شمار صفحه‌های ورود روی ماشین چیزی دربارهٔ هیچ‌یک از آن‌ها نمی‌گوید.
| Arrangement | Enforced by | Who can use the path |
|---|---|---|
| Host-wide tunnel | The routing table | Any local process using that table |
| Per-user connection | Profile permission list | Only the listed accounts |
| Per-app allowlist | The VPN client itself | Only the selected applications |
| Namespace or VM | The interface boundary | Only processes inside it |
خواندن جدول سطر به سطر نشان می‌دهد که پرسش واقعی این نیست که جداسازی وجود دارد یا نه، بلکه این است که کجا پیاده‌سازی شده است.
چهار نقطهٔ اجرا را مقایسه کنید
در Linux جدول مسیرها نخستین چیزی است که باید بررسی شود، چون تونل سراسر میزبان آنجا پدیدار می‌شود و فضای نام نه. اجرای جستجو به‌عنوان کاربر دوم همان گامی است که مردم از آن می‌گذرند؛ پاسخ با آنچه خودشان گرفتند تفاوت دارد و همین گزارش را توضیح می‌دهد.
دو بررسی بعدی به سیاست نگاه می‌کنند نه به مسیریابی. قاعدهٔ دیوار آتش که با UID مطابقت دارد بر ترافیک تولیدشدهٔ محلی اعمال می‌شود، پس می‌تواند دو کاربر را روی یک میزبان جدا کند حتی وقتی هر دو مسیر را شریک‌اند. نمایهٔ اتصال با فهرست مجوز صریح را مدیر شبکه هنگام فعال‌سازی اجرا می‌کند. هیچ‌یک از بررسی‌ها نیازمند تغییر تونل نیست، و به همین دلیل ارزش دارد پیش از هر بازطراحی انجام شوند.
ip route get 10.40.2.10
sudo -u bob ip route get 10.40.2.10
nmcli connection show vpn-work | grep -i permission
sudo nft list ruleset | grep -n skuidاگر جستجوی دوم مسیر تونل را نشان دهد، مرز آنجا نیست که طراحی فرض کرده بود.
قواعد نشست همزمان کنترلی جداگانه است
دروازه‌ها غالباً محدود می‌کنند که یک حساب چند نشست می‌تواند نگه دارد، و آن محدودیت هیچ ربطی به کاربران محلی ندارد. حساب را محدود می‌کند، پس نفر دومی که با همان اعتبارنامه وارد شود می‌تواند تونل نفر اول را قطع کند.
شکست را بخوانید پیش از آنکه مسئلهٔ جداسازی محلی را فرض کنید. محدودیت نشست در دروازه قطع ارتباط پدید می‌آورد، در حالی که مسئلهٔ دامنه تونلی کارکن پدید می‌آورد که صرفاً ترافیک کاربر دیگر را حمل نمی‌کند. این دو نشانه به اصلاح‌های کاملاً متفاوتی می‌رسند. پیام دقیق کارخواه را نگه دارید، چون معمولاً قاعده را نام می‌برد. از مالک نمایه گردش‌کار تأییدشده را بخواهید به‌جای دور زدن محدودیت.
ماشین مجازی هیچ‌کس را از آن قاعده معاف نمی‌کند و طرح شبکه و اعتبارنامهٔ خودش را می‌افزاید.
زمینه‌ای را که برایتان مهم است آزمایش کنید
کاربر و برنامهٔ موردنظر را آزمایش کنید، سپس زمینه‌ای را که باید رد شود. بازبینی‌ای که فقط ثابت می‌کند گذرواژهٔ اصلی کار می‌کند، احراز هویت را آزموده و هیچ چیز دیگر.
sudo -u bob curl -sS -m 5 https://intranet.internal/health
wg show
ss -tnp | grep -E ':443|:51820'نقطهٔ اجرا را کنار هر نتیجه ثبت کنید: جدول مسیرها، قاعدهٔ UID، مجوز نمایه یا سیاست نشست دروازه. آن ثبت تغییر بعدی را بازبینی‌پذیر می‌کند. همچنین مانع باز شدن دوبارهٔ همان پرسش می‌شود هر بار که کسی صفحهٔ ورود دومی را می‌بیند. دسترس‌پذیری مجوزدهی نیست و هیچ‌یک از این دو جداسازی نیست.