VPN בין אתרים עובד בכיוון אחד בלבד: שתי תקלות שונות

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

ההבחנה הזו קובעת אילו פקודות שווה להריץ.

שתי תקלות שנראות זהות

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

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

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

מקרה ראשון: מסלול החזרה חסר

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

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

מקרה שני: המדיניות מעולם לא התירה זאת

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

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

השוו לפני ואחרי על אותם מארחים

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

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

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

לאחר תיקון, חזרו על אותה בדיקה מאותו מארח ואשרו שגישה שאינה קשורה עדיין נדחית. מצב מנהרה “established” אינו תומך באף אחת משתי המסקנות לבדו.