כתובת ה-L2TP הזו היא IPCP, לא חכירת DHCP ברשת המקומית

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

שתי כתובות בחיבור אחד

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

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

מה בדיוק עושה IPCP

IPCP הוא פרוטוקול הבקרה של IPv4 עבור PPP. כל צד שולח הודעות Configure-Request שמתארות את האפשרויות שהוא רוצה, ואפשרות הכתובת היא אחת מהן. לקוח שעדיין אין לו כתובת שואל בדרך כלל עם 0.0.0.0, והשרת משיב ב-Configure-Nak הנושא את הכתובת שהוא רוצה שהלקוח ישתמש בה. לאחר מכן הלקוח מבקש את הכתובת הזו, וההפעלה עולה עם כתובת מקומית וכתובת מרוחקת.

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

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

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

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

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

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

בדקו את ההפעלה, ואחר כך את הנתיב

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

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

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

הפרידו בין שלושת השלבים

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

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