OpenVPN: הכתובת המקומית מול כתובת המנהרה — שני שקעים שונים

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

שגיאת הקישור נוקבת בכתובת מקומית

כאשר OpenVPN מדווח שאינו יכול לקשור כתובת מקומית, הוא מדבר על שקע התעבורה: נקודת הקצה UDP או TCP שנושאת את החיבור המוצפן אל העמית.

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

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

מה local ו-remote באמת בוחרים

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

לאף אחת מההוראות אין קשר לכתובת שבתוך המנהרה.

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

ip -brief address show
ip route get 203.0.113.10

הכתובת הפנימית מגיעה מהשרת

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

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

גם הממשקים שכדאי לקרוא שונים. פרמטרים של ifconfig ותצורת המאגר מתארים את הפנים, ואילו remote, local, proto ו-nobind מתארים את החוץ. שמירה על שתי הרשימות בנפרד מסבירה כמעט כל דוגמה מבלבלת שתמצאו בפורום. המדריך של OpenVPN 2.6 מתעד אותם בסעיפים נפרדים בדיוק מהסיבה הזו.

המלכודת: מנהרה מלאה שלוכדת את התעבורה של עצמה

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

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

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

הרגל שמונע את הבלבול

קראו כל כתובת בפרופיל והחליטו לאיזו שכבה היא שייכת לפני שתערכו אותה.

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

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