הכניסה השנייה של VPN ב-WAN נכשלת בזמן שהראשית עדיין עובדת

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

כל WAN זקוק לחוזה הכניסה שלו

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

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

בדקו שה-WAN השני באמת עונה

בדקו מבחוץ לשני המעגלים, לא ממכונה מאחורי השער, ובדקו בדיוק את השם שפרופיל הלקוח משתמש בו. עבור מאזין TLS, הבדיקה המהירה היא openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts שמופעלת ממארח מחוץ לרשת שלכם. אתם רוצים לחיצת יד שהושלמה שהשרשרת שלה תואמת לשם שבפרופיל, לא רק פורט TCP שמקבל חיבור.

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

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

עקבו אחרי התשובה, לא רק אחרי הבקשה

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

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

תנו ללקוח דרך ללמוד על כניסה שתיים

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

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

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

להחזיק כתובת ציבורית אחת נגישה דרך שני המעגלים הוא שירות ניתוב, לא תיבת סימון ב-VPN. הוא צריך מרחב כתובות ששני הספקים מוכנים לשאת, מוכרז באופן שהרשתות שלהם מקבלות, וזה מה שנותן multihoming עם מרחב בלתי תלוי בספק ו-BGP. הקצאת הכתובת של ספק A לממשק של ספק B לא מגיעה לשם; החבילה מגיעה לרשת שמעולם לא הכריזה על הקידומת והיא נזרקת במעלה הזרם.

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

מה לבדוק בהמשך

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

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