מסלולי L2TP מפוצלים ב-Mac: מדוע כתובת מארח אינה עובדת

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

היעד הוא כתובת רשת, המסכה מתארת את הקידומת

networksetup -setadditionalroutes מקבל שלשות של יעד, מסכת תת-רשת ושער. הקריאה ששולחת תת-רשת פנימית אחת דרך המנהרה נראית כך:

sudo networksetup -setadditionalroutes "VPN (L2TP)" 192.168.1.0 255.255.255.0 10.2.0.0

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

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

כשאתם רוצים בדיוק מארח אחד, השתמשו בכתובת המארח עם מסכה 255.255.255.255. בזוגות מעורבים הדבר משתבש, ולא בשימוש בכתובת מארח כשלעצמו. /32 שנבנה מכתובת אחת הוא מסלול לגיטימי; /24 שנבנה מכתובת אחת הוא טעות.

הקריאה מחליפה את הרשימה, והשם הוא מילולי

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

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

networksetup -listallnetworkservices

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

כשהפרופיל תובע את מסלול ברירת המחדל

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

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

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

מנהרות PPP זקוקות לקרס במקום מפתח

עבור מנהרות מבוססות PPP, defaultroute הוא מפתח הפרופיל שיוצר מסלול ברירת מחדל; הסירו אותו והלקוח מפסיק לתבוע כל יעד. לאחר מכן מוסיפים מסלולים אחרי שהממשק מופיע, בדרך כלל מתוך /etc/ppp/ip-up:

#!/bin/sh
/sbin/route add -net 192.168.1.0 -interface ppp0

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

אמתו את הפיצול בשלוש בקשות

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

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

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