לקוח OpenVPN מגיע לשרת אך לא למארחי ה-LAN: רשימת בדיקה

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

שלב ראשון: התבוננו בהחלטת הניתוב של הלקוח

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

ip route get 192.168.50.10

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

ב-Windows לאותה שאלה יש פקודה אחרת. Find-NetRoute -RemoteIPAddress 192.168.50.10 מדפיס את הממשק ואת הקפיצה הבאה שהמחסנית הייתה בוחרת, ו-route print -4 מראה אם הקידומת שנדחפה קיימת בכלל.

שלב שני: אשרו שהשרת יעביר את החבילה

אם מסלול הלקוח נכון, החבילה מגיעה לשרת והשרת חייב להסכים להעביר אותה. מתג הליבה הוא השער הראשון, ו-sysctl net.ipv4.ip_forward חייב להחזיר 1. הגדרה עם echo 1 > /proc/sys/net/ipv4/ip_forward עובדת עד האתחול הבא, וזה בדיוק למה אותה תלונה חוזרת כעבור שבועות.

רשמו את זה במקום ששורד אתחול:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

השער השני הוא טבלת הסינון. מארח שעליו מותקן Docker נושא לעתים קרובות מדיניות FORWARD של DROP, והמנהרה יורשת את ההחלטה הזו. iptables -L FORWARD -v -n מציג גם את המדיניות וגם את מוני החבילות; אם המדיניות היא DROP, ההעברה דורשת אישור מפורש לכיוון מהמנהרה אל ה-LAN ואחד לתשובה.

שלב שלישי: עקבו אחר החבילה אל ה-LAN וחפשו את התשובה

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

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

בקשות שמופיעות על tun0 ושוב על eth0 עם מקור 10.8.0.x, ואחריהן שתיקה, פירושן שהחבילה הגיעה והתשובה הלכה למקום אחר. מארח ה-LAN עונה לשער ברירת המחדל שלו, לשער הזה אין מסלול עבור מאגר ה-VPN, והתשובה מתה בנתב ה-LAN. פינג למארח ה-LAN מהשרת לא מוכיח דבר על המסלול הזה, כי התעבורה הזו אף פעם לא חוצה את המנהרה.

שלב רביעי: בחרו בין תרגום לבין מסלול חזרה

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

הגבילו את הכלל למאגר ולממשק ה-LAN, ואז הפכו אותו לקבוע, אחרת טעינת חומת האש הבאה תסיר את התיקון שלכם בשקט. המחיר הוא זהות: כל לקוח נראה כמו שרת ה-VPN ביומני ה-LAN ובכללי הגישה, ו-per-client policy becomes guesswork.

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

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

סגרו את הלולאה מהלקוח, לא מהשרת. התחברו לשירות אמיתי במארח ה-LAN, ואז אשרו שמוני התרגום זזו עם iptables -t nat -L POSTROUTING -v -n, כי כלל עם אפס חבילות הוא כלל שמעולם לא התאים. conntrack -L -s 10.8.0.5 מציג את הזרימה ואת מצבה כשצריך הוכחה שכיוון החזרה נמצא במעקב.

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