לנתב תת-רשת LAN אחת דרך OpenVPN ולשמור על ברירת המחדל
שמור על ברירת המחדל של ה-LAN בזמן שתת-רשת אחת עוברת במנהרה. השווה טבלת מדיניות לשינויים בטבלה הראשית, ואז בחר NAT או נתיב בצד השרת.
מכשירים שמנתבים עבור LAN וגם מחייגים ל-VPN מוצאים את עצמם באותו ויכוח עם עצמם: המנהרה רוצה להחזיק בנתיב ברירת המחדל, וה-LAN זקוק לו בחזרה. כש-OpenVPN מתחבר, הוא עלול להתקין נתיב ברירת מחדל דרך המנהרה או זוג חצאי-ברירות מחדל, וזה נכון למחשב נייד ושגוי לשער שהשכנים שלו מצפים לתשובות מכתובת ה-LAN שלו. התשובה אינה לוותר על ה-VPN. התשובה היא לתת לשתי ההחלטות טבלאות שונות.
נתיב ברירת מחדל אחד, שני בעלים
תנועה מועברת ותנועה שמקורה מקומי לא חייבות ללכת באותו מסלול. לקוחות ה-LAN זקוקים למנהרה רק ליעדים שתבחר, ואילו הפעלות הניהול של המארח עצמו והתשובות שלו לאותם לקוחות זקוקות לברירת המחדל של ה-LAN. ערבוב שניהם בטבלה הראשית כופה תשובה אחת על שתי שאלות שונות.
ל-OpenVPN יש מתג בדיוק בשביל זה. route-noexec מונע מהלקוח לגעת בטבלה הראשית בכלל, והערכים שבהם היה משתמש מיוצאים לסקריפט route-up בשמות route_vpn_gateway, dev וכתובות הממשק. אחר כך אתה מחליט איזו טבלה מקבלת איזה נתיב, בקוד שתוכל לקרוא מאוחר יותר.
טבלת מדיניות לעומת שכתוב הטבלה הראשית
| Approach | What it buys | What it costs |
|---|---|---|
| Separate table plus source rule | LAN traffic and host traffic keep independent defaults | Every lookup now depends on rule order |
| Editing the main table only | Fewer moving parts on a single-purpose host | One mistake takes the gateway offline entirely |
| Two half-default routes | Works for a full-tunnel client | Ambiguous on a host that must answer on its LAN address |
הטבלה הנפרדת היא האפשרות היחידה שמתרחבת מעבר לתת-רשת אחת. תן לה שם פעם אחת, ואז התייחס אליה בשם כדי שאיש לא יצטרך לזכור מספר:
echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpnהכתובות כאן הן ממלאי מקום. החלף את קידומת ה-LAN, את שער המנהרה ואת שם ההתקן מהפריסה שלך לפני שתפעיל משהו.
הכלל חייב להתאים גם למארח
כלל שמתאים רק לקידומת ה-LAN מכסה מנות מועברות. הוא אינו מכסה תנועה שהשער עצמו יוצר, ואינו מכסה את התשובות שהוא מחזיר ללקוחות ה-LAN, שנושאות את כתובת ה-LAN של השער כמקור. החיפושים האלה נופלים ל-main ועדיין יכולים לצאת דרך המנהרה.
הוסף כלל שני לכתובת ה-LAN של השער עצמו, או הרחב את הכלל הראשון לקבוצה שכוללת את שניהם. הסדר חשוב: שים את הכלל הספציפי יותר ראשון, ובדוק את התוצאה בחיפוש שמציין את המקור במפורש.
ip route get 203.0.113.9 from 192.168.50.1אם זה מדווח על התקן המנהרה עבור יעד שאמור להישאר מקומי, מערך הכללים שגוי בלי קשר למה שהטבלה מכילה.
NAT או נתיב בצד השני
שרת ה-VPN מכיר את תת-הרשת של המנהרה ולא שום דבר אחר. למנות שמגיעות עם כתובת מקור של LAN אין נתיב חזור אלא אם מישהו מספק אחד, ויש בדיוק שתי דרכים לספק אותו. הוספת נתיב לקידומת ה-LAN בשרת משאירה את המקור המקורי גלוי מקצה לקצה, וזה מה שתכנון מבוקר בדרך כלל רוצה. מיסוך בשער משכתב את המקור לכתובת המנהרה ואינו צריך שיתוף פעולה מהשרת.
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADEבחר NAT כשאינך שולט בשרת ואינך יכול להוסיף שם נתיבים. בחר בנתיב בצד השרת כשהלוגים, בקרת הגישה או הסימטריה של נתיב החזור חשובים, כי המיסוך מוחק את הכתובת המקורית מכל מה שהצד השני רושם.
בכל מקרה, העברה חייבת להיות מופעלת, וסינון קפדני של נתיב החזור עלול להפיל את התשובה כש-main לא היה בוחר במנהרה עבור אותו מקור. בדוק את הערך האפקטיבי לפני שאתה מאשים את המנהרה.
גרום לפיצול לשרוד התחברות מחדש
כללים ונתיבים שהוספו ביד נעלמים כשהממשק נוצר מחדש, ורשומה מיושנת בטבלה יכולה לשרוד את ההפעלה שהצדיקה אותה. שים את כלל הטבלה, את נתיב המנהרה ואת רשומת המיסוך בתוך סקריפט route-up של הלקוח, ורוקן את הטבלה בראש הסקריפט כדי ששער ישן לא יוכל לשרוד אל תוך ההפעלה החדשה.
אמת משני הקצוות: חיפוש בשער עם מקור LAN, ובקשה אמיתית מלקוח LAN ליעד שאמור לעבור במנהרה. נתיב שקיים אך לעולם אינו נבחר מתנהג בדיוק כמו אין נתיב כלל, עד שתקרא את המונים.