OpenVPN עובד בבית אבל לא ברשת אחת: UDP או TCP?

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

השלב שנכשל מלמד איזו השוואה חשובה

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

צלמו בזמן הניסיון החוזר, לא אחריו. בלקוח, tcpdump -ni any udp port 1194 מראה אם חוזרת תשובה בכלל. חזרו על זה בממשק ה־WAN של שרת שאתם שולטים בו, מה שמגלה אם החבילות האלה מגיעות בכלל לקצה הרחוק.

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

סינון UDP לעומת פורט סגור

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

פרופיל TCP בפורט 443 הוא הפתרון המקובל, כי הוא דומה לזרימת HTTPS רגילה ועובר דרך רוב פורטלי הלכידה ומסנני היציאה. שני תנאים חייבים להתקיים. השרת חייב להאזין עם proto tcp-server והלקוח חייב להתאים עם proto tcp-client, והמפעיל חייב לפרסם את נקודת הקצה החלופית הזו. כתיבה מחדש של פרופיל UDP עובד כדי להצהיר על TCP 443 לא מגיעה לשום מקום כשבצד השני אף אחד לא מאזין.

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

פרוטוקולים ישנים יותר נמדדים רע בציר הזה. PPTP זקוק ל־TCP 1723 בתוספת GRE, ו־GRE הוא פרוטוקול IP מספר 47 ולא פורט, ולכן שום העברת פורט רגילה לא מבטאת אותו.

כשהמתג הוא זה שמפיל חבילות

מתג מנוהל יכול להפיל את המנהרה בכוונה. כמה דגמי HPE ו־Aruba מציעים במקטע האבטחה המתקדמת בקרת הגנת הצפה של UDP, שלפעמים מסומנת Prevent UDP Blat Attack. כשהבקרה הזו פעילה, שרת שיושב מאחורי המתג לא עונה דבר וכל לקוח מגיע לפקיעת זמן באותה צורה. כיבויה ושמירת התצורה הפעילה הם כל התיקון, אבל רק אחרי שתקבעו שהמתג באמת נמצא בנתיב.

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

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

חפיפת כתובות שנראית כמו כשל DNS

רשת גישה שממוספרת בתוך 10.0.0.0/8 יכולה לחפוף לבריכת המנהרה, והפותר בדרך כלל חי בתוך הבריכה הזו. כשמחשב נייד מקבל כתובת כמו 10.184.178.50 עם מסכת /8 ב־Wi-Fi, כל יעד 10.x הוא מקומי בהגדרה. חבילות אל 10.4.0.1 הולכות אז ל־LAN, המנהרה נשארת למעלה, ופתרון השמות נכשל.

ip addr חושף את החפיפה במבט אחד, ו־ip route get 10.4.0.1 מראה היכן החבילה תימסר באמת. מכיוון שהתסמין הנראה הוא כשל של הפותר, המקרה הזה שורד לעיתים קרובות כמה סבבים של שינויי DNS.

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

החלטה בין חלופת TCP לתיקון נתיב

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

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