למה מנהרת VPN שנייה שוברת את הראשונה?

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

התסמין: הלקוח השני מנצח בשקט

OpenVPN: האפשרות redirect-gateway def1 אינה דורסת את 0.0.0.0/0. היא מוסיפה את 0.0.0.0/1 ואת 128.0.0.0/1: יחד הן מכסות כל כתובת IPv4, וכל קידומת מנצחת ברירת מחדל פשוטה באורכה. ברירת המחדל המקורית נשארת בטבלה ומפסיקה לשמש לתעבורה רגילה, ונתיב מארח לשרת ה-VPN מונע מהמנהרה ללכוד את המנות החיצוניות של עצמה. שני הלקוחות עושים זאת, והשני פשוט מתקין את הזוג שלו מאוחר יותר.

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

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

קראו איזו מנהרה באמת מנצחת

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

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

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

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

ווינדוס: מנעו מפרופיל אחד להחזיק בברירת המחדל

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

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

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

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

לינוקס: החזיקו את המנהרה השנייה מחוץ לטבלה הראשית

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

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

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

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

לפי יישום, ושרשור כבעיה נפרדת

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

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

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