Rut URLSession-WebSockets via SOCKS5 på iOS 17+

Sett opp URLSessionWebSocketTask via en SOCKSv5-proxy på sesjonsnivå på iOS 17 eller høyere, og hold ruting atskilt fra WSS-dekryptering.

Vanlige HTTPS-forespørsler fra en iOS-app kan dukke opp i en feilsøkingsproxy mens WebSocket-trafikken mangler. Finn først ut hvilken WebSocket-transport som brukes: URLSessionWebSocketTask kan bruke en proxykonfigurasjon på sesjonsnivå, mens et bibliotek som åpner sine egne sockets trenger en egen støttet integrasjon. For en rå Network.framework-forbindelse på iOS 17+ setter du opp NWConnections egen proxykontekst.

På iOS 17 eller høyere lager 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)
}

Bytt ut adressen og porten fra dokumentasjonen med den tilgjengelige SOCKS-lytteren til den eksisterende feilsøkingsproxyen. Slå på den lytteren i proxyprogrammet. HTTP-lytteren kan ligge på en annen port.

Lag webSocketTask fra sesjonen som returneres. En oppgave som lages gjennom en annen URLSession, arver ikke overstyringen fra denne sesjonen. En tom proxyConfigurations-matrise bruker systemets standardverdier; det er ikke et uttrykkelig valg av direkte rute.

Nåbarhet og lesbare meldinger er to ulike milepæler

En fysisk telefon trenger en adresse som når fram til feilsøkingsmaskinen. På den telefonen peker 127.0.0.1 på selve telefonen. Sjekk grensesnittet til lytteren og den tillatte klienttilgangen i proxyen når forbindelsen aldri kommer fram.

En SOCKS-rute frakter forbindelsen. Å lese wss-innhold krever i tillegg at feilsøkingsverktøyet er satt opp for TLS-inspeksjon, og at enheten har riktig tillit. Sertifikatpinning eller en separat TLS-implementasjon kan blokkere den inspeksjonen selv om trafikken når lytteren.

Let etter WebSocket-utvekslingen og meldingene når forbindelsen er etablert. Å bare se én polling-forespørsel fra en Socket.IO-applikasjon beviser ikke at den senere WebSocket-transporten brukte samme rute. Hold denne uttrykkelige feilsøkingskonfigurasjonen innenfor appens tiltenkte utviklingsmiljø.

Relaterte artikler