האם ספק האינטרנט חוסם UDP, או שזו האפליקציה בתוך המנהרה?

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

שתי כותרות, מילה אחת

בפריסת IPsec עם NAT-traversal, המנה החיצונית היא UDP הממוענת בין שתי נקודות הקצה של ה-VPN, בדרך כלל בפורט 4500. בפנים, המטען המוצפן נושא כל מה שהמנהרה מעבירה, ואפשר שהוא עצמו TCP או UDP. לכן המילה UDP מופיעה פעמיים, במשמעות ונראות שונות.

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

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

מה הרשת עדיין יכולה לראות

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

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

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

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

למה אפליקציית UDP אחת נכשלת בתוך מנהרה שעובדת

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

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

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

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

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

דווחו על השכבה, לא על הפרוטוקול

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

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

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