UDP דרך פורט SOCKS של Tor: מה לא עובר

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

בדקו מה האפליקציה באמת שולחת

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

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

מה ממשק ה-SOCKS של Tor יקבל

Tor מממש את הפקודה SOCKS5 CONNECT לחיבורי זרם ופקודות הרחבה לפתרון שמות, ולכן דפדפן עובד דרכו ללא שינוי. UDP ASSOCIATE, הפקודה שהייתה מאפשרת ללקוח למסור דאטהגרמות לפרוקסי להעברה, אינה חלק ממה ש-Tor מציע. התיעוד של ההרחבות נמצא במפרט הרחבות SOCKS של הפרויקט, והוא קצר. היעדר פקודת דאטהגרם הוא מכוון: העברה של UDP שרירותי הייתה נותנת לרשת תפקיד העברה שמעולם לא תוכנן עבורה.

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

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

הפעילו את הבדיקה לפי הסדר

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

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

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

חזרו אחורה ובחרו בכלי הנכון

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

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