שתי מנהרות OpenVPN על מארח Linux אחד: למי שייך הנתיב?

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

התחילו מהעבודה שהקישור השני חייב לעשות

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

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

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

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

מאגרים חופפים נשברים לפני שהניתוב נשבר

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

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

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

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

תנו לכל פרופיל יחידה משלו ולכל קידומת בעלים

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

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

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

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

סימונים מחזיקים תשובות בממשק שממנו הגיעו

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

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

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

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

הוכיחו בידוד על ידי עצירת קישור אחד

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

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

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