מנהרה מלאה הרגה את הפעלת ה-SSH שלך: הצמד את נתיב החזרה

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

מה redirect-gateway באמת מתקין

בצורת def1 redirect-gateway הוא מוסיף 0.0.0.0/1 ו-128.0.0.0/1 במקום לדרוס את נתיב ברירת המחדל. שני החצאים הללו מכסים את כל מרחב הכתובות ושניהם נשארים קידומות ארוכות יותר מ-0.0.0.0/0, כך שכל יעד בלי התאמה ספציפית יותר נכנס כעת למנהרה. זהו המנגנון שכדאי לזכור, מפני שכל תיקון בהמשך עובד באמצעות התקנת התאמה ספציפית יותר.

כתובת הניהול שלך היא אחד מהיעדים האלה.

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

ip route show table main | head -n 20
ip route get 198.51.100.23

מצא את כתובת המקור שלך ואת הנתיב שלפני המנהרה

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

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

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

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

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

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

אמת באמצעות חיפוש ולא על ידי בחינת הטבלה: התשובה חייבת למנות את eth0 ואת השער, לעולם לא את tun0.

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

גרום לזה לשרוד התחברות מחדש

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

גם route-up סקריפט וגם וו ה-pre-up של מנהל הרשת עובדים, והבדיקה האמינה היא התחברות מחדש ואחריה אותו חיפוש.

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

כשנתיב מוצמד עדיין לא מספיק

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

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

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