שלושה סוגי מעבר חירום של OpenVPN ב-pfSense, שלושה מנגנונים

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

תנו שם לתקלה לפני שאתם בונים קבוצה

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

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

WAN מקומי: להעביר את התעבורה

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

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

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

נקודת קצה מרוחקת: שרת אחר

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

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

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

נתיב המנהרה: לבחור יציאה אחרת

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

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

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

מוניטורים, NAT וכלל fail-closed

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

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

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

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