חיבור IPv6 בלבד, שירות IPv4: תנו לפרוקסי SOCKS לגשר

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

שני שקעים, שתי משפחות כתובות

בקשת SOCKS5 מכנה את היעד באחת משלוש צורות: כתובת v4 מילולית, כתובת v6 מילולית, או שם שהפרוקסי יפתור. הבקשה מתארת לאן הפרוקסי צריך להתחבר, לא איך נראה החיבור בין הלקוח לפרוקסי.

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

דוגמת SSH מבוקרת

קחו מארח SSH שמותר לכם להשתמש בו, שעונה על IPv6 ויכול בעצמו להגיע לשירות HTTPS שקיים רק ב-v4. העברה דינמית של OpenSSH מציבה מאזין SOCKS מקומי במחשב שלכם בשעה שסשן הכניסה רץ דרך v6.

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

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

כשהסשן פועל, הבקשה נראית כך:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

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

מה היעד באמת רואה

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

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

זה לא DNS64 ולא NAT64

DNS64 עונה ברשומות מסונתזות שמחליפות יעדי v4, ו-NAT64 כותב מחדש מנות לאורך נתיב מוגדר. אף אחד מהם אינו מתאר את מה שקורה כאן, שבו שיחת תעבורה אחת נגמרת ואחרת מתחילה ושום כתובת מסונתזת אינה מסבירה את התוצאה. לכן בקשה מוצלחת אינה אומרת דבר על אילו שירותי תרגום מפעיל הספק שלכם, והפרוקסי עשוי להריץ NAT רגיל ביציאה שלו עצמו.

שני המנגנונים יכולים להתקיים באותה רשת, לכן תארו את זה שבאמת אימתתם ולא את זה שנשמע קרוב יותר.

דעו את ההיקף לפני שאתם מבטיחים אותו

ההעברה הדינמית של OpenSSH נושאת חיבורי TCP, לא תעבורת IP שרירותית, לכן UDP, ICMP וכל פרוטוקול שמתעלם מהפרוקסי זקוקים לתכנון נתמך אחר. שמרו על אימות מפתח מארח SSH, על מגבלות ההעברה של השרת ועל אימות תעודת HTTPS, כי הפרוקסי הוא משתתף מהימן נוסף ולא סיבה להחליש בדיקות זהות. אם המטרה היא להעביר את התעבורה החיצונית של VPN דרך הפרוקסי, אמתו ששני הקצוות תומכים בתעבורה הזו במקום להניח שכל מאזין SOCKS יכול להעביר אותה.

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