یک دروازه NAT در AWS رو به VPN از کدام IP مبدأ استفاده می‌کند؟

کنسول VPC را باز می‌کنید چون شریکی پرسیده است کدام محدوده مبدأ از طریق VPN سایت‌به‌سایت می‌رسد. صفحه دروازه‌های NAT یک دروازه عمومی با Elastic IP متصل نشان می‌دهد و وسوسه آن است که همان نشانی را بفرستید و جلو بروید. این پاسخ درست برای مسیر اینترنت و پاسخ نادرست برای مسیر VPN است و تفاوت در این است که جدول مسیریابی به کدام دروازه اشاره می‌کند. مسیر را پیش از نوشتن فهرست مجاز قدم بزنید.

از صفحه دروازه‌های NAT شروع کنید، نه از فهرست مجاز

صفحه دروازه‌های NAT زیرشبکه، نوع و Elastic IP را به شما می‌گوید و این سه فیلد برای شروع کافی است. آنچه نمی‌گوید مسیری است که ترافیک بعد از آن طی می‌کند. این از جدول‌های مسیریابی متصل به زیرشبکه دروازه NAT می‌آید.

نخست نوع را بخوانید، چون عمومی یا خصوصی بودن تعیین می‌کند آیا بعداً دروازه اینترنت در زنجیره ظاهر می‌شود. سپس زیرشبکه را بخوانید، چون مسیر دوم همان‌جا است.

دو ترجمه را دنبال کنید

هم دروازه‌های NAT عمومی و هم خصوصی مبدأ IPv4 خصوصی بار کاری را به نشانی IPv4 خصوصی خود دروازه NAT ترجمه می‌کنند. این ترجمه نخست بدون توجه به نوع رخ می‌دهد. ترجمه دوم همان است که فراموش می‌شود: دروازه NAT عمومی ترافیک را به دروازه اینترنت می‌سپارد و آن نشانی را به Elastic IP متصل نگاشت می‌کند.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

در مسیر خصوصی هیچ دروازه اینترنتی در زنجیره نیست. وقتی ترافیک از طریق دروازه گذر یا دروازه خصوصی مجازی خارج می‌شود، راهنمای دروازه NAT نشانی خصوصی دروازه NAT را به‌عنوان مبدأیی که طرف دور دریافت می‌کند مستند می‌کند. همان نشانی است که شریک باید مجاز کند، نه Elastic IP.

مسیر VPN معمولاً نشانی خصوصی را نشان می‌دهد

برای بار کاری در 10.20.1.0/24 که به پیشوند شریک می‌رسد، جدول مسیریابی زیرشبکه بار کاری به دروازه NAT و جدول مسیریابی زیرشبکه دروازه NAT به مسیر دروازه خصوصی اشاره می‌کند. هر دو گام مهم‌اند و تنها دومی تعیین می‌کند شریک چه می‌بیند. اگر زیرشبکه NAT هیچ مسیری به مسیر VPN نداشته باشد، بسته هرگز نمی‌رسد و این شکستی متفاوت از نشانی مبدأ نادرست است.

پیش از هر گفتگو درباره نشانی‌ها همان مسیر دوم را بررسی کنید. مسیر غایب و مبدأ اشتباه گزارش‌شده برای شریکی که به‌سادگی ترافیکی نمی‌بیند کاملاً یکسان به نظر می‌رسند.

وقتی ترجمه دومی پاسخ را تغییر می‌دهد

AWS همچنین نگاشت NAT صریح و متناظر یک‌به‌یک روی یک پیوست دروازه گذر ارائه می‌دهد. آن نگاشت می‌تواند مبدأ را دوباره ترجمه کند پیش از آنکه سرویس دور آن را ببیند و این رفتار پیش‌فرضی که فقط مسیریابی می‌کند نیست. چون باید آگاهانه پیکربندی شود، آن را استثنای طراحی بدانید نه چیزی که تصادفاً به ارث می‌برید. اگر هیچ‌کس در تیم شما به یاد نمی‌آورد آن را روشن کرده باشد، تا خواندن پیوست آن را غایب فرض کنید.

اگر طراحی شما از آن استفاده می‌کند، فهرست مجاز باید نگاشت نهایی را توصیف کند نه نشانی دروازه NAT را. همان احتیاط برای مسیرهای دسترس‌پذیری هم صادق است: وقتی چند نشانی دروازه مشارکت دارند، مجموعه مبدأ مورد انتظار اجتماع آن‌هاست نه یک نشانی نماینده. بنویسید هر نشانی به کدام ترجمه تعلق دارد، چون فهرست بدون منشأ بعداً قابل حسابرسی نیست.

به یک دروازه NAT خصوصی نمی‌توان با نشانه‌رفتن به دروازه اینترنت سرویس اینترنت داد؛ AWS مستند می‌کند که چنین ترافیکی دور ریخته می‌شود. نوع را از مسیر کامل انتخاب کنید، نه از واژه VPN در نیازمندی.

قراردادی بنویسید که شریک شما بتواند بر اساس آن عمل کند

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

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

سپس پس از هر تغییری هر دو جدول مسیریابی را دوباره بررسی کنید، چون پیوست جدید یا زیرشبکه‌ای که دوباره مرتبط شده پاسخ را بی‌صدا بازنویسی می‌کند.