شبکه LAN در پشت یک نشست AWS Client VPN: چه چیزی عبور داده می‌شود

لپ‌تاپ به نقطه پایانی AWS Client VPN متصل می‌شود، به زیرشبکه خصوصی می‌رسد و همه‌چیز سالم به نظر می‌رسد. رایانه رومیزی در همان LAN به هیچ جا نمی‌رسد، هرچند میزبان Linux هم یک رابط پل دارد و هر دو دستگاه روی یک سیم هستند. هیچ چیز در تونل اشتباه پیکربندی نشده است؛ قطعه گمشده مسیریابی است و پل یک رد گمراه‌کننده است.

گسترش یک نشست Client VPN به LAN یک نقش دروازه است. این یک قطعه Ethernet کشیده‌شده در یک سرویس مدیریت‌شده نیست.

میزبان کار می‌کند و LAN نه

رابط تونل روی دستگاه Linux آدرسی درون CIDR کلاینت Client VPN دارد و نقطه پایانی مسیرهایی برای محدوده‌های VPC فرستاده است. درخواستی که روی آن دستگاه انجام می‌شود ترافیک تولیدشده محلی است: یک مسیر انتخاب می‌کند، از تونل خارج می‌شود و پاسخی می‌گیرد. آن مسیر هرگز به کد عبوردهی، رابط LAN یا هیچ قاعده فایروالی که عبور را کنترل می‌کند دست نمی‌زند.

ترافیک از دستگاه دیگری در LAN جریان متفاوتی است. به رابط LAN می‌رسد، به مسیری نیاز دارد که به تونل اشاره کند، به عبوردهی فعال نیاز دارد، به فایروالی نیاز دارد که آن را مجاز کند و به این نیاز دارد که پاسخ از همان میزبان برگردد. چهار شرط، و آزمون موفق لپ‌تاپ هیچ‌یک را اثبات نمی‌کند. از دید رایانه رومیزی خرابی عجیب به نظر می‌رسد: تونل بالاست، اعتبارنامه‌ها معتبرند و مقصد به‌سادگی هرگز پاسخ نمی‌دهد. نقص محلی است در مسیر عبوردهی دروازه، نه در سرویس.

هر کلاینتی نمی‌تواند دروازه باشد

AWS اعلام می‌کند که برنامه رومیزی Client VPN آن از عبوردهی IP پشتیبانی نمی‌کند و کلاینت‌های دیگر ممکن است پشتیبانی کنند. این محدودیت معماری را پیش از تایپ هر فرمانی تعیین می‌کند. اگر تنها کلاینت در دسترس برنامه رسمی رومیزی باشد، دروازه Linux که برای LAN عبور می‌دهد پیکربندی‌ای نیست که بتوانید تمام کنید و هیچ مقدار masquerading آن را تغییر نمی‌دهد.

کلاینت جایگزین هم باید با روش احراز هویت نقطه پایانی و سیاستی که قصد اعمال آن را دارید سازگار باشد. نقاط پایانی مبتنی بر گواهی، دایرکتوری و SAML پیکربندی‌های کلاینت یکسانی را نمی‌پذیرند و کلاینت شخص ثالثی که احراز هویت می‌کند اما مسیرهای فرستاده‌شده را نادیده می‌گیرد بهبود نیست.

انتخاب کلاینت را بخشی از بازبینی طراحی بدانید. تعیین می‌کند که الگوی عبوردهی LAN اصلاً در دسترس است یا نه و تعیین می‌کند نقطه پایانی چه هویتی را برای هر دستگاه پشت دروازه می‌بیند. کلاینت و پیکربندی نقطه پایانی را که در برابر آن آزمون شده ثبت کنید. تعویض کلاینت شش ماه بعد می‌تواند قابلیتی را که طراحی فرض کرده بود بی‌صدا حذف کند.

LAN را به تونل هدایت کنید و ترجمه کنید

با وجود یک کلاینت پشتیبانی‌شده، بقیه کار عادی دروازه است. دستگاه‌های LAN به مسیری برای محدوده VPC نیاز دارند که به میزبان Linux اشاره کند و میزبان به عبوردهی فعال نیاز دارد. اگر می‌خواهید VPC ترافیک را به‌عنوان کلاینت متصل ببیند و نه به‌عنوان یک آدرس LAN دلخواه، منبع را در خروج ترجمه کنید.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

قاعده را به رابط تونل و محدوده VPC محدود کنید، همان‌طور که بالا آمد، به‌جای masquerading هر چیزی که میزبان عبور می‌دهد. قاعده باریک‌تر آسان‌تر قابل استدلال است و بی‌صدا ترافیکی را تغییر نمی‌دهد که قرار بود آدرس منبع اصلی خود را حفظ کند.

اگر می‌توانید بگذارید مسیر LAN خودکار بیاید: یک گزینه DHCP، یک اعلام روتر یا یک مسیر ایستا که توسط چیزی که LAN را مدیریت می‌کند فرستاده شود. مسیری که فقط روی یک دستگاه آزمایشی وجود دارد طراحی را در همان لحظه‌ای که کس دیگری امتحانش کند خراب نشان می‌دهد.

پاسخ هم به مسیر نیاز دارد

وقتی درخواست به VPC می‌رسد، پاسخ باید از همان حالت‌های ترجمه برگردد و مسیر LAN را روی دروازه پیدا کند. این بخش معمولاً وقتی قاعده masquerade سر جایش باشد کار می‌کند، چون نگاشت روی همان میزبانی زندگی می‌کند که آن را انجام داد. وقتی سمت VPC مسیری داشته باشد که پاسخ را جای دیگری بفرستد می‌شکند، و به همین دلیل هم مسیر CIDR کلاینت و هم پیوند زیرشبکه روی نقطه پایانی اهمیت دارند.

شمارنده‌ها را ببینید، نه فقط ping را. قاعده masquerade با صفر بسته به شما می‌گوید درخواست هرگز به رابط تونل نرسیده است، که به مسیر LAN یا جدول مسیریابی خود کلاینت برمی‌گردد. قاعده‌ای با بسته اما بدون پاسخ به سمت VPC، قواعد مجوز یا یک گروه امنیتی اشاره می‌کند که منبع ترجمه‌شده را نمی‌پذیرد. پیش از تغییر هر چیزی هر دو جهت را بخوانید، چون شمارشی که فقط در یک طرف رشد می‌کند مسیر یک‌طرفه است نه کند.

به یاد داشته باشید نقطه پایانی یک سرویس مدیریت‌شده است. فایل پیکربندی سروری برای ویرایش و دستور client-config برای افزودن وجود ندارد، پس دستورالعمل‌هایی که برای سرور OpenVPN خودمدیریتی با مسیرهای زیرشبکه کلاینت سفارشی نوشته شده‌اند منتقل نمی‌شوند. در AWS اهرم‌ها پیوند زیرشبکه، قواعد مجوز و جدول‌های مسیریابی VPC هستند.

هویت مشترک بخشی است که سیاست باید به آن پاسخ دهد

هر دستگاه پشت دروازه از نشست VPN دروازه استفاده می‌کند. قواعد مجوز نقطه پایانی به یک کاربر یا گروه دسترسی می‌دهند و از دید سرویس دقیقاً یک کاربر روی آن نشست وجود دارد. عبوردهی محلی آن هویت را به احراز هویت هر دستگاه تکثیر نمی‌کند و بررسی‌های وضعیت دستگاه را تا چاپگر گوشه گسترش نمی‌دهد.

این ممکن است پذیرفتنی باشد یا دلیل رد شدن طراحی. به آنچه منابع VPC درباره اینکه چه کسی تماس می‌گیرد فرض می‌کنند بستگی دارد. هویت مشترکی که با مدل مجوز سازگار است خوب است؛ هویتی که بی‌صدا یک نشست احراز هویت‌شده را به دسترسی سراسری LAN تبدیل می‌کند یافته‌ای است که منتظر نوشته شدن است.

اگر الزام واقعاً اتصال یک سایت کامل به VPC است، پیش از گسترش یک کلاینت دسترسی از راه دور یک طراحی سایت‌به‌سایت پشتیبانی‌شده را مقایسه کنید. معناشناسی متفاوت است و نشست کلاینت NAT‌شده جایگزین ضعیفی برای پیوند سایت است وقتی VPC باید اتصال‌ها را به LAN آغاز کند.

کلاینت، مسیر، ترجمه و داستان هویت را به همین ترتیب تصمیم بگیرید. هر کدام بعدی را محدود می‌کند و ترتیب توضیح می‌دهد چرا میزبان کار می‌کند در حالی که LAN نه.