AWS Client VPN با تونل تقسیم‌شده: کدام مسیرها را منتشر کنید
تونل تقسیم‌شده یک فهرست مسیر است، نه یک کادر انتخاب. تعیین کنید ترافیک اینترنت کجا می‌رود، کدام پیشوندهای خصوصی منتشر شوند و از کدام resolver استفاده شود.
کنسول یک کلید برای تونل تقسیم‌شده ارائه می‌دهد، پس تصمیم مثل یک کادر انتخاب به نظر می‌رسد. اما نیست. آنچه واقعاً به کلاینت می‌رسد مجموعه مسیرهای منتشرشده نقطه پایانی است، و همان فهرست تعیین می‌کند کدام پیشوندهای خصوصی از تونل استفاده کنند، ترافیک عمومی اینترنت محلی بماند یا از AWS خارج شود، و کلاینت هنوز با کدام resolver بتواند صحبت کند. سه پرسش طراحی را روشن می‌کند، و به هر یک می‌توان بد پاسخ داد در حالی که اتصال همچنان برقرار می‌شود.
پرچم تونل تقسیم‌شده فهرست مقصد نیست
AWS تونل تقسیم‌شده را چنین توصیف می‌کند: افزودن مسیرهای نقطه پایانی به جدول مسیر کلاینت هنگام برقراری اتصال. مسیر VPC خصوصی تونل را به همان مقصد محدود می‌کند؛ هر چیز دیگر مسیر معمول کلاینت را دنبال می‌کند. مسیر پیش‌فرض دستور دیگری با اثر دیگری است، به همین دلیل مستندات تونل تقسیم‌شده از انتشار 0.0.0.0/0 روی نقطه پایانی که برای این حالت پیکربندی شده هشدار می‌دهد: این کار معمولاً اتصال را می‌شکند نه اینکه گسترش دهد. جدول مسیر نقطه پایانی سیاست است، و جدول مسیر کلاینت نتیجه‌ای است که می‌توانید بررسی کنید.
جدول مسیر نقطه پایانی و مسیرهای نصب‌شده کلاینت را با هم بخوانید. برچسب یک قصد را توصیف می‌کند؛ مسیرها آنچه رخ می‌دهد را توصیف می‌کنند.
تصمیم یکم: آیا ترافیک عمومی اینترنت باید محلی بماند؟
اگر قرار است مرور وب از اتصال خود کاربر استفاده کند، فقط مقصدهای خصوصی مورد نیاز کار را منتشر کنید و همان‌جا متوقف شوید. مسیر اینترنت را به این دلیل که یک آموزش تونل کامل یکی داشت اضافه نکنید، و فرض نکنید مسیر اضافی امنیت را بهتر می‌کند. مسیر را عوض می‌کند، سیاستی اضافه نمی‌کند و معمولاً تأخیری هزینه دارد که در بودجه نگنجانده بودید.
اگر ترافیک اینترنت باید از AWS خارج شود، معماری مستندشده دسترسی اینترنت را بسازید: مسیر نقطه پایانی، قواعد مجوز، مسیر زیرشبکه مرتبط، سیاست امنیتی و یک خروجی بالادستی فعال. مسیر پیش‌فرض به تنهایی هیچ‌یک از این‌ها را فراهم نمی‌کند.
تصمیم دوم: کدام پیشوندهای خصوصی و با مجوز چه کسی؟
کوچک‌ترین مجموعه مقصد که بار کاری واقعی را پوشش می‌دهد منتشر کنید، و بررسی کنید که هر زیرشبکه مرتبط بتواند به آن‌ها مسیریابی کند. هدف مسیر نقطه پایانی و مسیریابی VPC زیرشبکه لایه‌های متفاوتی هستند و مسیر موجود در یکی دلیل دیگری نیست. مجوز دوباره جدا است: مقصد می‌تواند در دسترس باشد و همچنان رد شود چون گروه کلاینت قاعده‌ای ندارد که آن را مجاز کند.
آزمایش یک جلسه موفق فقط یک مسیر را اثبات می‌کند. هر زیرشبکه مرتبط را بررسی کنید، زیرا ارتباط زیرشبکه‌ای که بعداً اضافه شده دقیقاً جایی است که مسیر گمشده معمولاً در آن قرار دارد.
وقتی مقصدی باید با نام در دسترس باشد، توجه کنید که پرسش بعدی حل نام است، نه مسیر.
تصمیم سوم: کدام resolver از تونل پیروی می‌کند؟
کلاینت ممکن است سرور DNS را دریافت کند که فقط از طریق VPN در دسترس است، و آن resolver تنها وقتی کار می‌کند که آدرسش خودش داخل مسیر مجاز باشد. هر دو نیمه را بررسی کنید: آدرس resolver از یک مسیر منتشرشده پیروی می‌کند و سرور به نام‌هایی که برنامه می‌پرسد پاسخ می‌دهد. درخواستی که با آدرس موفق می‌شود اما با نام میزبان شکست می‌خورد به نام‌گذاری اشاره دارد نه مسیریابی، و اشکال‌زدایی تونل در آن حالت بعدازظهر را هدر می‌دهد.
نام‌های عمومی باید همان‌گونه که پیش از اتصال حل می‌شدند حل شوند، که دلیل دیگری برای دقیق بودن درباره چیزی است که منتشر می‌کنید.
مجموعه مسیرها را تغییر دهید، سپس هر دو جهان را بررسی کنید
AWS مستند می‌کند که تغییر مسیرها روی نقطه پایانی با تونل تقسیم‌شده اتصال‌های کلاینت را بازنشانی می‌کند. تغییر را با این نکته برنامه‌ریزی کنید: اعمالش کنید، از طریق کلاینت پشتیبانی‌شده دوباره متصل شوید و مسیرهای نصب‌شده را از نو بخوانید به‌جای اعتماد به وضعیتی که پیش از ویرایش اعمال شده بود. وضعیت اعمال‌شده کهنه شایع‌ترین دلیل به‌نظر شکسته آمدن یک تغییر درست است.
طراحی را فقط وقتی بپذیرید که یک منبع خصوصی و یک مقصد عمومی هر دو آن‌گونه که مقصود است رفتار کنند، با نام و با آدرس، در خانواده‌های آدرسی که واقعاً پشتیبانی می‌کنید. تونلی که احراز هویت می‌کند با تونلی که درست تقسیم می‌کند یکی نیست.
فهرست مسیرها را در runbook کنار استدلال بنویسید تا نفر بعدی بتواند استثنای عمدی را از استثنای فراموش‌شده تشخیص دهد.