AWS Client VPN متصل است اما اینترنت ندارد: بررسی مسیرها
AWS Client VPN متصل است ولی به اینترنت دسترسی ندارد؟ مسیرهای کلاینت، مجوز نقطه پایانی، خروجی زیرشبکه و DNS را به همین ترتیب بررسی کنید.
شما به نقطه پایانی AWS Client VPN متصل هستید، زیرشبکه خصوصی پاسخ می‌دهد، و با این حال هر صفحه عمومی به پایان مهلت می‌رسد. این ترکیب مشکل را به یکی از سه شیء در سمت مدیریت‌شده محدود می‌کند: مسیری که کلاینت نصب می‌کند، مسیر نقطه پایانی همراه با قاعده مجوز آن، یا پرش بعدی زیرشبکه مرتبط. من آن‌ها را به همین ترتیب بررسی می‌کنم، چون هر خرابی از دید کلاینت متفاوت به نظر می‌رسد. این راهنما نقطه پایانی مدیریت‌شده مرتبط با VPC را پوشش می‌دهد، نه سرور OpenVPN روی یک نمونه EC2 و نه اتصال Cloud WAN یا Transit Gateway.
با آنچه کلاینت واقعاً مسیریابی می‌کند شروع کنید
وضعیت متصل بودن، نشست TLS و تخصیص CIDR به کلاینت را اثبات می‌کند، نه چیز بیشتری. از سیستم‌عامل بپرسید یک آدرس عمومی وقتی تونل بالاست به کجا می‌رود. در Linux، ip route get 1.1.1.1 باید رابط تونل را نام ببرد؛ در macOS، netstat -rn -f inet | head -5 ورودی پیش‌فرض را نشان می‌دهد؛ در Windows، Find-NetRoute -RemoteIPAddress 1.1.1.1 رابط انتخاب‌شده و پرش بعدی را چاپ می‌کند.
سپس پرچم تونل تقسیم‌شده را بخوانید، چون تعیین می‌کند آیا مسیرهای منتشرشده نقطه پایانی تنها مقاصد ارسالی کلاینت به تونل هستند یا نه:
aws ec2 describe-client-vpn-endpoints \
--client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
--query 'ClientVpnEndpoints[0].SplitTunnel'وقتی SplitTunnel برابر true است، یک مقصد عمومی تنها زمانی از تونل استفاده می‌کند که نقطه پایانی مسیری منتشر کرده باشد که آن را پوشش دهد، بنابراین 0.0.0.0/0 غایب آن ترافیک را روی رابط محلی باقی می‌گذارد. وقتی false است، کلاینت ترافیک را می‌گیرد، اما نقطه پایانی هنوز باید آن را مسیریابی و مجاز کند؛ وگرنه بسته‌ها به تونل وارد می‌شوند و همان‌جا می‌مانند. پس از تغییر هر یک از دو تنظیم، کلاینت را دوباره متصل کنید، چون مسیرها و سرورهای DNS در زمان اتصال تحویل داده می‌شوند و کلاینت در حال اجرا می‌تواند مجموعه قدیمی خود را نگه دارد.
مسیر نقطه پایانی و قاعده مجوز را جداگانه بخوانید
این‌ها دو شیء هستند و ساختن یکی دیگری را نمی‌سازد. مسیرهای نقطه پایانی را فهرست کنید و مسیر پیش‌فرضی را جستجو کنید که مقصدش یک زیرشبکه مرتبط است:
aws ec2 describe-client-vpn-routes \
--client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0هر مسیر دقیقاً یک زیرشبکه مقصد دارد، پس سه ارتباط هر یک به مسیر پیش‌فرض متناظر نیاز دارند. AWS این شرط پوشش را مستند می‌کند، و نشانه عملی یک شکاف کاربری است که از یک زیرشبکه کار می‌کند و از دیگری گیر می‌کند، که به عنوان یک خرابی متناوب خوانده میشود نه مسیر گم‌شده. مستندات رسمی سناریوی Client VPN چیدمان زیرشبکه عمومی را که این مسیرها به آن تعلق دارند توصیف می‌کند.
مجوز شیء دوم است. وقتی هیچ قاعده‌ای مقصد عمومی را پوشش نمی‌دهد، تونل بسته را حمل می‌کند و سرویس آن را دور می‌ریزد، بنابراین منابع خصوصی کار می‌کنند در حالی که اینترنت نه:
aws ec2 describe-client-vpn-authorization-rules \
--client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0یک قاعده برای CIDR مربوط به VPC درباره 0.0.0.0/0 چیزی نمی‌گوید. افزودن قطعات گم‌شده برای یک تونل کامل یعنی یک مسیر به ازای هر زیرشبکه مرتبط به‌علاوه یک قاعده مجوز که بعداً می‌توانید آن را حسابرسی کنید:
aws ec2 create-client-vpn-route \
--client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
--destination-cidr-block 0.0.0.0/0 \
--target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
--client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
--destination-cidr-block 0.0.0.0/0 \
--access-all \
--description "internet egress for full tunnel"--access-all مقصد را به هر کلاینت نقطه پایانی اعطا می‌کند، پس آن را فقط تا زمانی که تونل باید کامل باشد نگه دارید؛ قاعده‌ای که به یک گروه دایرکتوری بسته شده باشد زمانی ترجیح دارد که گروه‌هایی برای بستن دارید.
بسته را از زیرشبکه مرتبط به بیرون دنبال کنید
مسیر نقطه پایانی تعیین می‌کند که AWS بسته را به آن زیرشبکه تحویل می‌دهد. پرش بعدی پس از آن را تعیین نمی‌کند، که در جدول مسیرهای VPC خود زیرشبکه زندگی می‌کند:
aws ec2 describe-route-tables \
--filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
--query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'یک مسیر پیش‌فرض قابل استفاده برای یک زیرشبکه عمومی به دروازه اینترنت و برای یک زیرشبکه خصوصی به دروازه NAT اشاره می‌کند، و وضعیت blackhole یعنی مقصد حذف شده و مسیر اکنون بی‌صدا می‌میرد. این‌ها جدول‌هایی متفاوت از فهرست مسیرهای نقطه پایانی هستند و تعمیر یکی دیگری را تعمیر نمی‌کند.
دو فیلتر روی این پرش قرار دارند. گروه امنیتی اعمال‌شده روی ارتباط شبکه مقصد باید ترافیک خروجی به سمت مقصد عمومی را مجاز کند، و هر ACL شبکه قابل اعمال باید درخواست و ترافیک بازگشتی روی پورت‌های موقت را مجاز کند. گروه امنیتی محدودکننده ارتباط دلیل رایجی است که دسترسی خصوصی کار می‌کند و عمومی نه.
لایه اول را از روی نشانه انتخاب کنید، نه اینکه هر سه را همزمان تغییر دهید:
| What you observe | Layer to check first |
|---|---|
| No tunnel interface for a public IP | Client route or split-tunnel flag |
| Tunnel interface chosen, request times out | Endpoint route and authorization rule |
| Endpoint route present, still times out | Subnet route table, association security group |
| Named host fails, numeric address works | DNS servers and their own authorization |
خرابی DNS را از مسیر مرده جدا کنید
تفکیک نام متفاوت از ارسال خراب میشود، و تونل کامل این تفاوت را مهم می‌کند چون اکنون به حل‌کننده تحت‌فشار از طریق تونل دسترسی پیدا میشود. اگر نقطه پایانی سرورهای DNS مربوط به VPC را مشخص کند، آدرس‌هایشان مانند هر مقصد دیگری به پوشش مسیر و مجوز نیاز دارند. مستقیماً از حل‌کننده بپرسید تا ببینید کدام خرابی را دارید: dig +short example.com @10.0.0.2 یا nslookup example.com 10.0.0.2 در Windows.
وقتی یک URL عددی پاسخ می‌دهد و یک نامی نه، ویرایش مسیر پیش‌فرض را متوقف کنید و روی DNS کار کنید. درخواست به یک آدرس IP چیزی درباره یک میزبان مجازی نامی و گواهی‌اش اثبات نمی‌کند، پس یک آزمون نامی را در بررسی نهایی نگه دارید.
زمان‌بندی کمک می‌کند. اتصال TCP که در چند ثانیه پاسخی نمی‌گیرد به مسیریابی یا یک فیلتر اشاره می‌کند، در حالی که درخواستی که داخل جستجوی نام معلق می‌ماند به حل‌کننده اشاره می‌کند. تغییر مسیر پیش‌فرض در حالی که حل‌کننده در دسترس نیست معمولاً یک خرابی را به دو تبدیل می‌کند.
تمیز به عقب برگردید، سپس مسیر خروج را بررسی کنید
هر دو شیء افزودنی بودند، پس بازگشت حذف است نه تعمیر:
aws ec2 delete-client-vpn-route \
--client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
--destination-cidr-block 0.0.0.0/0 \
--target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
--client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
--destination-cidr-block 0.0.0.0/0 \
--access-allدوباره متصل شوید و تأیید کنید ترافیک از کدام مسیر خارج میشود. آدرس عمومی مشاهده‌شده را با آدرس IP کشسان دروازه NAT یا با دروازه اینترنتی که قصد استفاده از آن را داشتید مقایسه کنید و بررسی کنید که یک منبع خصوصی هنوز در همان نشست پاسخ می‌دهد.
با یک فهرست کوتاه تمام کنید و آخرین مورد را بخشی از تغییر بدانید نه مستندسازی:
- یک
0.0.0.0/0مسیر نقطه پایانی برای هر زیرشبکه مرتبط. - یک قاعده مجوز که
0.0.0.0/0را برای کلاینت‌هایی که می‌خواهید به آن‌ها خدمت کنید پوشش دهد. - یک مسیر پیش‌فرض VPC که در وضعیت blackhole نیست، روی هر زیرشبکه مرتبط.
- خروجی گروه امنیتی ارتباط، به‌علاوه ترافیک بازگشتی ACL.
- آدرس‌های حل‌کننده مسیریابی و مجاز شده، با یک درخواست نامی تأیید شده.
- بازگشت ثبت‌شده برای مسیر و قاعده.
یک نکته دامنه: این یک مسیر IPv4 است. کلاینت دوپشته هر اتصال IPv6 که از قبل دارد را حفظ می‌کند، پس مسیر پیش‌فرض IPv6 تصمیمی جداگانه با مجوز خودش است نه عارضه جانبی این یکی.