Relay מסוג stream ב-Nginx עבור UDP של OpenVPN: מה זה משנה

הלקוח שלכם מוגדר ל-UDP, לשרת ה-Nginx יש בלוק location שמצביע על פורט ה-VPN, ותו לא מגיע. זה צפוי: location של HTTP אינו יכול לשאת דאטהגרם UDP, יהיה שם החזית אשר יהיה. Nginx זקוק למאזין stream לשם כך, ולאחר שתעבירו לשם את התצורה, קבוצה שנייה של פרטים מחליטה אם הפגישה תשרוד.

שכבת ה-proxy באה לפני הכתובת

מודול ה-stream של Nginx עושה proxy ל-TCP ול-UDP בלי לנתח HTTP. מודול ה-HTTP שלו מצפה לשורת בקשה, כותרות ותגובה, ושום דבר מזה לא נמצא בדאטהגרם OpenVPN מקורי. בחירת השכבה היא אפוא ההחלטה הראשונה, והיא בלתי תלויה בשאלה אם המאזין הוא IPv4 או IPv6.

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

המאזין וה-backend

nginx -V 2>&1 | tr ' ' '\n' | grep stream

stream {
    server {
        listen [::]:1194 udp reuseport;
        proxy_pass [2001:db8::20]:1194;
    }
}

ודאו שה-build כולל את מודול ה-stream לפני עריכה כלשהי; חבילת הפצה עשויה לפצל אותו למודול נפרד, ומודול חסר מייצר שגיאת תצורה ולא מנהרה. שימו את הבלוק בהקשר התצורה הראשי, לא בתוך http, והחליפו את כתובת התיעוד ב-backend האמיתי.

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

פסקי זמן של פגישה אינם פסקי זמן של בקשה

ה-proxy מסוג stream שומר מצב עבור פגישת UDP וזורק אותו לפי פסק הזמן והגדרות התגובה שלו. פסק זמן קצר שהועתק מ-relay של DNS מתאים בצורה גרועה ל-VPN שמצפה להחליף דאטהגרמים במשך שעות, והכשל מופיע כחיבור שמת בשקט ולא כזה שמסרב להתחיל.

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

מה ה-relay משנה ומה לא

ה-proxy מסוג stream אינו מסיים את ערוץ הבקרה של TLS של OpenVPN ואינו ממיר אותו ל-HTTPS. ה-backend נשאר שירות ה-VPN, ויחסי התעודה נשארים בין הלקוח לאותו שירות. שמירה על זהות ה-backend המיועדת היא עדיין תפקידם של הלקוח והשרת.

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

אמתו מהלקוח, לא מהפורט

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

כשמישהו מדווח ש-Nginx לא יודע UDP כי כלי relay פשוט עבד במקומו, שתי העובדות אינן קשורות זו לזו. הכלי הוכיח שה-backend עונה; הוא לא אמר דבר על מה שהחזית תומכת בו. שתיהן יכולות להיות נכונות, ורק אחת מהן היא תצורה לפריסה הזו.