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