איך בונים מדיניות מעבר כשל של VPN בנתב בלי דליפות
החליטו מה צריך התעבורה לעשות כשהמנהרה המועדפת נופלת: מנהרת גיבוי, WAN רגיל או חסימה. אחר כך בנו ובדקו זאת בנתב.
מעבר הכשל עבד בדיוק כפי שהוגדר, וזו הייתה הבעיה. כשהמנהרה הראשית נפלה, הנתב העביר את נתיב ברירת המחדל למודם הכבלים, המחשבים הניידים המשיכו לגלוש, ואף אחד לא התקשר. יומיים אחר כך מישהו שם לב שתיקיית הכספים הייתה נגישה דרך נתיב האינטרנט הפתוח במשך שש שעות. מדיניות מעבר כשל של VPN בנתב אינה תעלול ניתוב; היא החלטה מה צריכה התעבורה לעשות כשהנתיב המועדף נעלם, וההחלטה הזו חייבת להתקיים לפני שהנתיב נעלם.
החליטו על התוצאה לפני שאתם בוחרים בגלאי
בדרך כלל יש שלוש תוצאות על השולחן: לשלוח לקוחות שנפגעו דרך מנהרת גיבוי, לתת להם להשתמש ב-WAN הרגיל, או לחסום אותם לחלוטין. כתבו איזו מהן חלה על איזו VLAN, SSID או סוג מכשיר. כלל שטוח אחד של “לעבור ל-WAN” הוא הסיבה שתיקיית הכספים למעלה הגיעה לנתיב ציבורי.
השלוש אינן ניתנות להחלפה. נפילה ל-WAN משאירה את שולחן התמיכה עונה לטלפונים תוך חשיפת שמות פנימיים לפותר המקומי. מנהרת גיבוי משמרת את המדיניות אך עלולה לנחות בכתובת יציאה שהצד השני אינו מקבל. חסימה נכונה ל-VLAN של שכר ושגויה לרשת אורחים שמעולם לא השתמשה במנהרה.
| תוצאה | מתאים ל | מה נשבר |
|---|---|---|
| מנהרת גיבוי | המדיניות חייבת להחזיק, נדרשת גישה מרחוק | כתובת יציאה חדשה, נתיב חזרה, חידוש מפתח איטי יותר |
| WAN רגיל | תעבורת אורחים או ציבורית בלבד | שמות פנימיים, חשיפת DNS ו-IPv6 |
| חסימה | שכר, ניהול, כל דבר VPN בלבד | המשתמשים מאבדים כל גישה ומתקשרים אליכם |
התאימו את הגלאי לכשל שאתם באמת חוששים ממנו
מצב לחיצת היד, מצב הממשק והעברה שמישה הם שלושה אותות שונים, ורק האחרון חשוב למשתמש. עמית WireGuard יכול להראות לחיצת יד עדכנית בזמן שהזרם העליון של הספק זורק חבילות לבור שחור. OpenVPN הלקוח יכול להישאר ב“מחובר” אחרי שהנתיב שהוא דחף הפסיק להיפתר.
ב-pfSense הסידור המעשי הוא קבוצת שערים שמוזנת על ידי dpinger, שבודק כתובת ניטור ומסמן שער כמושבת כאשר אובדן או השהיה חוצים את הספים שלו. כוונו את הניטור הזה למשהו מעבר למנהרה, כמו מארח ב-LAN המרוחק או כתובת ציבורית שאליה אתם מגיעים דרכה. כיוונו לכתובת העמית של המנהרה עצמה מודד את החלק שאתם כבר יודעים שהוא חי.
בנו את הקבוצה כך שהגיבוי יישאר המוצא האחרון
השתמשו בדרגות במקום רשימת חברים שטוחה. ראשי בדרגה 1, מנהרת גיבוי בדרגה 2, WAN בדרגה 3 רק ל-VLAN שהמדיניות שלהן מאפשרת. ב-pfSense זה נמצא תחת System > Routing > Gateway Groups: הוסיפו את שני השערים, תנו להם דרגות שונות, הגדירו Trigger Level ל-member down plus packet loss, שמרו, ואז החילו את הקבוצה כברירת מחדל של הממשק או בשדה Gateway של כללי חומת האש שזקוקים לה.
עבור מופע לקוח OpenVPN ב-pfSense 2.5 ואילך, הגדרת Default Gateway של המופע קובעת אם המנהרה מחליפה בכלל את נתיב ברירת המחדל של המערכת. ניתוב מדיניות לפי כלל מתנהג כמצופה רק כאשר הנתיב שאתם מניחים שקיים אכן מותקן. בדקו את Status > Gateways לאחר השינוי במקום לסמוך על סמל מצב המנהרה.
שתי הגדרות גורמות לרוב הריצוד. האחת היא מרווח בדיקה קצר מההתכנסות מחדש של הספק עצמו. האחרת היא קבוצה שבה ראשי וגיבוי חולקים דרגה, כך ששניהם נשארים כשירים כל הזמן. הוסיפו היסטרזיס דרך ספי אובדן והשהיה לפני שהמשתמשים שלכם ירגישו את המעברים במקומכם.
סגרו את הנתיבים שהמנהרה מעולם לא החזיקה
קודם דליפות DNS. הפותר ממשיך לענות ב-WAN ומעביר דרכו החוצה, כך ששמות ממשיכים להיפתר דרך ספק האינטרנט בזמן שהתעבורה מוצמדת למנהרה. הגבילו את ממשקי היציאה של הפותר, דחפו את הפותר הפנימי ללקוחות, וחסמו פורט 53 לכל השאר ב-VLAN של VPN בלבד.
IPv6 צריך החלטה משלו. LAN דו-מחסנית יכול לאבד את המנהרה ולשמור על נתיב ברירת מחדל גלובלי IPv6 שעובד, כך שדפדפנים מעדיפים IPv6 ויוצאים דרך ה-WAN בזמן ש-IPv4 נראה כלוא לחלוטין. או נתבו את IPv6 לתוך המנהרה, או הפסיקו לפרסם קידומת גלובלית כשהמנהרה מושבתת. חצי מדיניות גרועה מכלום, כי היא נראית כאילו היא עובדת.
אחר כך נתיב החזרה. אם יציאת הגיבוי משתמשת בכתובת מקור אחרת, הצד השני חייב לדעת איך לשלוח תעבורה חזרה אליה, וכל מצב שנקשר לכתובת הישנה כבר מת. הפעלות שהיו פתוחות כשהראשי נפל אינן נודדות; הן נתקעות עד שהן פוקעות והיישום מחליט מה לעשות.
בדקו את הנפילה, הריצוד ואת הדרך חזרה פנימה
משכו את הראשי כשתעבורה בלתי מזיקה פועלת, ואז קראו ארבעה דברים: Status > Gateways עבור מצבי חברי הקבוצה, pfctl -ss עבור מצבים שעדיין מוצמדים לשער הישן, traceroute מלקוח עבור נתיב היציאה, ושאילתת פותר כדי לראות איזה שרת ענה.
עכשיו תריצדו אותו. העלו את הראשי לשלושים שניות, הורידו לשלושים, פעמיים. אם התעבורה רודפת אחרי כל מעבר, הספים הדוקים מדי או הדרגות שגויות. תקנו זאת לפי לוח הזמנים שלכם, כי אחרת ספק יעשה זאת לפי שלו.
לבסוף, ודאו שאתם עדיין יכולים לנהל את הנתב. החזיקו נתיב מחוץ לרצועה כמו כבל קונסולה, VLAN ניהול או מודם סלולרי. מבחן מעבר כשל שנועל אתכם בחוץ הוא מבחן שאינכם יכולים לסיים, ונתב בלתי נגיש אינו יכול לחזור מעצמו.
לפני שאתם מכריזים שהמדיניות מוכנה, עליכם להיות מסוגלים לענות על ארבע שאלות בלי לפתוח מסוף: אילו VLAN רשאיות להשתמש ב-WAN כשהמנהרה מושבתת, מה הגלאי צופה וכמה זמן הוא ממתין, אילו שרתי שמות ונתיבי IPv6 נעים עם הנתיב, ואיך נכנסים חזרה אם גם הגיבוי נכשל. אם תשובה כלשהי היא “מה שהיה ברירת מחדל”, המדיניות עדיין שייכת לנתב ולא לכם.