איך לשלוח יעד IPv4 אחד מחוץ למנהרת OpenVPN

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

השורה נראית תמימה ולעיתים קרובות היא באמת כזו, אבל היא מכריעה רק שאלה אחת: לאן הולכות מנות לכתובת ה-IPv4 המדויקת הזו. היא לא משנה את ה-DNS, את IPv6, את מדיניות חומת האש או איזה תהליך פתח את החיבור, וכל אחד מאלה יכול לבטל את הפטור בשקט.

מה net_gateway באמת מכנה

רשומת הפרופיל לפטור הזה היא שורה אחת: route 198.51.100.77 255.255.255.255 net_gateway. הכתובת הראשונה היא מציין מקום תיעודי ליעד, המסכה הופכת אותו למסלול מארח בודד, והאסימון האחרון מכנה את מציין המקום של השער. OpenVPN מפענחת מצייני מקום של שערים כשהיא מתקינה מסלולים. vpn_gateway פירושו השער של המנהרה עצמה, הצד המרוחק של קישור ה-VPN. net_gateway פירושו שער ברירת המחדל שהיה למארח לפני שה-VPN שינה משהו, שבדרך כלל הוא הנתב המקומי ברשת הפיזית.

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

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

למה מסלול מארח מנצח את ברירת המחדל של המנהרה

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

מסלול לכתובת אחת עם מסכה 255.255.255.255 הוא /32, וזו הספציפיות המרבית ש-IPv4 מאפשר. כשמנתחים מנה לכתובת הזו, ה-/32 מתאים ומנצח בלי קשר לשאלה איזה מסלול הותקן קודם. זה המנגנון שמאחורי הפטור, והוא עובד אותו דבר ב-Linux, macOS ו-Windows כל עוד המסלול באמת קיים.

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

מה הפטור לא מכסה

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

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

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

לבדוק את הפטור בלי לרמות את עצמכם

התחילו מהמסלול המותקן, לא מהדפדפן. ב-Linux, שאלו את הליבה איזה מסלול ואיזו קפיצה הבאה היא תשתמש לכתובת הספציפית; ב-Windows, קראו את טבלת המסלולים עבור ה-/32 הזה. ודאו שהשער הוא הפיזי ולא המנהרה. אם הרשומה חסרה, הפרופיל לא הוחל או שלקוח לא הייתה הרשאה לשנות מסלולים.

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

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

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