לקוחות VPN מגיעים לשרת אבל לא ל-LAN: איזה תיקון?

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

קודם כל לאמת איזה כיוון שבור

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

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

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

שאלה ראשונה: האם אתם יכולים לערוך את הנתב של ה-LAN המרוחק?

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

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

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

שאלה שנייה: האם ה-LAN יכול להפסיק לראות כתובות של לקוחות?

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

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

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

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

שאלה שלישית: האם השרת עצמו הוא לקוח של מנהרה אחרת?

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

לאחר מכן אמתו את שני הכיוונים ואת שני הגדלים

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

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

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