מדוע מארח LAN שולח ARP עבור כתובת לקוח OpenVPN

בעיות נגישות בין מארח ב-LAN ללקוח VPN מובילות לעתים קרובות חזרה לתוכנית הכתובות עצמה. תנו לאותו מארח ממשק על 10.0.100.0/22 והוא יתייחס לכל כתובת מ-10.0.100.0 עד 10.0.103.255 כמחוברת ישירות, כולל מאגר לקוחות שהוצב בשקט על 10.0.101.0/24. התשובה לעולם אינה הולכת לנתב, משום מנקודת המבט של המארח אין נתב שמשתתף. החבילה ממוענת לשכן ומתבקשת על החוט.

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

ה-/22 שבולע את ה-/24

קראו את הקידומת כטווח, לא כמחרוזת. קידומת /22 מכילה 1024 כתובות, ו-10.0.100.0/22 משתרעת מ-10.0.100.0 עד 10.0.103.255, כך שמאגר על 10.0.101.0/24 נמצא כולו בתוכה. הטעות שורדת את הסקירה משום שהאוקטטים הראשונים של המאגר נראים שונים מהאוקטטים הראשונים של ה-LAN, ורק האוקטט השלישי חושף את ההכלה. כתבו את שני הטווחים במספרים לפני שאתם מכריזים עליהם כנפרדים.

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

חיבור ישיר משמעו ARP, לא ניתוב

כאשר מארח עם ממשק /22 שולח אל 10.0.101.25, הגרעין משווה את היעד לקידומת של הממשק ומוצא התאמה. החבילה הופכת לחיפוש שכן במקום חבילה מנותבת, וב-Ethernet חיפוש השכן הוא בקשת ARP עבור אותה כתובת. אם הכתובת שייכת ללקוח VPN מאחורי שער מנותב, אף מארח ב-LAN אינו מחזיק בה, ולכן הבקשה נשארת ללא מענה והחבילות נזרקות. המנהרה אינה אשמה, והלקוח לעולם אינו רואה את התעבורה.

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

TUN, TAP ומה כל אחד נושא

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

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

תכננו מאגר שאינו יכול לחפוף

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

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

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