بررسی مبدأ/مقصد یک دروازه است، نه تمام مسیر VPN
نمونهٔ ارسال‌کننده به مجوز AWS و همچنین مسیرهای Linux و قواعد دیوار آتش نیاز دارد. بررسی مبدأ/مقصد را روی نمونه‌ای که ارسال می‌کند انجام دهید.
تونل VPN روی یک نمونهٔ EC2 پایان می‌یابد، شما می‌توانید به نشانی تونل آن نمونه برسید، و ترافیکی که باید از آن به سمت یک میزبان خصوصی دیگر عبور کند ناپدید می‌شود. این‌ها دو آزمون متفاوت‌اند و آمیختن آن‌ها ساعت‌ها تلف می‌کند. آزمون اول می‌پرسد آیا به نمونه می‌رسید؛ دومی می‌خواهد که برای مقصدی که مال خودش نیست ترافیک ارسال کند، و این به ارسال در Linux، یک سیاست دیوار آتش، یک مسیر در طرف دور و مجوزی در سطح AWS نیاز دارد که هیچ ارتباطی با سیستم‌عامل مهمان ندارد. هیچ چیز در کنسول توجه را به این تفاوت جلب نمی‌کند. نشانه شبیه خطای مسیریابی است و معمولاً چنین نیست.
پیش از تغییر هر چیزی دو آزمون را جدا کنید
رسیدن به دروازه، تونل، مسیر تا نشانی آن و گروه امنیتی که تبادل را مجاز می‌کند را اثبات می‌کند. ارسال برای میزبان دیگر هیچ‌یک از این‌ها را اثبات نمی‌کند: از نشانی مبدأ متفاوت، مقصد متفاوت و نمونه‌ای در نقشی استفاده می‌کند که لزوماً برای آن ساخته نشده است. دو آزمون را جداگانه بنویسید و یادداشت کنید کدام شکست می‌خورد، زیرا اصلاح هر یک در کنسول دیگری است. نمونهٔ دروازه‌ای که فقط برای پایان دادن به تونل‌ها ساخته شده دلیلی برای ارسال برای چیز دیگری ندارد و پیش‌فرض‌هایش این را نشان می‌دهند. به همین دلیل آزمون دوم به راه‌اندازی خودش نیاز دارد، نه اصلاح کوچکی در اولی.
پینگی که به دروازه کار می‌کند و پینگی که به میزبان آن‌سو شکست می‌خورد، مشکل گاه‌به‌گاه نیست. این رفتار مورد انتظار نمونه‌ای است که به آن گفته نشده می‌تواند ارسال کند.
پیش از دست زدن به هر تنظیمی مسیر را بنویسید
پیشوند مشتری، نمونه یا واسط شبکهٔ ارسال، زیرشبکهٔ هدف و مسیر پاسخ را ثبت کنید. یک ورودی در جدول مسیرهای VPC که به یک نمونه اشاره می‌کند، سیستم‌عامل آن نمونه را برای ارسال پیکربندی نمی‌کند، و هستهٔ مهمان با ارسال فعال‌شده مسیری در VPC ایجاد نمی‌کند. هر دو سر این رابطه باید وجود داشته باشد، و آن‌ها در جاهای مختلف توسط افرادی با دسترسی متفاوت ویرایش می‌شوند.
سپس تنظیم بررسی مبدأ/مقصد را روی همان مؤلفهٔ ارسال واقعی بررسی کنید، نه روی هر نمونه در VPC. AWS توضیح می‌دهد چرا نمونه‌ای که ترافیک دیگران را ارسال می‌کند باید این بررسی را غیرفعال داشته باشد، و نیز چرا این تنظیم تصمیمی برای هر نمونه است و نه پیش‌فرضی برای کل VPC.
چهار مرز، و بررسی تنها یکی از آن‌هاست
مسیر را چهار پرسش بدانید و به ترتیب به آن‌ها پاسخ دهید. نخستین پاسخ شکست‌خورده جایی است که کار در آن است و هیچ‌یک از بقیه آن را جبران نمی‌کند.
| Boundary | Question it answers |
|---|---|
| VPC route tables | Do the destinations and replies select the intended gateway? |
| Forwarding instance | Do the AWS check and the guest OS both permit forwarding? |
| Access policy | Do security groups, ACLs and host rules allow the exchange? |
| Destination | Can the service accept that source and return a reply? |
ترتیب مهم است زیرا بررسی ارزان است: مسیرها در یک صفحه دیده می‌شوند، بررسی یک ویژگی است و نظر مقصد معمولاً آخرین چیزی است که کسی می‌پرسد.
ترجمه تغییر می‌دهد که مقصد کدام مبدأ را می‌بیند
طرح مسیریابی‌شده نشانی مبدأ مشتری را حفظ می‌کند، پس مقصد به مسیر بازگشت به پیشوند مشتری نیاز دارد. طرح ترجمه‌شده در عوض نشانی دروازه را ارائه می‌دهد، که آن نیاز را حذف می‌کند و آن را با جدول وضعیت روی دروازه جایگزین می‌کند. بر اساس معماری مورد نظر تصمیم بگیرید، نه اینکه ترجمه را اضافه کنید چون مثالی نامرتبط از آن استفاده کرده و کارآمد به نظر می‌رسیده.
اگر ترجمه می‌کنید، قاعده را به پیشوند مشتری و مقصد مورد نظر محدود کنید. اگر حفظ می‌کنید، تأیید کنید که طرف دور واقعاً مسیر را می‌داند، نه اینکه فرض کنید آن را یاد خواهد گرفت.
از مشتری اصلی آزمون بگیرید و سپس تغییر را نگه دارید
درخواستی که روی دروازه ساخته می‌شود می‌تواند موفق شود در حالی که درخواست ارسال‌شده شکست می‌خورد، زیرا مبدأ متفاوت و حالت ارسال متفاوتی است. پس از اصلاحی هدفمند، همان آزمون مشتری به منبع را که شکست خورده بود، از همان مشتری تکرار کنید و تأیید کنید که پاسخ برمی‌گردد، نه فقط اینکه درخواست رسیده است.
در پایان، تنظیم را در پیکربندی مدیریت‌شدهٔ دروازه قرار دهید تا نمونهٔ جانشین آن را دریافت کند. آزمون موفقی که به یک استثنای دستی وابسته است آزمونی است که در بازسازی بعدی منقضی می‌شود، و کسی که آن را کشف کرده برای یادآوری دلیل آنجا نخواهد بود.