שני שערים, VPN אחד: מדוע OpenVPN בוחר את הקישור העולה הלא נכון

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

כתובת המנהרה אינה נקודת הקצה

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

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

מצאו את הכתובת שאליה הלקוח באמת חייג

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

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

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

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

קבעו את נקודת הקצה וקראו את סדר המדיניות

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

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

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

ip rule show
ip route get 203.0.113.40

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

כאשר נקודת הקצה זזה

שם מארח שנפתר לכמה כתובות מבטל /32 קבוע ברגע שהתשובה משתנה. לפרופיל עם כמה שורות remote יש אותה בעיה, כי הלקוח עשוי לנחות על כל אחת מהן. רעננו את המסלול מה-hooks של מחזור החיים של הלקוח עצמו במקום להוסיף אותו ביד. סקריפט up שקורא את העמית המתואם ומתקין את מסלול המארח ושומר על החריגה מיושרת עם המציאות, וסקריפט down תואם מסיר אותה.

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

הפרידו בין המדיניות הפנימית

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

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

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