הרחבת אתר VPN: עקבו אחר מסלול החזרה מעבר לשער

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

השער המרוחק הוא נקודת קצה של הצפנה

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

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

קראו את שני הכיוונים של מדיניות המנהרה

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

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

הוסיפו את המסלול קדימה ואשרו את הכניסה

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

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

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

בדקו מהסניף ואז בדקו שוב את המסלול הישן

קבלה דורשת מקור אמיתי ולא בדיקה מהשער המרוחק. הריצו את הבדיקה ממארח בסניף ושמרו על היעדים שעבדו קודם באותה בדיקה.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

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

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