פרוקסי SOCKS5 ל-OpenVPN: מנהרת TCP או פרוקסי לאפליקציות?

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

אילוץ אחד קובע את התכנון

SOCKS5 אכן מגדיר מצב שיוך UDP. עם זאת, תמיכת הפרוקסי של לקוח OpenVPN בנויה סביב זרמים: socks-proxy מתועד לפרופילי TCP, ולפרוקסי HTTP CONNECT אין שום נתיב לדאטהגרמים. שורת תיעוד אחת מכריעה את הארכיטקטורה לפני שאתם נוגעים בקובץ הגדרות.

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

אפשרות א': להפוך את המנהרה לזרם

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

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

החליפו את השורה האחרונה ב-http-proxy proxy.internal 8080 כאשר הפרוקסי מדבר HTTP, והוסיפו קובץ אישורים אם הוא דורש אחד. הפרוקסי חייב להסכים לבצע CONNECT לפורט ה-VPN שלכם, והשרת חייב לענות ב-TCP; מאזין UDP בלבד מתעלם מהניסיון. בחירה ב-443 היא מהלך מעשי, כי רשתות מגבילות רבות מאפשרות אותו ומעט אחר.

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

אפשרות ב': להניח למנהרה

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

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

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

היכן כל אפשרות נכשלת

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

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

אף אפשרות לא משנה את דרישת ההתקן. מנות עדיין צריכות צומת TUN או TAP לפני שהליבה תנתב אותן, כך שהתהליך עדיין צריך הרשאה על /dev/net/tun. עטיפה משנה מה קורה לאחר שהצומת הזה פתוח, לא אם אתם צריכים אותו.

להוכיח איזה נתיב בניתם

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

ss -tnp | grep openvpn

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

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