AWS Client VPN وصل است اما EC2 هنوز پاسخ نمی‌دهد

لپ‌تاپ من می‌گفت وصل است. کلاینت AWS Client VPN وضعیت سبز خود را نشان می‌داد، endpoint یک نشست ثبت کرد و با این حال نمی‌توانستم پورت MongoDB را روی یک نمونه EC2 در یک زیرشبکه خصوصی باز کنم. هیچ چیز آشکارا خراب نبود: گواهی معتبر بود، پروفایل از کنسول آمده بود و تونل ترافیک را حمل می‌کرد. اشتباه از من بود، چون وصل را به معنای مجاز می‌خواندم.

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

بررسی‌های زیر همان ترتیبی است که اکنون به کار می‌برم.

یک نشست متصل در واقع چه چیزی را اثبات می‌کند

در هنگام دست‌دادن، endpoint گواهی کلاینت را با trust store خود اعتبارسنجی می‌کند، یا وقتی SAML پیکربندی شده باشد مرورگر را به ارائه‌دهنده هویت شما هدایت می‌کند. اگر این بگذرد، کلاینت نشانی‌ای از CIDR کلاینت endpoint می‌گیرد و کنسول اتصال فعال را نشان می‌دهد. در هیچ نقطه‌ای از این تبادل چیزی نمی‌پرسد که آیا می‌توانید به 10.0.4.17 روی پورت 27017 برسید.

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

قاعده مجوزدهی را با منبع مقایسه کنید، نه با VPC

قواعد را فهرست کنید و آن‌ها را کنار نشانی‌ای بگذارید که نمونه واقعاً دارد:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

خروجی برای هر قاعده یک CIDR مقصد و یک شناسه گروه نشان می‌دهد. دو خرابی در آن پنهان است. قاعده ممکن است 10.0.0.0/16 را مجاز کند در حالی که نمونه در VPC همتا روی 10.1.0.0/16 قرار دارد؛ مسیر peering وجود دارد، اما هیچ‌کس قاعده مجوزدهی برای محدوده دوم ننوشته است. یا قاعده به گروهی در دایرکتوری اشاره می‌کند که کاربر در دایرکتوری عضو آن است اما در گروهی که endpoint ارزیابی می‌کند نیست.

تنگ‌ترین قاعده‌ای را بنویسید که مقصد را پوشش می‌دهد و قاعده دوم را فقط وقتی اضافه کنید که CIDR دوم واقعاً لازم است. قاعده گسترده 0.0.0.0/0 از یک شروع سریع کار می‌کند و به همین دلیل تا تولید زنده می‌ماند و مدل را پنهان می‌کند.

دو جدول مسیر تعیین می‌کنند که بسته حرکت می‌کند یا نه

یک مسیر endpoint یک CIDR مقصد را به یکی از زیرشبکه‌هایی که endpoint به آن‌ها مرتبط است نگاشت می‌کند. این نیمی از راه است. جدول مسیر خود زیرشبکه هنوز باید بداند چگونه بسته را هدایت کند و این همان لحظه‌ای اهمیت دارد که مقصد پشت یک اتصال peering، یک transit gateway یا محدوده‌ای محلی است که از طریق تونل site-to-site در دسترس است.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

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

یک تنظیم سمت کلاینت مسیریابی را می‌شکند بی‌آنکه تونل را بشکند: پروفایلی که route-nopull دارد. این دستور به کلاینتی مبتنی بر OpenVPN می‌گوید مسیرهایی را که سرور هل می‌دهد نادیده بگیرد، بنابراین رابط فقط با نشانی خود endpoint بالا می‌آید و مقصد به سادگی مسیری ندارد. با ip route show در Linux یا netstat -rn در macOS بررسی کنید که مسیری از رابط tun وجود دارد یا نه. اگر نیست، route-nopull را از پروفایل صادرشده بردارید و دوباره وصل شوید تا مسیرهای هل‌داده‌شده اعمال شوند.

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

این همان بخشی است که یک بعدازظهر اشتباه گرفتم. برای یک endpoint IPv4 مرتبط با یک زیرشبکه، سرویس نشانی مبدأ کلاینت را به نشانی رابط شبکه endpoint در آن زیرشبکه ترجمه می‌کند. بسته‌ای که به نمونه می‌رسد نشانی‌ای را که کلاینت شما نشان داده بود حمل نمی‌کند، پس قاعده‌ای در گروه امنیتی که استخر کلاینت، مثلاً 172.16.0.0/22، را مجاز می‌کند با هیچ چیز تطبیق ندارد.

پورت را از گروه امنیتی endpoint که به رابط انجمن متصل است مجاز کنید، نه از CIDR کلاینت. ارجاع به گروه پایدارتر از سخت‌کد کردن نشانی است، چون نشانی رابط در اختیار شما نیست. ACLهای شبکه بی‌حالت‌اند، پس هر جا ورودی سفارشی وجود دارد، هم جهت ورودی و هم جهت خروجی باید جریان را مجاز کنند.

به نشانی خصوصی نمونه هم وصل شوید. یک IP عمومی بسته را از VPC بیرون می‌برد و از مسیری دیگر با قواعد دیگر برمی‌گرداند، پس آزمون از نشانی عمومی هیچ چیزی درباره مسیر خصوصی نمی‌گوید.

ترتیب جداسازی‌ای که در نخستین شکست می‌ایستد

این‌ها را به ترتیب پیش ببرید و هر جا یکی شکست خورد بایستید. هر گام یک لایه را کنار می‌گذارد نه همه را.

1. تأیید کنید نشست از کدام هویت استفاده کرد و endpoint کدام گروه را ارزیابی می‌کند. گواهی از یک trust store همان موجودیتی نیست که یک گزاره SAML از دایرکتوری است.
2. تأیید کنید قاعده‌ای مجوزدهی CIDR منبع را برای آن گروه پوشش می‌دهد.
3. تأیید کنید مسیر endpoint وجود دارد و به زیرشبکه‌ای مرتبط اشاره می‌کند، سپس تأیید کنید جدول مسیر زیرشبکه می‌تواند جلوتر برود.
4. تأیید کنید گروه امنیتی پورت را از رابط endpoint مجاز می‌کند نه از استخر کلاینت.
5. از داخل VPC با یک نشست SSM روی نمونه‌ای دیگر در همان زیرشبکه آزمایش کنید تا مشکل برنامه را از مشکل مسیر کلاینت جدا کنید.

وقتی گام‌ها قطعی نیستند، به این جدول تکیه می‌کنم:

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

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