מנהרה מלאה של OpenVPN מנתקת את הפעלת ה-SSH שלך: תקן את נתיב התשובה

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

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

למה התשובה יוצאת מהדלת הלא נכונה

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

ההגנה של OpenVPN עצמו מכסה בדיוק יעד אחד. המדריך של 2.6 מתאר את --redirect-gateway כרצף: הוא מוסיף נתיב מארח ל-peer של ה-VPN דרך השער שהיה בשימוש לפני המנהרה, כדי שהתעבורה המוצפנת לא תוכל לחזור לתוך עצמה, ואז מחליף את נתיב ברירת המחדל. נתיב המארח הזה מיועד ל-peer בלבד. לקוח ה-SSH שלך הוא רק עוד כתובת אינטרנט ולא מקבל שום חריגה.

שווה לשלול מוקדם טעות קידומת אחת. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 בלי אורך מתאים לכתובת הבודדת 0.0.0.0, לא לאינטרנט; הוא חייב להיות 0.0.0.0/0. ואם נטילת ברירת המחדל שוברת את התעבורה של המנהרה עצמה, הוסף את נקודת הקצה כנתיב מארח דרך הממשק הפיזי, באמצעות הכתובת האמיתית של הספק.

הצמד את כתובת לקוח ה-SSH שלך לתיקון מיידי

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

curl -s https://ifconfig.co
ip route

בשרת, הוסף את החריגה לפני שהלקוח מתחיל. הכתובות כאן הן מצייני מקום; הצורה היא מה שחשוב:

sudo ip route add 80.128.240.55 via 192.168.178.1

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

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

האפשרות הנקייה יותר היא למנוע מהמנהרה להחליף את נתיב ברירת המחדל בכלל. route-nopull, בשימוש עם --client או --pull, מקבל את האפשרויות הנדחפות למעט נתיבים, block-outside-dns ואפשרויות בסגנון DHCP כמו שרתי DNS, כך שאתה מוסיף רק את הקידומות שאתה צריך. כלי צר יותר הוא מסנן משיכה, שמפיל הנחיה בעייתית אחת ושומר על השאר:

route-nopull
pull-filter ignore "redirect-gateway"

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

פצל את נתיב החזרה לפי מקור או לפי חיבור

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

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

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

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

שמור על סימן החיבור, סימן חומת האש ומספר הטבלה נפרדים בזמן הבדיקה. שימוש חוזר במספר אחד לשני תפקידים יוצר כלל שנראה נכון ומתאים לחבילות הלא נכונות. רשומת ברירת המחדל של הטבלה צריכה גם via עם שער ה-LAN בקישור Ethernet רגיל; dev eth0 חשוף עובד רק כשהממשק הוא נקודה לנקודה או כשהקפיצה הבאה נפתרת בדרך אחרת. המארח Jessie שדווח ישב במקרה על קישור שבו הצורה החשופה עבדה, וזה לא כלל הפצה להעתיק.

אמת בלי לנעול את עצמך בחוץ

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

ip route get 80.128.240.55

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

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