AWS Client VPN یا bastion برای رسیدن به VPC همتا

یک endpoint از Client VPN می‌تواند به VPC برسد که با VPC مرتبطش peering دارد، و برای مشروع کردن آن به bastion نیازی نیست. انتخابی که ارزش انجام دادن دارد این است که ترافیک کجا دست به دست می‌شود: یک مسیر endpoint که در سابنت association فرود می‌آید و اتصال peering را می‌گذراند، یا یک host در VPC همتا که نشست را پایان می‌دهد. هر دو مسیر کار می‌کنند و در جاهای متفاوتی شکست می‌خورند، پس تصمیم درباره مالکیت و حسابرسی است نه درباره آنچه AWS اجازه می‌دهد. اینجا می‌آید چگونه بین آنها انتخاب می‌کنم، و چهار ورودی که مسیر مسیریابی‌شده را کار می‌اندازند.

دو مسیر، یک endpoint، مالکان متفاوت

در مسیر مسیریابی‌شده، ترافیک کلاینت به endpoint می‌رسد، به آدرس واسط شبکه Client VPN در سابنت association ترجمه می‌شود و از آن سابنت از طریق اتصال peering از A به B خارج می‌شود. VPC B هیچ نشست VPN را پایان نمی‌دهد؛ ترافیک معمول از VPC A را می‌بیند، به همین دلیل مسیر بازگشتش به VPC A اشاره می‌کند نه به استخر کلاینت.

در مسیر bastion، کلاینت نخست به یک host می‌رسد. bastion در A هنوز آخرین پرش را از اتصال peering می‌گذراند، پس کار peering را نگه می‌دارید و یک نشست اضافه می‌کنید. bastion در B هم به مسیری از کلاینت نیاز دارد، و وقتی آن مسیر همان مسیر endpoint باشد، طراحی مسیریابی‌شده به‌علاوه یک پرش دارید. bastion تنها زمانی کار را کم می‌کند که از پیش وجود داشته باشد، از پیش تأیید شده باشد، و چیزی که پشت آن است به مرز نشست نیاز داشته باشد نه مرز شبکه.

چهار ورودی مسیر مسیریابی‌شده را کار می‌اندازند

AWS این سناریو را در صفحه Client VPN how-it-works مستند می‌کند، و در عمل به چهار ورودی می‌رسد که دو یا سه تیم مالک آن هستند. بازه‌ها نمونه‌اند؛ بازه همتا باید یکتا باشد و بازه بازگشت باید با طرح شما بخواند.

مسیر و مجوز دو کنترل جدا هستند. مسیر endpoint درست بدون قاعده مجوزسازی منطبق چیزی به کلاینت نمی‌دهد؛ قاعده مجوزسازی برای مقصدی که endpoint نمی‌تواند مسیریابی کند به آن یک چاله سیاه می‌دهد. هر دو باید همان بازه را نام ببرند.

مسیر endpoint به سابنتی در VPC خود endpoint اشاره می‌کند، هرگز به اتصال peering. جدول‌های مسیر VPC به اتصال peering اشاره می‌کنند، هرگز به یک instance یا واسط. کپی کردن یک مقدار بین این دو بدون هیچ شکایتی ذخیره می‌شود و هیچ چیز را مسیریابی نمی‌کند.

چون سابنت association مبدأ کلاینت را ترجمه می‌کند، B باید به VPC A بازگردد نه به استخر کلاینت. فرستادن بازه کلاینت روی اتصال peering متقارن به نظر می‌رسد، بازبینی را می‌گذراند و بی‌صدا شکست می‌خورد چون B هرگز بسته‌ای با مبدأ کلاینت نمی‌بیند.

گروه‌های امنیتی و آخرین متر مجوز

مسیریابی بسته‌ها را به B می‌رساند؛ B همچنان تصمیم می‌گیرد. برای یک اتصال peering فعال در همان منطقه، یک گروه امنیتی در B می‌تواند به گروهی که روی association مربوط به Client VPN اعمال شده ارجاع دهد، که قاعده را باریک نگه می‌دارد و در برابر تغییر آدرس‌ها دوام می‌آورد. جایی که ارجاع به گروه شدنی نیست، بازه سابنت association را صریحاً مجاز کنید به‌جای گسترش به 0.0.0.0/0، که یک خطای مسیریابی را به یک timeout بی‌توضیح تبدیل می‌کند.

سپس چیزهایی را بررسی کنید که مسیریابی هرگز لمس نمی‌کند: ACLهای شبکه روی هر دو سابنت، فهرست مجاز برنامه یا مخاطب توکن، و DNS. peering زون‌های میزبانی‌شده خصوصی را کپی نمی‌کند، پس لپ‌تاپ می‌تواند مسیر کارآمدی به آدرسی داشته باشد که نمی‌تواند حل کند، و اتصال peering هیچ اعتمادی به گواهی اضافه نمی‌کند. endpoint را به resolverی که برای B پاسخ می‌دهد اشاره دهید، سپس تأیید کنید که نام خصوصی و گواهی می‌خوانند.

وقتی bastion پاسخ صادق است

سه محرک برای انتخاب آگاهانه bastion نگه می‌دارم. VPC همتا مال تیمی است که مسیر بازگشتی برای بازه شما اضافه نمی‌کند یا ارجاع به گروه را نمی‌پذیرد. دسترسی باید برای هر نشست تأیید یا ثبت شود و برنامه نمی‌تواند خودش آن را حمل کند. یا آخرین پرش باید داخل B بماند چون سرویس فقط همان‌جا حل می‌شود و هویت TLS آن به یک نام داخلی سنجاق شده است.

هیچ‌یک از این‌ها دور زدن این واقعیت نیست که peering ترانزیتی نیست. غیرترانزیتی بودن محدود می‌کند که منابع در B چه می‌توانند بکنند: نمی‌توانند از A به‌عنوان ترانزیت به VPC سومی استفاده کنند که A با آن peering دارد. این هرگز به معنای آن نبود که کاربر VPN نمی‌تواند به VPC همتای مستقیم برسد، و bastionای که برای دور زدن این خوانش غلط ساخته شود hostای است که بی‌دلیل patch می‌شود.

خطای معکوس در طول زمان بیشتر هزینه دارد: هر تیم را از تنها bastion موجود عبور دهید، سپس بفهمید که گروه امنیتی، جدول مسیر و پنجره patch آن وابستگی تولید است. بنویسید host به کدام محرک خدمت می‌کند، و وقتی محرک رفت آن را بازنشسته کنید.

Transit Gateway و چند association حساب را تغییر می‌دهند

اگر endpoint به‌جای سابنت مستقیماً به Transit Gateway متصل باشد، مدل تغییر می‌کند: کلاینت‌ها دیگر به آدرس واسط در سابنت association ترجمه نمی‌شوند و جدول‌های مسیر gateway باید بازه کلاینت به‌علاوه اتصالی که به VPC همتا می‌رود را حمل کنند. این در مقیاس تمیزتر است، اما کار از چهار ورودی به جدول‌های مسیر gateway منتقل می‌شود.

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

ترتیب بررسی که شکست را سریع پیدا می‌کند

این‌ها را به ترتیب اجرا کنید؛ هر گام می‌تواند بگذرد در حالی که گام بعدی شکست می‌خورد، و timeout کلاینت تقریباً هرگز نمی‌گوید کدام شکست.

1. نام برنامه را از کلاینت حل کنید و بررسی کنید آدرس داخل بازه همتاست.
2. متصل شوید، سپس گزارش اتصال‌های endpoint را برای associationای که نشست را پایان داد بخوانید.
3. روی آن سابنت association تأیید کنید که جدول مسیر بازه همتا را به یک اتصال peering فعال اشاره می‌دهد.
4. روی سابنت منابع در B، یک ورودی بازگشت برای بازه واسط و قواعد گروه منطبق را تأیید کنید.
5. یک عملیات مجاز و یک منبعی که باید غیرقابل‌دسترس بماند را آزمون کنید؛ دومی بازمانده‌های اشکال‌زدایی را می‌گیرد.
6. پس از هر تغییر مسیر split-tunnel دوباره متصل شوید، چون تونل در حال اجرا مجموعه مسیر جدید را نمی‌گیرد.

دو نشانه ارزش به‌خاطرسپردن دارند. SYNای که بدون پاسخ به B می‌رسد تقریباً همیشه مسیر بازگشت گمشده است. اتصالی که کامل می‌شود و سپس بازنشانی می‌شود معمولاً گروه، ACL یا برنامه است. هیچ‌یک در گزارش endpoint به‌عنوان علت دیده نمی‌شود، پس چهار ورودی را با مالکی کنار هر یک نگه دارید.

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