לנתב תת-רשת של סניף דרך יציאת האינטרנט של SonicWall במטה

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

התחילו בבורר, לא במסלול

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

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

הוסיפו את מדיניות הסניף ואז הגנו על הסדר שלה

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

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

השלימו את הנתיב במטה

מדיניות המנהרה במטה חייבת לקבל את התעבורה שמסלול הסניף בוחר כעת. בורר בין-משרדי המוגבל ל-LAN הפרטי של המטה אינו הרשאה לשאת יעדים ציבוריים שרירותיים, לכן המדיניות זקוקה למקור הסניף ולטווח היעדים שאתם באמת מתכוונים אליו. לאחר מכן המטה מעביר את התעבורה הנכנסת הזו לקישור האינטרנט שלו לפי כללי הגישה שלו, ו דוגמת היציאה המרכזית של SonicWall כוללת תרגום מקור עבור הרשת המרוחקת ב-WAN המרכזי. בלי התרגום הזה הצד המרוחק רואה כתובת סניף פרטית ואין לו מסלול חזרה אליה.

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

החליטו מה הקבוצה עושה כשהמנהרה נופלת

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

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

אמתו משלושה לקוחות ואז חזרו לאחור בצורה נקייה

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

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

השוו היכן הבקשה הציבורית באמת צצה. לקוח נבחר אמור להגיע לאינטרנט דרך יציאת המטה, ולקוח רגיל אמור עדיין להציג את הכתובת של הסניף בצד המרוחק; 203.0.113.10 הוא כתובת תיעוד המשמשת כתחליף ליעד שחשוב לכם. כללו DNS באותו מעבר, כי לקוח ששואל את הפותר של הסניף יכול לייצר חיפוש שמקורו בנתב עם מקור שונה ולכן מסלול שונה.

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