تونل کامل Access Server روی EC2: چرا یک کادر تیک کافی نیست

خاموش کردن بررسی مبدأ و مقصد روی یک نمونه EC2 پرتکرارترین پاسخ به پرسش‌های خروج اینترنت Access Server است و به‌تنهایی هیچ کاری برای کلاینت‌های شما نمی‌کند. این بررسی یک محدودیت ارسال در AWS است: باعث می‌شود نمونه بسته‌هایی را بپذیرد که مبدأ یا مقصدشان آدرس خودش نیست. به کلاینت Access Server نمی‌گوید ترافیک اینترنت را از تونل بفرستد، مسیری به سمت بالا ایجاد نمی‌کند و NAT اضافه نمی‌کند. افسانه این است که خود کادر تیک همان قابلیت است.

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

هر رابط شبکه EC2 ترافیکی را که به آن آدرس داده نشده دور می‌ریزد، مگر اینکه نمونه نقش روتر، دستگاه NAT یا دروازه VPN داشته باشد و شما آن بررسی را خاموش کنید. خاموش کردن آن اجازه ارسال می‌دهد. اجازه پیکربندی نیست: نمونه هنوز به مسیری به دروازه اینترنت یا دستگاه NAT نیاز دارد، جدول مسیر VPC هنوز به ورودی مطابق نیاز دارد، گروه‌های امنیتی هنوز باید جریان را مجاز کنند و سرور هنوز باید ترافیک برگشتی را ترجمه یا مسیریابی کند.

پیش از هر تغییری مقدار فعلی را با aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck بررسی کنید. اگر آن را در کنسول تغییر می‌دهید، به این دلیل تغییر دهید که نمونه برای دیگران ارسال می‌کند، نه به این دلیل که کلاینتی به اینترنت نمی‌رسد.

خط‌مشی مسیریابی کلاینت متعلق به Access Server است

در Access Server 3 بخش Access Controls را باز کنید و قسمت Internet Access and DNS را بیابید. انتخاب Internet Gateway تونل کامل یا تونل تقسیم‌شده را پیشنهاد می‌دهد؛ تونل کامل به کلاینت می‌گوید ترافیک پیش‌فرضش را به داخل VPN مسیریابی کند، تونل تقسیم‌شده ترافیک اینترنت را روی مسیر محلی کلاینت می‌گذارد. از طریق گردش‌کار محصول ذخیره و اعمال کنید، سپس یک کلاینت آزمایشی را دوباره وصل کنید، زیرا خط‌مشی در زمان اتصال تحویل داده می‌شود.

نسخه‌های قدیمی‌تر از منوهای متفاوت استفاده می‌کنند و برخی ساخت‌های Community از OpenVPN کنترل معادلی ندارند. پیش از جست‌وجوی صفحه‌ای که وجود ندارد، نسخه اصلی نصب‌شده را بررسی کنید. سپس تأیید کنید کلاینت چه دریافت کرد: نمایه تونل کامل باید مسیر پیش‌فرضی از تونل نصب کند و نمایه تونل تقسیم‌شده نباید چنین کند.

بسته را پس از تونل ردیابی کنید

وقتی کلاینت ترافیک اینترنت را به تونل می‌فرستد، سرور باید آن را ارسال و معمولاً ترجمه کند. Access Server قواعد NAT و مسیریابی خودش را مدیریت می‌کند، پس پیکربندی مؤثر را بخوانید، نه اینکه قواعد Community OpenVPN را به فایل‌های تولیدشده بیفزایید؛ قواعد مدیریت‌نشده در به‌روزرسانی بعدی محصول بازنویسی می‌شوند یا تعارض پیدا می‌کنند. sudo iptables -t nat -L -n -v یا معادل nftables نشان می‌دهد واقعاً چه چیزی ترجمه می‌شود.

سمت AWS مسیری جداست. نمونه در یک زیرشبکه عمومی مستقیماً به دروازه اینترنت می‌رسد و آدرس عمومی یا IP الاستیک خود را نگه می‌دارد. نمونه در زیرشبکه خصوصی به مسیری به دروازه NAT یا نمونه NAT نیاز دارد و دستگاه NAT به مسیر خودش به دروازه اینترنت نیاز دارد. اتصال دروازه اینترنت به VPC به‌خودی‌خود به هیچ مبدأ خصوصی آدرس بازگشت عمومی نمی‌دهد، به همین دلیل همان تنظیمات Access Server در یک زیرشبکه کار می‌کند و در دیگری بی‌صدا شکست می‌خورد.

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

خروج IP و DNS را جدا نگه دارید

نخست یک آدرس تحت‌اللفظی و سپس یک نام را از همان برنامه کلاینت آزمایش کنید. اگر curl -4 https://checkip.amazonaws.com آدرس عمومی برمی‌گرداند اما نام میزبان‌ها شکست می‌خورند، تونل و مسیر NAT کار می‌کنند و مشکل DNS است: resolver ارسال‌شده، وضعیت resolver کلاینت یا گروه امنیتی که resolver را مسدود می‌کند. تنظیمات DNS در Access Server در همان ناحیه Internet Access است، اما مسیر کد متفاوتی را طی می‌کند.

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

نگذارید یک کادر تیک تحقیق را ببندد

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

در پایان، وضعیت قطع‌شده را آزمایش کنید. انتخاب تونل کامل خط‌مشی مسیریابی در حالت متصل را توصیف می‌کند، نه آنچه هنگام افتادن تونل رخ می‌دهد. اگر الزام این است که هیچ ترافیکی بیرون از VPN نگریزد، این پرسش kill-switch و دیوار آتش است و به آزمون خودش نیاز دارد، نه استنتاجی از جدول مسیر.