מנהרה מלאה של FortiClient: לנתב רק את תת-הרשת של המשרד

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

מה הלקוח התקין, ולמה נעלמה הרשת המקומית

התחילו בקריאת הטבלה במקום בממשק הלקוח. ב-macOS netstat -rn מדפיס את כל הטבלה ו-route -n get default מציין את הממשק ואת המדד שמנצחים כרגע; ב-Linux הזוג הוא ip route show ו-ip route get 8.8.8.8. שניהם עונים על שאלה אחת: איזו רשומה תישא מנה שאינה תואמת דבר ספציפי יותר.

שם התקן המנהרה אינו קבוע. פרופיל IKEv2 ב-macOS מציג בדרך כלל utun עם מספר, לקוח SSL VPN מציג ppp0, ו-OpenVPN מציג tun0. שני נתיבי ברירת מחדל יכולים גם להיות נוכחים בו-זמנית עם מדדים שונים, ורשומת הלקוח עשויה להשתלט רק לאחר התחברות מחדש ולא ברגע שבו היא מופיעה. לכן שתי הדפסות של הטבלה בהפרש של חמש דקות יכולות לספר סיפורים שונים.

למה נתיב ברירת המחדל של המנהרה חייב ללכת ראשון

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

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

הרצף ב-macOS וב-Linux

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

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

ב-Linux אותו סדר משתמש בכלי אחר: שער ה-LAN עבור נתיב ברירת המחדל והתקן המנהרה עבור קידומת המשרד. הפקודה הוותיקה route עדיין מקבלת את התחביר הישן, אבל ip route היא הצורה שמתאימה לתיעוד הנוכחי.

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

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

קידומות, הפותר וה-DMZ שנשאר חשוך

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

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

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

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

קראו את שני הערכים לפני שתפעילו אותה. peer הוא הקצה הרחוק של מנהרה מנקודה לנקודה, וזו הכתובת שנתיב ה-DMZ צריך; במנהרה מנותבת המקבילה היא הממשק או השער שהלקוח מדווח עליו. אם אף אחד מהם לא מופיע, הלקוח אינו במצב שהנחתם.

אחרי החיבור הבא, ומתי להפסיק לעשות את זה מקומית

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

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

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