Rut URLSession-WebSockets gennem SOCKS5 på iOS 17+

Konfigurer URLSessionWebSocketTask gennem en SOCKSv5-proxy på sessionsniveau på iOS 17 eller nyere, og adskil routing fra WSS-dekryptering.

En iOS-apps almindelige HTTPS-anmodninger kan dukke op i en fejlretningsproxy, mens dens WebSocket-trafik mangler. Identificér først WebSocket-transporten: URLSessionWebSocketTask kan bruge en proxykonfiguration på sessionsniveau, mens et bibliotek, der åbner sine egne sockets, har brug for sin egen understøttede integration. For en rå Network.framework-forbindelse på iOS 17+ skal du konfigurere NWConnections egen proxykontekst.

På iOS 17 eller nyere opretter du sessionen med en eksplicit SOCKSv5-proxy:

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)
}

Erstat dokumentationsadressen og -porten med den tilgængelige SOCKS-lytter i den eksisterende fejlretningsproxy. Aktivér den lytter i proxyprogrammet. Dens HTTP-lytter kan være på en anden port.

Opret webSocketTask ud fra den returnerede session. En opgave, der er oprettet via en anden URLSession, arver ikke denne sessions tilsidesættelse. Et tomt proxyConfigurations-array bruger systemets standardindstillinger; det er ikke et udtrykkeligt valg af direkte rute.

Tilgængelighed og læsbare meddelelser er separate milepæle

En fysisk telefon har brug for en adresse, der når fejlretningscomputeren. På den telefon betegner 127.0.0.1 selve telefonen. Kontrollér lytterens interface og proxyens tilladte klientadgang, når forbindelsen aldrig når den.

En SOCKS-rute bærer forbindelsen. Læsning af wss-indhold kræver desuden fejlretningsværktøjets TLS-inspektionsopsætning og passende tillid på enheden. Certifikatpinning eller en separat TLS-implementering kan forhindre den inspektion, selv når trafikken når lytteren.

Kig efter WebSocket-udvekslingen og meddelelserne, efter at forbindelsen er oprettet. At se kun én pollinganmodning fra en Socket.IO-applikation er ikke bevis for, at dens senere WebSocket-transport brugte den samme rute. Hold denne udtrykkelige fejlretningskonfiguration inden for appens tilsigtede udviklingsopsætning.

Relaterede artikler