מדוע שרת מאחורי לקוח VPN עונה דרך המנהרה
חיבורים נכנסים נכשלים כאשר התשובות עוקבות אחר מסלול ברירת המחדל של ה-VPN במקום אחר נתיב ההגעה. ניתוב מדיניות או NAT מקור מחזירים את נתיב החזרה.
חיבורים נכנסים אל מארח שמריץ גם לקוח VPN נכשלים באופן מאוד ספציפי: לחיצת היד מגיעה, הדמון עונה, והלקוח לא מקבל דבר בחזרה. שום דבר לא חוסם את הפורט. התשובה יצאה דרך המנהרה, משום שהמנהרה מחזיקה במסלול ברירת המחדל והגרעין מנתב תשובות לפי יעד ולא לפי זיכרון של מקור הבקשה. הדמון תקין והפורט פתוח.
התשובה מנותבת, לא נזכרת
לקוח VPN שמתקין מסלול ברירת מחדל מוסיף רשומה שעוקפת את שער ה-LAN, בין אם לפי מדד ובין אם על ידי פיצול המרחב לשני חצאים ספציפיים יותר. חבילות יוצאות בוחרות כעת בממשק המנהרה. הגרעין לעולם לא שואל מהיכן הגיעה החבילה שמשיבים עליה במקור. אותה השמטה אחת מסבירה כל סימפטום שיבוא.
הכיוון קדימה מנותב לפי יעד, וכך גם הכיוון אחורה. התשובה ממוענת ללקוח ציבורי, שהמנהרה תישא בשמחה. הקצה המרוחק מקבל חבילה שאינו מחזיק במקור שלה, משליך אותה, והלקוח המקורי ממתין עד שהזמן יפוג.
סינון קפדני של נתיב החזרה עלול להשליך את החבילה הנכנסת לפני שהדמון קורא אותה בכלל. בדקו את המונה הזה קודם, כי השלכה על ידי מסנן ושגיאת ניתוב נראות זהות מבחוץ.
ip route show default sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter nft list ruleset | grep -A3 'hook forward'
הפקודה הראשונה מראה איזה מסלול ברירת מחדל מנצח כעת. השנייה מדווחת אם הסינון הקפדני חל באופן גלובלי או לפי ממשק, והשלישית מציגה כל כלל בשרשרת ההעברה שעשוי להיות מעורב.
שלוש דרכים לשמור על נתיב החזרה
החרגת יעד השירות מהמנהרה היא האפשרות הצרה ביותר. מסלול מארח המופנה אל שער ה-LAN, בתוספת דמון הכרוך בכתובת הפיזית ולא בכל כתובת, משאיר את הזרימה האחת מחוץ למנהרה. השינוי מקומי וקל לביטול.
ניתוב מדיניות הוא התשובה הכללית. כלל המבוסס על כתובת המקור או על סימן חומת אש בוחר טבלה שמסלול ברירת המחדל שלה מצביע אל שער ה-WAN, בעוד החיבורים של המארח עצמו ממשיכים להשתמש במנהרה. שמרו על עדיפות מפורשת כדי שהכלל לא יוצל בהמשך.
ip rule add from 203.0.113.25/32 table 100 priority 100 ip route add default via 192.0.2.1 dev eth0 table 100 ip route get 198.51.100.7 from 203.0.113.25
שתי הפקודות הראשונות בונות את הנתיב החלופי לתשובות שמקורן בכתובת הציבורית. השלישית שואלת את הגרעין איזה נתיב בדיוק ייקחו אותו מקור ויעד, וכך אתם מאשרים שלכלל יש השפעה כלשהי.
תרגום מקור הוא האפשרות השלישית והיחידה ששורדת מול נתב שכבר מבצע NAT לפני השירות. התשובה חייבת לחזור לנתב הזה, וההסתרה אל ממשק ה-WAN משיגה זאת תוך הסתרת הלקוח מיומני השירות. החלפת מסלול ברירת המחדל ביד לאחר ההתחברות היא אבחון, כי הלקוח כותב מחדש את הטבלה בהתחברות הבאה.
כאשר הקופסה מנתבת גם עבור LAN
אותה תקלה מופיעה קפיצה אחת רחוק יותר כאשר המארח מנתב עבור התקנים שמאחוריו. חיבור נכנס מועבר להתקן פנימי שנתיב החזרה היחיד שלו הוא המנהרה, והתשובה מגיעה ללקוח החיצוני מכתובת הספק. ההתקן הפנימי פועל כשורה כל הזמן.
מעקב החיבורים רואה אז תשובה לזרימה שמעולם לא תיעד והשליך אותה. תרגום יעד מוסר את החיבור הנכנס להתקן, ותרגום מקור גורם לתשובה להיראות כאילו יצאה מהנתב עצמו.
מסלול מדיניות שמשאיר את הפורט המועבר ב-WAN בעוד התעבורה של הנתב עצמו משתמשת במנהרה הוא המקבילה הנקייה יותר. בלי תרגום מקור התשובה ממוענת ללקוח החיצוני, ולהתקן הפנימי אין נתיב כלל לכתובת הזו.
שלוש בדיקות שמפרידות בין הסיבות
הריצו שלוש בדיקות: חיבור אל הקופסה מהאינטרנט, חיבור ממנה אל מארח ציבורי, ושאילתת שם. כאשר הראשונות שתיים חלוקות, נתיב החזרה אשם. כאשר שמות נכשלים בשני הכיוונים, הפותר הוא תקלה אחרת שרק חולקת את המנהרה.
תקנו קודם את שאלת הניתוב, ואז הביטו בשמות. ערבוב השניים הוא הדרך שבה שרת עובד מואשם בפותר שבור.
רשמו איזה ממשק החריגה מזכה ושמרו את התצורה תחת בקרת גרסאות. כלל שנכתב מול ממשק שמשונה שמו לאחר שדרוג עובר היום ונכשל לאחר האתחול הבא.