FortiGate پشت NAT: local-gw، localid و IP عمومی

یک FortiGate پشت NAT می‌تواند 10.0.0.2 را روی رابط WAN خود داشته باشد، در حالی که اینترنت آن را به‌صورت 198.51.100.40 نشان می‌دهد، و هر دو عدد واقعی‌اند. نشانی‌ای که دستگاه به آن متصل می‌شود و هویتی که در هنگام احراز هویت IKE می‌فرستد دو انتخاب جداگانه‌اند که در دو فیلد جداگانه و برای دو مخاطب جداگانه انجام می‌شوند. NAT نشانی‌دهی بیرونی را در مسیر بازنویسی می‌کند؛ اما هویت احراز‌شده را به آنچه همتای دور انتظار دارد بازنویسی نمی‌کند. بیشتر شکست‌های فاز 1 در این شکل از گذاشتن مقدار درست در فیلد نادرست می‌آید.

سه مقدار، سه مالک

با نام بردن سه مقدار و مالک هر یک شروع کنید. local-gw نشانی‌ای است که FortiGate از آن به‌عنوان منبع IKE روی رابط خارجی استفاده می‌کند و باید نشانی‌ای باشد که دستگاه واقعاً دارد. نقطه پایانی عمومی نشانی دستگاه NAT است و متعلق به کسی است که ترجمه را انجام می‌دهد. هویت IKE رشته‌ای است که همتا آن را با پیکربندی خودش تطبیق می‌دهد و لازم نیست اصلاً نشانی IP باشد.

نام فیلدها به‌قدری نزدیک‌اند که به جایگزینی دعوت کنند، و دام همین‌جاست. localid و localid-type شناسایی را توصیف می‌کنند؛ local-gw اتصال محلی را توصیف می‌کند.

یک مثال تمایز را عینی می‌کند. روی FortiGate، config vpn ipsec phase1-interface را باز کنید، سپس set interface "wan1" و set local-gw 10.0.0.2 — نشانی‌ای که جعبه دارد، و همین است که باعث می‌شود سوکت IKE با موفقیت متصل شود. local-gw را روی 0.0.0.0 رها کنید تا نشانی رابط استفاده شود، که معمولاً همان چیز است اما کمتر صریح. local-gw را روی 198.51.100.40 قرار ندهید، زیرا دستگاه آن نشانی را ندارد و سوکت به آن متصل نمی‌شود. یکسان نشان دادن دو مقدار روی کاغذ پیکربندی نیست.

گام 1: هویتی را انتخاب کنید که همتا می‌پذیرد

اکنون هویت، که تصمیم متفاوتی است. set localid مقداری را می‌گیرد که همتا مقایسه می‌کند، و set localid-type به FortiGate می‌گوید چگونه آن را تفسیر کند: یک نشانی، یک FQDN، یک FQDN کاربر یا یک ID کلید. با auto دستگاه آن را استخراج می‌کند، معمولاً از نشانی رابط خروجی، که دقیقاً همان مقداری است که دستگاه NAT در آستانه تغییر آن است.

همین استخراج دلیل اهمیت هویت صریح در این توپولوژی است. اگر همتا هویت نشانی انتظار دارد، localid-type address و localid را روی نشانی عمومی‌ای که همتا می‌بیند تنظیم کنید، سپس تأیید کنید که همتا آن مقدار را به‌عنوان هویت می‌پذیرد نه به‌عنوان هدف مسیریابی. اگر همتا FQDN انتظار دارد، از localid-type fqdn و نامی که با آن پیکربندی شده استفاده کنید. با diagnose vpn ike gateway list بررسی کنید که واقعاً چه فرستاده شده است؛ این دستور وضعیت دروازه و شناسه‌های در حال استفاده را نشان می‌دهد، نه آنچه قصد داشتید تایپ کنید. فرض نکنید که گزینه‌ی نوع هویت نشانی غیرمحلی دلخواه را می‌پذیرد؛ ابتدا معناشناسی مستند نسخه را بررسی کنید.

گام 2: UDP 500 و 4500 را به دستگاه هدایت کنید

مقدار سوم متعلق به دستگاه NAT است و همانی است که مردم فراموش می‌کنند بررسی کنند. نقطه پایانی عمومی باید UDP 500 و UDP 4500 را به FortiGate هدایت کند، زیرا تشخیص NAT-T و ESP کپسوله‌شده‌ای که پس از آن می‌آید هر دو به رسیدن این پورت‌ها وابسته‌اند. این طراحی یک نگاشت یک‌به‌یک را فرض می‌کند؛ اشتراک یک نشانی عمومی واحد بر پایه پورت میان چند همتا توپولوژی متفاوتی با محدودیت‌های متفاوت است.

هدایت را با یک ضبط تأیید کنید نه با امید: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 نشان می‌دهد که آیا بسته‌ها می‌رسند و آیا پاسخ‌ها خارج می‌شوند.

Google Cloud VPN نگاشت NAT یک‌به‌یک همراه با NAT-T را به‌عنوان آرایش پشتیبانی‌شده برای همتای پشت NAT مستند می‌کند، و اگر طرف دور یک دروازه Cloud VPN باشد، همین محدودیت است که باید بر اساس آن طراحی کنید. اشتراک یک‌به‌چند یا مبتنی بر پورت همان توپولوژی پشتیبانی‌شده نیست و هیچ میزان تنظیم هویت محلی آن را تغییر نمی‌دهد. اگر طرف دور دستگاه دیگری باشد، مستندات خودش تعیین می‌کند چه چیزی را به‌عنوان هویت می‌پذیرد و آیا نشانی همتای ترجمه‌شده را تحمل می‌کند. پیش از تغییر یک فیلد محلی آن را بخوانید، زیرا طرف محلی نمی‌تواند قاعده‌ای را مذاکره کند که طرف دور آن را پیاده‌سازی نمی‌کند.

گام 3: بررسی کنید فاز 1 چه چیزی را حل نمی‌کند

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

پس لایه‌به‌لایه بررسی کنید. get vpn ipsec tunnel details نشان می‌دهد که آیا تونل بالاست و کدام انتخاب‌گرها مذاکره شده‌اند، و ناسازگاری میان زیرشبکه دور پیکربندی‌شده و انتخاب‌گر مذاکره‌شده یک مشکل مسیریابی با لباس فاز 2 است. execute vpn ike gateway clear مذاکره‌ی مجدد را اجباری می‌کند، بنابراین پیکربندی فعلی را می‌آزمایید نه جلسه‌ای که پیش از آخرین تغییر شما برقرار شده است. سپس ترافیک را به میزبان در پیشوند دور بفرستید و تأیید کنید که شمارنده‌ها حرکت می‌کنند، زیرا تونلی که بالاست و چیزی عبور نمی‌دهد تا وقتی بررسی نکنید دقیقاً مانند یک تونل سالم به نظر می‌رسد.

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

تغییر شماره‌گذاری دستگاه NAT دلیلی برای دست زدن به local-gw در FortiGate نیست، و تغییر هویت دلیلی برای شماره‌گذاری مجدد چیزی نیست. قاطی کردن این دو همان روشی است که یک تونل سالم در یک پنجره نگهداری نامرتبط بازسازی می‌شود. راهنمای NAT در Cloud VPN مرجع توپولوژی پشتیبانی‌شده در آن سمت است.

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