דחיית זיהוי גיאוגרפי ב-Firebox: מצאו קודם את שלב כניסת ה-VPN

מישהו במדינה אחרת לא מצליח להתחבר, והדחף הראשון הוא להסתכל על הכלל שמעניק גישה למשאבים פנימיים. הכלל הזה פועל אחרי הקבלה, כך שהוא לא יכול להיות מה שדוחה את המנהרה. השלב החוסם נמצא אי שם בנתיב הכניסה, ול-Firebox יש יותר מנתיב כניסה אחד בהתאם לשירות ה-VPN. יש לבצע את הבדיקות לפי הסדר ולעצור ברגע שאחת מהן מסבירה את הדחייה.

בדיקה 1: תן שם לשירות הנכנס

עבור Mobile VPN עם SSL, Access Portal ו-BOVPN מעל TLS, הכניסה הנכנסת היא מדיניות WatchGuard SSLVPN. החל שם את ההגבלה המיועדת, על השירות שהוגדר בפועל, במקום להסיק אותה מכלל גישת משתמש שפועל מאוחר יותר.

IPsec הולך בנתיב אחר. מדיניות IPSec המובנית מתירה תעבורת IPsec חיצונית אל ה-Firebox עבור שירותי הסניף וה-VPN הנייד הרלוונטיים, והיא קודמת למדיניות IPSec שנוצרה ידנית. אם הלקוח שלך הוא IKEv2, אתה בנתיב השני הזה, ומדיניות SSLVPN אינה רלוונטית.

לטעות כאן זה אחר הצהריים המבוזבז הנפוץ ביותר בתחום הזה: לערוך מדיניות שלעולם לא רואה את החבילה, ואז להסיק שההגבלה לא עובדת.

בדיקה 2: קרא את הדחייה, לא את התיאוריה

בצע ניסיון מותר אחד מבוקר ותאם ארבעה דברים: כתובת המקור הציבורית של הלקוח, שירות הכניסה שאליו הגיע, המדיניות שהתאימה, וכל סיבת דחייה ביומן. ההנחיות לפתרון בעיות IKEv2 של WatchGuard מציינות שזיהוי גיאוגרפי וטיפול ברירת מחדל בחבילות יכולים לדחות תעבורה לפני הקבלה של המדיניות המובנית, כלומר הדחייה שאתה רואה עשויה לנקוב בשלב שלא שקלת.

סיווג המדינה עוקב אחר מקור הרשת שנצפה. משתמש נודד, NAT במעלה הזרם או נתיב מאושר אחר יכולים לשנות את מה שה-Firebox רואה, לכן אשר את הכתובת ולא את תיאור המשתמש היכן הוא נמצא. בקש את הכתובת הציבורית שהלקוח רואה, והשווה אותה למקור ביומן ה-Firebox. כשהם שונים, הסיווג עוקב אחר נתיב שאיש לא הזכיר.

בדיקה 3: האם המדיניות המובנית היא עדיין הבעלים?

אם נראה שמדיניות IPSec ידנית מותעלמת, בדוק אם המובנית עדיין מופעלת. כלל ידני שמוצל על ידי כלל מובנה בעל עדיפות גבוהה יותר וכלל ידני שהוא הקבלה היחידה הם תצורות שונות עם ממשק דומה למראה.

החלט איזה מהן אמור להחזיק בנתיב. אם זו המדיניות הידנית, יש להשבית את המובנית עבור אותה תעבורה, ומשם מתחילה הבדיקה הבאה.

בדיקה 4: תכנן את ההחלפה לפני ההשבתה

השבתת מדיניות IPSec המובנית מסירה את הקבלה שלה עבור שירותי ה-VPN המושפעים. זה כולל מנהרות סניף שאולי אינך חושב עליהן בזמן שאתה מתקן את החיבור של משתמש נייד אחד.

תכנן תחילה את ההחלפה המלאה: אילו שירותים זקוקים לקבלה, אילו טווחי מקור הם מקבלים, ואיך תנהל את ההתקן אם השינוי ייכשל. השאר נתיב ניהול ושחזור עצמאי פתוח, כי טעות כאן עלולה להסיר את המנהרה שבה היית משתמש כדי לתקן אותה. רשום את שלבי השחזור ברשומת השינוי, כולל איך להגיע להתקן אם נתיב ה-VPN נעלם. אחר כך בדוק חידוש, לא רק את החיבור הראשון.

גם הקישוריות הפעילה וגם המשא ומתן המחודש המאוחר יותר יכולים להיות תלויים בקבלה. שינוי שעובד עבור ההפעלה שבדקת ונכשל בהחלפת המפתח הבאה הוא תוצאה קלאסית של החלפת קבלה בלי לבדוק חידוש.

בדיקה 5: הפרד זהות ממיקום

זיהוי גיאוגרפי מוסיף הקשר להחלטת כניסה. הוא לא קובע מי המשתמש, והוא לא אמור להחליף בדיקות זהות של השער, הרשאת חשבון או MFA.

אם דרישת העסק היא רק משתמשים מאושרים ממקומות מאושרים, אתה צריך את שני הבקרות. כלל מיקום שמקבל מדינה שלמה אינו תחליף לאימות, ומשתמש מאומת במדינה חסומה הוא שאלת מדיניות ולא תקלה.

בדיקה 6: תעד אותו ואמת את שני הנתיבים

רשום את השירות, את מדיניות הכניסה, את טווח המיקום המיועד, את החריגים ואת האחראי על השחזור. אחר כך בדוק את הנתיב הנייד ולפחות נתיב אתר אחד לאחר השינוי, כדי שההגבלה תישאר מחוברת לשירות שלשמו נועדה.

לבסוף, קרא שוב את הדחייה שאיתה התחלת. אם היא השתנתה מדחיית מיקום לכשל אימות או הרשאה, בעיית הכניסה נפתרה ואחרת נראית כעת. הנחיות WatchGuard לדחיות IKEv2 הוא המקור לסדר השלבים המתואר לעיל.