چرا یک TAP VPN اشتراکی هنوز به HTTPS روی پورتال نیاز دارد
یک TAP VPN همتا را احراز هویت می‌کند، نه سرویس پشت آن را. اعتبارسنجی نام میزبان را روی پورتال نگه دارید و همسایگانی را که به آن‌ها اعتماد ندارید جدا کنید.
دو دستگاه اعتبارنامه‌های معتبر VPN دارند و یک قطعه اترنت پل‌شده را مشترکاً استفاده می‌کنند. قرار است تنها یکی از آن‌ها به نمایندگی از پورتال دفتر پاسخ دهد، و دیگری همچنان می‌تواند آدرس پورتال را در آن قطعه ادعا کند. تونل کار خود را کرد: هر دو همتا را احراز هویت کرد و هر مسیر تا سرور را رمزگذاری کرد. کاری که نکرد این بود که تصدیق کند کدام‌یک مالک یک نام سرویس است، و همین شکاف دلیل آن است که پورتال هنوز به گواهی معتبر نیاز دارد.
VPN در واقع چه چیزی را احراز هویت می‌کند
دست‌دادن VPN به یک پرسش پاسخ می‌دهد: کدام همتا این تونل را و با چه مواد کلیدی کامل کرد. آن پاسخ به ازای هر همتا و هر اتصال است و درباره سرویس‌هایی که آن همتا بعداً ارائه می‌کند چیزی نمی‌گوید. در قطعه TAP، همتا حتی یک آدرس هم نیست، زیرا می‌تواند هر MAC و هر IP را که پل حاضر به یادگیری آن است ارائه دهد. احراز هویت در نقطه پایانی تونل متوقف می‌شود، نه در برنامه.
سه پرسش را از هم جدا کنید به جای اینکه آن‌ها را در یکی ادغام کنید. هر یک مکانیسم و حالت شکست خودش را دارد.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
یک استقرار می‌تواند تونلی کاملاً احراز هویت شده و سرویسی کاملاً بدون احراز هویت در پشت آن داشته باشد. همچنین می‌تواند گواهی تأییدشده‌ای روی میزبانی داشته باشد که آدرس لایه دوی آن توسط همتای دیگری ادعا می‌شود، و به همین دلیل هر دو کنترل باید در طراحی باشند نه اینکه یکی جای دیگری را بگیرد. جدول تمام استدلال در سه سطر است.
ARP در یک قطعه اشتراکی دفترچه راهنما نیست
ARP یک آدرس IPv4 را به یک MAC روی پیوند محلی نگاشت می‌کند و پاسخ‌ها را از هر کسی روی آن پیوند می‌پذیرد. در یک قطعه پل‌شده سهل‌گیر، همتا می‌تواند آدرسی را ادعا کند که به دستگاه دیگری تعلق دارد، و پل قاب‌ها را به کسی که آخرین بار پاسخ داده ارسال می‌کند. رمزگذاری هر مسیر مشتری تا سرور این را تغییر نمی‌دهد، زیرا قاب‌ها پیش از رسیدن به پل رمزگشایی می‌شوند. مرز اعتماد ARP همان قطعه است، نه تونل.
ببینید میزبان واقعاً چه یاد گرفته است: ip neigh show نگاشت‌های کنونی و وضعیت آن‌ها را فهرست می‌کند، و ورودی‌ای که در عملیات عادی بین دو آدرس MAC جابه‌جا می‌شود نشانه‌ای است که ارزش بررسی دارد نه نادیده گرفتن. در یک قطعه کوچک سالم، این ورودی‌ها مدت‌های طولانی پایدار می‌مانند.
جداسازی همتا و سیاست پل دقیقاً برای همین حالت وجود دارند. طراحی مسیریابی‌شده معمولاً پاسخ بهتر است وقتی سرویس فقط IP است و دستگاه‌ها هیچ دلیلی برای دیدن قاب‌های یکدیگر ندارند.
اعتبارسنجی گواهی را همان‌جا نگه دارید که سرویس هست
TLS برنامه به پرسشی پاسخ می‌دهد که تونل نمی‌تواند: آیا این همان سرویسی است که می‌خواستم به آن برسم. مرورگر نام میزبان را با گواهی بررسی می‌کند، و همین بررسی تنها بخشی از زنجیره است که پورتال را نام می‌برد نه همتا را.
پیش از آنکه هشدار را ظاهری بدانید، ببینید سرور چه چیزی ارائه می‌دهد. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal زنجیره و نام‌های جایگزین موضوع را چاپ می‌کند. اگر نامی که تایپ کرده‌اید در آن فهرست نیست، هشدار درست است و گواهی چیزی است که باید اصلاح شود. آموختن رد کردن آن به کاربران، یک کنترل کارآمد را به تزیین تبدیل می‌کند.
راهنمای پل‌سازی OpenVPN مدل اترنت و گزینه‌های سیاست پیرامون آن را توصیف می‌کند، و مرجع درست برای آن چیزی است که قطعه باید اجازه دهد. پیش از شل کردن یک قاعده پل آن را بخوانید، زیرا مدلی که توصیف می‌کند همان چیزی است که هر بررسی بالا فرض می‌کند.
تصمیم بگیرید که آیا این همتاها اصلاً باید یک قطعه را مشترک کنند
ارزان‌ترین اصلاح معمولاً این است که وقتی نیاز فقط دسترسی IP است، اشتراک‌گذاری لایه دو را متوقف کنید. یک VPN مسیریابی‌شده به هر مشتری آدرس خودش را می‌دهد، دامنه پخش اشتراکی را حذف می‌کند و ترافیک همتا به همتا را به یک تصمیم سیاستی به جای پیش‌فرض تبدیل می‌کند. آنگاه پورتال یک آدرس برای محافظت دارد و هیچ همسایه‌ای که بتواند آن را ادعا کند.
اگر قطعه باید بماند، تنظیم سمت سروری را که به مشتریان اجازه می‌دهد به هم برسند بررسی کنید: grep -n client-to-client /etc/openvpn/server.conf. وقتی غیرفعال است، ترافیک مشتری از سرور عبور می‌کند و می‌تواند همان‌جا فیلتر شود. وقتی فعال است، همتاها قاب‌ها را مستقیماً از طریق پل مبادله می‌کنند و نقاط فیلتر شما پل و دیوار آتش میزبان است.
بنویسید هر میزبان واقعاً به کدام محافظت‌ها تکیه دارد: احراز هویت تونل، جداسازی قطعه، یا TLS برنامه. میزبانی که به هر سه تکیه دارد خوب است. میزبانی که به اولی تکیه دارد و فرض می‌کند دو تای دیگر همراه آن آمده‌اند، همان کسی است که در نهایت محتوای اشتباه سرو می‌کند.