איזו חבילה צריכה מדיניות VPN עם שני קווי WAN להתאים?

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

תנו שם לשני השיחות

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

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

מצאו איפה המדיניות שלכם באמת יכולה לראות את החבילה

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

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

אשרו את ההובלה שעליה סיכמתם

עבור IPsec עטוף ב-UDP, RFC 3948 מציב את ESP בתוך UDP ומשתמש בסמן שאינו ESP כדי ש-IKE יישאר מובחן ביציאה המשותפת. ESP רגיל הוא פרוטוקול IP, לא יציאת TCP או UDP, ולכן כלל חומת אש שנכתב לפי מספר יציאה לא יתאים לו כלל. ההבחנה הזו קובעת אם מדיניות ה-WAN שלכם זקוקה לכלל UDP, לכלל פרוטוקול או לשניהם.

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

בדקו את נתיב החזרה לפני שאתם מתחייבים

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

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

אמתו את שתי השכבות עם שתי לכידות

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

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

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