چرا GRE و ESP از دروازه NAT در AWS عبور نمی‌کنند

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

مجموعه قواعد مجموعه پروتکل‌ها نیست

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

مشخصات پروتکل دروازه NAT از AWS برای سرویس مدیریت‌شده TCP، UDP و ICMP را فهرست می‌کند. این کل مجموعه پشتیبانی‌شده است. یک قاعده مجاز برای پروتکل IP دیگر نمی‌تواند آن را گسترش دهد، زیرا قاعده مدت‌ها پیش از رسیدن به مسیر ارسال دروازه ارزیابی می‌شود.

این تمایز مهم است زیرا دو شکست از دید کلاینت یکسان به نظر می‌رسند و اصلاح‌های کاملاً متفاوتی دارند.

PPTP نشان می‌دهد چرا تست پورت دروغ می‌گوید

PPTP روشن‌ترین مثال قدیمی از بررسی پورتی است که چیزی را اثبات نمی‌کند. یک اتصال کنترل TCP روی پورت 1723 باز می‌کند و سپس داده‌های تونل را روی GRE حمل می‌کند که پروتکل IP 47 است. پروتکل 47 پورت TCP 47 نیست و این دو عدد هیچ ارتباطی با هم ندارند جز اشتراک در ارقام.

اپراتوری که اتصال به 1723 را آزمایش می‌کند و یک دست‌دادن کامل می‌بیند نتیجه می‌گیرد که مسیر کار می‌کند. سپس کانال داده هرگز حتی یک بسته را عبور نمی‌دهد، زیرا دروازه هیچ پشتیبانی GRE برای ارائه ندارد. این تفسیری از الزامات یک پروتکل قدیمی است، نه توصیه‌ای برای استقرار PPTP که سال‌هاست منسوخ شده است.

همین استدلال برای هر پروتکلی صدق می‌کند که کانال کنترل آن TCP یا UDP است در حالی که مسیر داده آن چنین نیست.

IPsec فقط به‌صورت UDP زنده می‌ماند

IPsec موردی است که پاسخ در آن مشروط است نه یک نه قاطع. AWS عبور از NAT را به‌عنوان ترتیب پشتیبانی‌شده برای IPsec از طریق دروازه NAT مستند می‌کند. با NAT-T مذاکره‌شده، ESP در UDP کپسوله می‌شود و دروازه UDP عادی را به‌جای پروتکل 50 می‌بیند.

اجازه دادن به UDP 4500 باعث نمی‌شود نقاط پایانی از عبور NAT استفاده کنند. فقط بسته‌ها را مجاز می‌کند اگر از قبل به آن شکل درآمده باشند. از خروجی مذاکره خود کلاینت تأیید کنید کدام کپسوله‌سازی انتخاب شده است و در سمت گیرنده تأیید کنید که همتا آن را پذیرفته است. دو نقطه پایانی که برای ESP بومی پیکربندی شده‌اند بدون توجه به آنچه مجموعه قواعد می‌گوید به ارسال ESP بومی ادامه می‌دهند.

یک VPN مبتنی بر TCP یا UDP با مجموعه انتقال مستند سازگار است و باز هم می‌تواند به دلایل مسیریابی، فیلتر کردن یا احراز هویت شکست بخورد. سازگاری با مجموعه لازم است، نه کافی.

قبل از گسترش سیاست، مسیر را بررسی کنید

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

سپس نقطه پایانی تلاش‌شده، خانواده آدرس، پروتکل بیرونی و پورتی که پروتکل دارد را ثبت کنید. از تشخیص‌های کلاینت و مشاهدات جریان مالک شبکه استفاده کنید نه از یک درخواست موفق مرورگر که فقط اثبات می‌کند TCP و UDP کار می‌کنند. پس از آن، گروه امنیتی، ACL زیرشبکه، فایروال مهمان و سیاست سرویس را برای هر دو جهت جریان بررسی کنید.

همه ترافیک را برای جبران انتقالی که سرویس نمی‌تواند حمل کند باز نکنید. تغییر قاعده آن را درست نمی‌کند و از حادثه جان سالم به در می‌برد.

وقتی انتقال مناسب نیست

اگر پروتکل بیرونی خارج از مجموعه پشتیبانی‌شده است، راه‌حل معماری است: انتقالی انتخاب کنید که مسیر می‌تواند حمل کند، یا خروجی را به چیزی منتقل کنید که آنچه لازم دارید را حمل می‌کند. OpenVPN روی UDP، WireGuard روی UDP و تونل‌های مبتنی بر TLS همه با مجموعه مستند سازگار هستند. نمونه NAT که مشتری مدیریت می‌کند گزینه‌ای است وقتی یک پروتکل خاص باید عبور کند و هزینه عملیاتی اجرای آن قابل قبول است.

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

ترتیب کار: پروتکل بیرونی را نام ببرید، گام بعدی را تأیید کنید، آن را با مجموعه مستند مقایسه کنید، سپس معماری یا انتقال را تغییر دهید. یک شماره پورت متفاوت نمی‌تواند GRE را به TCP تبدیل کند، و یک قاعده سهل‌گیرانه دیگر نمی‌تواند یک تبادل کنترل کامل را به کانال داده کارآمد تبدیل کند.