ניתוב WebSocket של URLSession דרך SOCKS5 ב-iOS 17+

הגדירו את URLSessionWebSocketTask דרך פרוקסי SOCKSv5 ברמת הסשן ב-iOS 17 ואילך, והפרידו בין הניתוב לבין פענוח WSS.

בקשות HTTPS רגילות של אפליקציית iOS עשויות להופיע בפרוקסי לניפוי באגים בעוד שתעבורת ה-WebSocket שלה חסרה. זהו תחילה את תעבורת ה-WebSocket: URLSessionWebSocketTask יכול להשתמש בתצורת פרוקסי ברמת הסשן, ואילו ספרייה שפותחת שקעים משלה זקוקה לאינטגרציה נתמכת משלה. עבור חיבור Network.framework גולמי ב-iOS 17+, הגדירו את הקשר הפרוקסי של NWConnection עצמו.

ב-iOS 17 ואילך, צרו את הסשן עם פרוקסי SOCKSv5 מפורש:

import Foundation
import Network

@available(iOS 17.0, *)
func makeDebugSession() -> URLSession {
    let configuration = URLSessionConfiguration.default
    let endpoint = NWEndpoint.hostPort(
        host: "192.0.2.10", port: 8889)
    configuration.proxyConfigurations = [
        ProxyConfiguration(socksv5Proxy: endpoint)
    ]
    return URLSession(configuration: configuration)
}

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

צרו את ה-webSocketTask מהסשן המוחזר. משימה שנוצרה דרך URLSession אחרת אינה יורשת את העקיפה של סשן זה. מערך proxyConfigurations ריק משתמש בברירות המחדל של המערכת; זו אינה בחירה מפורשת במסלול ישיר.

נגישות והודעות קריאות הן אבני דרך נפרדות

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

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

חפשו את חילופי ה-WebSocket ואת ההודעות לאחר שהחיבור נוצר. ראיית בקשת סקר אחת בלבד מאפליקציית Socket.IO אינה הוכחה שתעבורת ה-WebSocket המאוחרת שלה השתמשה באותו מסלול. שמרו על תצורת הניפוי המפורשת הזו בתוך סביבת הפיתוח המיועדת של האפליקציה.

מאמרים קשורים