Rut URLSession-WebSockets gjennom SOCKS5 på iOS 17+

Konfigurer URLSessionWebSocketTask gjennom en SOCKSv5-proxy på sesjonsnivå på iOS 17 eller nyere, og skill ruting fra WSS-dekryptering.

En iOS-apps vanlige HTTPS-forespørsler kan dukke opp i en feilsøkingsproxy mens WebSocket-trafikken mangler. Identifiser først WebSocket-transporten: URLSessionWebSocketTask kan bruke en proxykonfigurasjon på sesjonsnivå, mens et bibliotek som åpner egne sockets trenger sin egen støttede integrasjon. For en rå Network.framework-tilkobling på iOS 17+ konfigurerer du NWConnections egen proxykontekst.

På iOS 17 eller nyere oppretter du sesjonen med en eksplisitt 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)
}

Erstatt dokumentasjonsadressen og -porten med den tilgjengelige SOCKS-lytteren i den eksisterende feilsøkingsproxyen. Aktiver den lytteren i proxyprogrammet. HTTP-lytteren kan være på en annen port.

Opprett webSocketTask fra den returnerte sesjonen. En oppgave som er opprettet via en annen URLSession, arver ikke denne sesjonens overstyring. En tom proxyConfigurations-matrise bruker systemets standardverdier; det er ikke et eksplisitt valg av direkte rute.

Tilgjengelighet og lesbare meldinger er separate milepæler

En fysisk telefon trenger en adresse som når feilsøkingsdatamaskinen. På den telefonen angir 127.0.0.1 selve telefonen. Kontroller lytterens grensesnitt og proxyens tillatte klienttilgang når tilkoblingen aldri når den.

En SOCKS-rute bærer tilkoblingen. Å lese wss-innhold krever i tillegg feilsøkingsverktøyets TLS-inspeksjonsoppsett og passende tillit på enheten. Sertifikatpinning eller en egen TLS-implementasjon kan hindre den inspeksjonen selv når trafikken når lytteren.

Se etter WebSocket-utvekslingen og meldingene etter at tilkoblingen er opprettet. Å se bare én pollingforespørsel fra en Socket.IO-applikasjon er ikke bevis for at dens senere WebSocket-transport brukte samme rute. Hold denne eksplisitte feilsøkingskonfigurasjonen innenfor appens tiltenkte utviklingsmiljø.

Relaterte artikler