دسترسی متناوب در AWS Client VPN: هر زیرشبکه متصل را بررسی کنید
برخی نشست‌های AWS Client VPN به VPC برنامه می‌رسند و برخی دیگر به پایان مهلت می‌خورند. ابتدا مسیرهای نقطه پایانی را با جدول مسیر VPC هر اتصال مقایسه کنید.
یک کاربر وصل می‌شود، برنامه داخلی را باز می‌کند و پاسخ می‌گیرد؛ همکاری روی همان نقطه پایانی از یک لپ‌تاپ یکسان در همان Wi-Fi مهلت تمام‌شدن می‌گیرد. این الگو امضای یک نقطه پایانی client VPN با بیش از یک زیرشبکه متصل است، جایی که مسیرها هم‌ارز نیستند. من این را از کنسول به بیرون دنبال می‌کنم، چون دو زبانه تعیین می‌کند که بقیه بررسی ارزش انجام دادن دارد یا نه. هیچ چیز در پیکربندی کلاینت این را توضیح نمی‌دهد.
از نقطه پایانی شروع کنید و اتصال‌ها را فهرست کنید
در کنسول VPC، Client VPN endpoints را باز کنید، نقطه پایانی را انتخاب کنید و زبانه Associations را بخوانید. هر اتصال یک زیرشبکه در یک منطقه دسترس‌پذیری است و کلاینت روی همانی فرود می‌آید که سرویس هنگام ساخت اتصال انتخاب می‌کند. شناسه زیرشبکه‌ها و جدول مسیری را که هرکدام واقعاً استفاده می‌کند یادداشت کنید، چون این دو فهرست همان مقایسه‌ای است که می‌خواهید انجام دهید.
اگر نقطه پایانی فقط یک اتصال نشان دهد، این نظریه غلط است و کلاینت مظنون بهتر است.
جدول مسیر نقطه پایانی را با هر اتصال مقایسه کنید
زبانه Route table را روی همان نقطه پایانی باز کنید. هر CIDR مقصد در آنجا یک هدف دارد و در client VPN هدف یک اتصال است نه دروازه. AWS برای هر زیرشبکه متصل یک ورودی مقصد لازم دارد، پس مسیری که فقط یکی از آن‌ها را هدف بگیرد دسترسی را به این وابسته می‌کند که نشست کجا فرود آمده است. مقصدی را که واقعاً برایتان مهم است بررسی کنید و سپس قاعده مجوز آن را، چون مسیر راه را فراهم می‌کند و قاعده تعیین می‌کند چه کسی می‌تواند از آن استفاده کند.
وقتی هر دو لایه را جدول‌بندی کنید، دیدن خرابی سخت است.
| Associated subnet | Endpoint route to 10.200.0.0/16 | VPC route in that subnet |
|---|---|---|
| subnet-aaa | Targets the association | 10.200.0.0/16 to pcx-example |
| subnet-bbb | Targets the association | No matching entry |
سطر دوم در بیشتر تیکت‌ها کل باگ است. مسیر نقطه پایانی وجود دارد، پس هیچ‌کس جلوتر را نگاه نمی‌کند، و بسته یک گام بعد داخل VPC می‌میرد.
هر زیرشبکه را تا جدول مسیر مؤثرش دنبال کنید
زیرشبکه‌ای که اتصال صریح به جدول مسیر ندارد، جدول اصلی VPC را به ارث می‌برد. جدولی را بخوانید که واقعاً در نیرو است، نه جدولی که نامش درست به نظر می‌رسد، و مقصد و هدف را مقایسه کنید نه برچسب سطر را.
راهنمای AWS درباره دسترسی متناوب این را پوشش مسیر در سراسر اتصال‌ها می‌داند، که مدل درستی است. نقطه پایانی بسته را به یک زیرشبکه می‌رساند و جدول آن زیرشبکه هنوز باید بداند شبکه برنامه کجاست.
سطر گمشده را در جدولی که مالک آن است درست کنید. کپی کردن کل جدول مسیر از یک زیرشبکه سالم، انتخاب‌های اینترنت، تجهیز و جداسازی را هم کپی می‌کند که هرگز برای این یکی در نظر گرفته نشده بودند، و این معامله معمولاً بدتر از همان قطعی است که با آن شروع کردید.
قواعد مجوز را بررسی کنید، سپس مسیر بازگشت
قواعد مجوز برای هر مقصد و هر گروه است و جدا از مسیرها ارزیابی می‌شود. مقصدی که همه‌جا مسیر دارد اما برای گروه کاربر قاعده‌ای ندارد مانند یک سیاه‌چاله با جدول مسیر سالم رفتار می‌کند.
مسیر بازگشت هم همین توجه را می‌طلبد. یک اتصال peering به مسیری در VPC برنامه نیاز دارد که به CIDR کلاینت برگردد، به قواعد گروه امنیتی که ترافیک را در دو سر اجازه می‌دهند، و به ACLهای شبکه که آن را دور نریزند. دسترس‌پذیری یک‌طرفه، جایی که ping کار می‌کند و دست‌دادن TCP نه، معمولاً به ACL یا گروه امنیتی اشاره می‌کند نه به VPN.
گروه‌های امنیتی خود نقطه پایانی روی رابط‌های شبکه کشسان اتصال قرار دارند، پس قاعده‌ای که پورت برنامه را از CIDR کلاینت اجازه می‌دهد باید به اتصال متصل شود، نه فقط به نمونه.
با اتصال مجدد تأیید کنید، نه با یک درخواست شانس‌آور
با split tunnel، مسیرهای نقطه پایانی هنگام برقراری اتصال فرستاده می‌شوند، پس مجموعه مسیر تغییرکرده هرگز به کلاینتی که متصل می‌ماند نمی‌رسد. اتصال را قطع و از طریق کلاینت پشتیبانی‌شده دوباره وصل کنید، سپس تأیید کنید مسیرهای جدید روی دستگاه وجود دارند.
در پایان، گزارش اتصال را با آدرسی که کلاینت دریافت کرده تطبیق دهید و آزمون را به‌قدر کافی تکرار کنید تا به بیش از یک اتصال بربخورید. یک درخواست موفق پس از اصلاح ثابت می‌کند یک مسیر کار می‌کند، و تیکت درباره دیگری بود.