Redsocks מאזין ב-loopback אבל תעבורת VPN לא מגיעה לעולם

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

היכן באמת נוחתת חבילה שמופנית מחדש

proxy שקוף בשער משתמש ב-REDIRECT בטבלת nat ב-PREROUTING כדי לשכתב את היעד של חיבור נכנס לפורט מקומי. היעד המשוכתב הוא כתובת מקומית כפי שהיא נראית מהממשק שבו הגיעה החבילה, ולא כתובת ה-loopback של תהליך שהופעל במקום אחר. מאזין שמקושר רק ל-127.0.0.1 מקבל חיבורים שכבר היו מקומיים במארח, וזה בדיוק המקרה שממשיך לעבוד בזמן שתעבורת המנהרה נכשלת. ה-loopback של הלקוח עצמו הוא כתובת שלישית ולעולם אינו היעד של כלל השער.

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

קראו את המאזין ואת כלל ההפניה יחד

הדפיסו את טבלת ה-sockets ואת כללי ה-nat במעבר אחד, כי כלל שמצביע על פורט שאין לו בעלים נראה זהה לכלל שמצביע על הכתובת הלא נכונה. sudo ss -ltnp | grep redsocks מציג את כתובת הכריכה ואת התהליך הבעלים. sudo iptables -t nat -S PREROUTING מציג את יעד ה-REDIRECT, והפקודה sudo iptables -t nat -L PREROUTING -v -n מציגה אם משהו התאים לו.

קפיצה לשרשרת משתמש בשם REDSOCKS לא משיגה דבר אלא אם השרשרת קיימת ונושאת את ההחרגות המיועדות ואת פעולת ה-REDIRECT. קראו את השרשרת שאליה היא קופצת עם sudo iptables -t nat -S REDSOCKS במקום להניח שהשם עושה את העבודה.

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

כרכו בצמצום, ואז הגבילו מה יכול להגיע אליו

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

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

הוכיחו זאת בחיבור חדש מלקוח

בדקו מלקוח VPN אמיתי בחיבור TCP חדש, לא מ-shell בשער. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com בלקוח מפעיל את הנתיב המופנה מקצה לקצה.

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

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