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

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

שתי שרשראות, שני יעדים שונים

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

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

מה כלל המאזין באמת מתיר

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

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

בדקו מלקוח, לעולם לא מהשער

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

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

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

ההעברה דורשת שלושה דברים, לא אחד

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

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

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

הפרידו בין שתי מערכות הכללים בתיעוד

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

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

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