VGW یا TGW؟ تونل IPsec سرویس AWS Site-to-Site کجا تمام می‌شود

مردم می‌پرسند یک VPN سرویس AWS Site-to-Site کجا از محافظت بسته دست برمی‌دارد و یک پاسخ واحد انتظار دارند: در دروازه. نسخهٔ کاربردی آن پاسخ می‌گوید کدام دروازه، چون دروازهٔ خصوصی مجازی و دروازهٔ ترانزیت دو آرایش متفاوت با اشیای پیوست متفاوت‌اند و بازبینی که آرایش اشتباه را فرض کند، بقیهٔ ارزیابی را بر نموداری بنا می‌کند که وجود ندارد. سه بررسی زیر را به ترتیب انجام دهید. هر کدام یا مرز را تأیید می‌کند یا می‌گوید پاسخ قبلی دربارهٔ منبع دیگری بود.

پیش از ارزیابی هر چیزی سه نقطهٔ پایانی را نام ببرید

بازبینی رمزنگاری این مسیر به سه چیز نام‌برده نیاز دارد: دروازهٔ مشتری، هدف VPN در AWS که IPsec را پایان می‌دهد، و نقطهٔ پایانی برنامه که بستهٔ درونی را دریافت می‌کند. آن‌ها را همراه شناسهٔ منابعشان بنویسید، پیش از آنکه حتی یک صفحهٔ کنسول باز کنید، چون هر چیزی پس از این نقطه اظهارنظری دربارهٔ یکی از آن سه است.

دروازهٔ مشتری از شماست و پیکربندی آن برایتان قابل مشاهده است. هدف AWS یک منبع مدیریت‌شده است و خطا در فرض کردن آن است: اتصال VPN می‌تواند به یک دروازهٔ خصوصی مجازی یا مستقیماً به یک دروازهٔ ترانزیت پیوست شود و هیچ‌یک دیگری را ایجاب نمی‌کند. نقطهٔ پایانی سوم همان است که مردم از آن می‌گذرند و تنها نکته‌ای است که به پرسش واقعی دربارهٔ داده‌های برنامه پاسخ می‌دهد.

بررسی 1: کدام دروازه واقعاً تونل را پایان می‌دهد

هر دو آرایش پشتیبانی می‌شوند و راهنمای معماری Site-to-Site VPN آن‌ها را کنار هم توصیف می‌کند، پس از API بپرسید نه از نموداری که اغلب یک سال قدمت دارد. یک پرس‌وجوی فقط‌خواندنی روی یک اتصال فیلدهای هدف VPN را برمی‌گرداند:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

مشخص‌کننده TransitGatewayId است، نه VpnGatewayId. اتصالی که TransitGatewayId آن خالی است در یک دروازهٔ خصوصی مجازی مستقل پایان می‌یابد، در حالی که اتصالی که آن فیلد در آن تنظیم شده در پیوست VPN دروازهٔ ترانزیت، پایان می‌یابد و VpnGatewayId در آن حالت همچنان می‌تواند پر باشد چون می‌تواند دروازهٔ پشتیبان پیوست را نام ببرد. نخست فیلد TGW را بخوانید، سپس نوع پیوست را از فهرست پیوست‌ها تأیید کنید نه از نام فیلد، چون یک پیوست VPC روی آن دروازهٔ ترانزیت، پیوست VPN نیست. یافتن نمونهٔ مقصد در یک VPC متصل هیچ چیزی دربارهٔ اینکه کدام پیوست VPN بسته را حمل کرده به شما نمی‌گوید.

وقتی آنجا هستید، تونل‌ها را هم بررسی کنید. اتصال دو تونل IPsec برای افزونگی حمل می‌کند و اتصالی که تونل دوم آن هرگز بالا نیامده است، یافته‌ای واقعی برای دسترس‌پذیری است، حتی اگر چیزی در مرز رمزنگاری را تغییر ندهد:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

بررسی 2: بستهٔ درونی هنوز چه چیزی حمل می‌کند

وقتی IPsec پایان یافت، AWS بستهٔ کپسول‌گشایی‌شده را با مسیری که با آن مطابقت داشت ارسال می‌کند. از آن نقطه به بعد ترافیک، ترافیک عادی VPC است و محافظت VPN به پایان رسیده است. این شکافی در سرویس نیست؛ معنای مرز همین است و نکتهٔ فهرست بررسی این است که آن را صریح بگویید، نه اینکه بگذارید «VPN رمزنگاری‌شده است» جای «داده‌ها از سرتاسر رمزنگاری‌شده‌اند» را بگیرد.

اکنون بررسی کنید درون چه بود. اگر بستهٔ درونی یک پروتکل برنامه با متن ساده باشد، هیچ چیز در پایین‌دست محرمانگی اضافه نمی‌کند تا وقتی چیز دیگری آن را رمزنگاری کند. اگر بستهٔ درونی از پیش یک نشست TLS حمل کند، برداشتن IPsec بیرونی چیزی را برای آن نشست تغییر نمی‌دهد: تا نقطهٔ پایانی خودش محافظت‌شده می‌ماند، هر جا که آن نقطهٔ پایانی باشد.

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

بررسی 3: چه چیزی TLS را پشت دروازه پایان می‌دهد

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

نقطهٔ پایانی‌ای را که واقعاً برایتان مهم است از درون VPC آزمایش کنید، با نامی که برنامه به کار می‌برد نه با IP که یک بار تحلیل کرده‌اید:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

این را برای هر گامی که درخواست از آن می‌گذرد تکرار کنید. اگر پاسخ میان نام رو به مشتری و نام بک‌اند متفاوت باشد، دقیقاً همان بخشی را یافته‌اید که VPN هرگز پوشش نداد و همان یافته‌ای است که باید نوشته شود.

نتیجه را به‌صورت بخش‌ها ثبت کنید، نه به‌صورت حکم

خروجی این فهرست بررسی جدولی کوچک با یک ردیف برای هر بخش است: از دروازهٔ مشتری تا هدف VPN در AWS، از دروازه تا بار کاری، از بار کاری تا مخزن داده، و هر گام پروکسی در میان. هر ردیف می‌گوید چه چیزی از آن محافظت می‌کند و آن محافظت به چه چیزی وابسته است. «رمزنگاری‌شده» بدون سازوکار و بدون نقطهٔ پایانی یک ردیف نیست.

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

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