Dante SOCKS על loopback לשירות HTTPS דרך WireGuard בלבד

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

הדוגמה מניחה ש-Dante 1.4.x מותקן כמופע ייעודי ומנוהל בתחנת עבודה מהימנה של Linux, כאשר חשבון השירות והגדרת התיעוד שמספק החבילה נשארים במקומם. תחנת העבודה מחזיקה ב-10.77.0.2 בממשק ה-WireGuard שלה, מגיעה אל 10.60.0.20:443 דרך המנהרה הזו, והשם התקני של השירות הוא app.corp.example.

שלב 1: קשרו את המאזין ל-loopback בלבד

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

internal: 127.0.0.1 port = 1080
external: 10.77.0.2
external.protocol: ipv4
clientmethod: none
socksmethod: none

client pass {
    from: 127.0.0.1/32 to: 127.0.0.1/32
}

socks pass {
    from: 127.0.0.1/32 to: 10.60.0.20/32 port = 443
    command: connect
    protocol: tcp
}

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

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

שלב 2: כתבו שני כללים, לא אחד

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

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

שלב 3: ודאו את הנתיב מהמקור הנכון

external בוחר כתובת מקור יוצאת; הוא לא מתקין נתיב WireGuard. חיפוש לקריאה בלבד עבור המקור והיעד של הדוגמה:

ip -4 route get 10.60.0.20 from 10.77.0.2

הריצו זאת במרחב השמות האמיתי של הרשת של Dante, ולא בשום מעטפת שנפתחה לכם. הנתיב, בחירת העמית ב-WireGuard, ההרשאה בצד המרוחק ונתיב החזרה — כולם חייבים להתאים לכתובת המקור הזו. חיפוש מוצלח הוא הכרחי ולא מספיק, כי הוא לא אומר דבר על האם הקצה המרוחק מקבל את הבקשה.

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

שלב 4: בדקו עם הזהות המיועדת

לאחר שהבעלים מאמת את הקונפיגורציה המותקנת ומפעיל את המופע דרך מנהל השירותים שלו, בקשה להמחשה היא:

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' https://app.corp.example/

עם socks5h, Dante מבצע את פתרון היעד, אבל Dante רץ בתחנת העבודה הזו, ולכן ההגדרה לא שולחת DNS לקצה המרוחק של המנהרה בעצמה. הפותר המאושר שבו Dante משתמש חייב להחזיר את הכתובת המותרת עבור אותו שם. רשימת ה-no-proxy הריקה מונעת מחריגה בת-ירושה לעקוף את SOCKS בשקט.

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

שלב 5: החליטו מה קורה כשהמנהרה נופלת

בדקו אובדן מנהרה והפעלה מחדש של המופע לפני שאתם קוראים לזה ייצור. מבקר שמפעיל את Dante אחרי WireGuard לא יוצר ניתוב fail-closed, והוא גם לא יוצר DNS fail-closed; את שניהם יש לאכוף דרך בעל הרשת. הביטו במה שהיישום עושה כשהמנהרה למטה: שגיאה נקייה היא תוצאה טובה, נפילה שקטה לפותר ציבורי אינה.

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