לקוח VPN מנותב מגיע לשרת אך לא למארחי ה-LAN

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

עקבו אחרי התגובה, לא אחרי הבקשה

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

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

שימו את נתיב החזרה במקום שבו המארחים מסתכלים

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

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

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

למה NAT מקור נראה כאילו הוא מתקן את זה

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

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

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

הנתיב בענן דורש שלושה הגדרות

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

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

הריצו את הבדיקות בסדר הזה

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

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

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

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