הגעה ללקוח IKEv2 בכתובת ה-IP הווירטואלית שהוקצתה לו

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

המנהרה לא מתקנת את כתובת המקור

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

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

קרא את המדיניות המותקנת, לא את קובץ התצורה

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

ipsec statusall
ip xfrm policy

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

הלקוח חייב להאזין במקום שאליו החבילה מגיעה

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

ss -ltnp 'sport = :9090'
iptables -S INPUT

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

בדוק את הכיוון החדש בנפרד

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

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

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

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