OpenVPN iroute מול נתיב הקרנל: מה חסר?

חבילה עבור 10.77.20.0/24 מקבלת שתי החלטות נפרדות בשרת OpenVPN: מערכת ההפעלה חייבת למסור אותה לממשק ה-VPN, ו-OpenVPN חייב לדעת איזה לקוח מחובר מחזיק בקידומת הזו. נתיב קרנל חסר מפיל אותה לפני המנהרה, ונתיב עמית חסר מפיל אותה אחריה. שתי התקלות נראות זהות מה-LAN המרוחק, ואבחון של איזו מהן יש לכם דורש פקודה אחת בכל צד.

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

שתי החלטות, לא נתיב אחד

דמיינו קישור מאתר לאתר שבו 10.77.20.0/24 יושב מאחורי לקוח בודד. נתיב הקרנל של השרת, למשל ip route add 10.77.20.0/24 dev tun0, שולח את החבילות המתאימות להתקן המנהרה. לאחר מכן OpenVPN עיין בטבלה הפנימית שלו, שנבנתה מרשומות iroute בספריית התצורה של הלקוח, כדי להחליט איזה חיבור עמית יקבל אותן. בלי נתיב הקרנל החבילה לא מגיעה לתהליך לעולם, ובלי נתיב העמית היא מגיעה לתהליך ולא הולכת לשום מקום.

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

איפה iroute נמצא ומה הוא אומר

הרשומה נכנסת לקובץ לכל לקוח שנקרא על שם ה-common_name של הלקוח, תחת client-config-dir, בתור iroute 10.77.20.0/24. התאמת שם הקובץ אינה קוסמטית: OpenVPN מחפש את הזהות המאומתת וקורא את הקובץ בדיוק בשם הזה, ולכן קובץ בשם site-a משפיע רק על לקוח שהשם הנפוץ שלו הוא site-a. הוסיפו ccd-exclusive אם לקוחות בלי קובץ כזה צריכים להידחות לחלוטין, שזו ההגדרה הנכונה כשכל לקוח הוא שער אתר. החזיקו קובץ אחד לכל שער ותנו לו שם לפי נושא התעודה שאתם באמת מנפיקים.

בדקו את הרשומה מהשרת לפני שמאשימים את ה-LAN המרוחק. קובץ המצב מפרט את הלקוחות המחוברים עם השמות הנפוצים שלהם, ושרת שפועל עם --verb 4 רושם ביומן את התקנת iroute ברגע שהעמית מתחבר. אם לא מופיע דבר בזמן החיבור, הקובץ נמצא בספרייה הלא נכונה או מציין זהות לא נכונה.

המלכודת: הקובץ קיים, הזהות לא נכונה

iroute שנראה תקין אך מחובר לעמית הלא נכון מבזבז יותר זמן מקובץ חסר, מפני שהכול על הדיסק נראה תקין. שינוי שמות של תעודות, שמות נפוצים כפולים, ו-username-as-common-name שמשנה את הזהות האפקטיבית כולם יוצרים את זה. בדקו איזו זהות השרת אימת, במקום איזו שציפיתם לה: פלט המצב הוא הקובע, בעוד שם הקובץ הוא רק מפתח חיפוש.

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

השלימו את המסלול מעבר לעמית

הבעלות על העמית היא אמצע המסלול, לא סופו. הלקוח חייב להעביר חבילות מהמנהרה אל ה-LAN שלו, כלומר העברת IP מופעלת במארח הזה וכלל חומת אש שמתיר את המעבר. מארחים ב-LAN המרוחק זקוקים לנתיב חזור עבור כתובת המנהרה: או נתיב שמצביע חזרה אל השער, או תכנון NAT מכוון בצד הלקוח. אשרו את הגדרת ההעברה בלקוח באמצעות sysctl net.ipv4.ip_forward במקום להניח ברירת מחדל של ההפצה.

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

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