למה ממשק הניהול של הראוטר מפסיק להגיב אחרי שינוי VPN

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

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

המנהרה מעולם לא הייתה נתיב הניהול

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

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

שכבה אחת: האם קיים נתיב לכתובת של הראוטר עצמו?

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

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

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

שכבה שתיים: מדיניות הקלט, לא מדיניות ההעברה

חומות אש מעריכות כללים במנשק שאליו המנה מגיעה. ב-pfSense וב-OPNsense הלשונית של המנשק וסדר הכללים קובעים אם תעבורה לשירותים של חומת האש עצמה מורשית; כלל שמשחרר לקוחות LAN לאינטרנט אינו כלל שמאפשר לעמית מנהרה לפתוח את ממשק האינטרנט. ב-OpenWrt עם firewall4 כל אזור נושא מדיניות קלט, option input 'ACCEPT' או 'REJECT', ומנשק מנהרה באזור שמדיניות הקלט שלו REJECT יסרב לחיבורי ניהול ובמקביל עדיין יעביר תעבורה אם ההעברה מורשית.

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

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

שכבה שלוש: האם משהו מאזין בכתובת הזו?

שירות יכול לרוץ ועדיין להיות בלתי נגיש מפני שהוא נקשר לכתובת אחת. ה-uhttpd של OpenWrt מחזיק רשומות האזנה מפורשות ב-/etc/config/uhttpd, למשל list listen_http '0.0.0.0:80'; בנייה שנקשרת רק לכתובת ה-LAN לא מקבלת דבר בכתובת המנהרה, ומוצרים שמציגים הגדרת מנשק האזנה מתנהגים אותו דבר. פקודות ההאזנה למעלה עונות על כך ישירות.

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

מנשק VPN הוא גבול, לא נתיב התאוששות

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

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

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

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

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

רשמו ארבעה דברים לפני השינוי הראשון: איך תגיעו להתקן אם המנהרה תמות, למשל קונסולה סדרתית, קונסולה של הספק או מכונה ברשת ה-LAN; לאן מיוצאת התצורה הנוכחית; איזה כלל או נתיב אחד אתם עומדים לשנות; ואיך תחזירו בדיוק את הפריט הזה. ב-OpenWrt sysupgrade -b /tmp/backup.tar.gz לוכד את התצורה, והעריכות נשארות ממתינות עד uci commit, מה שנותן לכם ביטול זול אם תשימו לב בזמן. pfSense מחזיק היסטוריית תצורה, ו-AutoConfigBackup עוזר רק אם הוא כבר היה מופעל. אם הראוטר מריץ סט כללים fail-closed, ודאו שנתיב התחזוקה שתכננתם אינו בתוך התעבורה שהכלל הזה חוסם, וזכרו שאתחול מיישם מחדש כללים מתמשכים במקום למחוק אותם.

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

בדיקה מהירה לפני שיוצאים:

• האם אתם מגיעים לראוטר ממקור שאינו תלוי בכלל שזה עתה ערכתם?
• האם מדיניות הקלט במנשק המנהרה מתירה רק את מקור המנהל?
• האם שירות הניהול נקשר לכתובת שקיימת במנהרה?
• האם בדקתם עמית אחד שנדחה וסשן חדש?
• האם משטח הניהול דרך WAN עדיין סגור?