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 של משתמש או מזהה מפתח. עם 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 מעלה את המנהרה, הסכמת זהות מחליטה אם העמית יקבל אותה, וניתוב הקידומת הפנימית מחליט מה באמת עובר. מזהה מקומי נכון לא יכול לספק נתיב סטטי חסר או בורר תעבורה חסר.

לכן אמתו בשכבות. 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 ולא זהות היו אי פעם הבעיה.