Proxy-IP's rouleren zonder VPN: wat de uitgang ziet

Proxyrotatie en een VPN veranderen je openbare adres op verschillende lagen, en dat verschil bepaalt wat er lekt. Een VPN verplaatst elk pakket naar een tunnel, dus het bronadres dat het doel ziet is het eindpunt van de tunnel. Een proxy zit boven de netwerklaag: alleen de verzoeken die je erdoor stuurt verschijnen vanaf de uitgang, terwijl al het andere op de machine het echte adres houdt. Die splitsing goed krijgen maakt van rotatie een ontwerpbeslissing in plaats van een vinkje.

Waar het openbare adres echt vandaan komt

Het adres dat een doel ziet is het adres waar je verkeer het laatst vertrok, en op een thuisverbinding is dat het adres van de provider op je router, niet iets wat de machine bezit. De router herstarten kan dezelfde lease teruggeven, en het wijzigen van het MAC-adres levert soms een nieuwe op, maar geen van beide geeft je een landkeuze. Een VPN vervangt het bronadres op de IP-laag, dus elk pakket van de machine, inclusief DNS en achtergrondupdates, vertrekt vanaf het eindpunt van de tunnel. Een proxy werkt een laag hoger: hij accepteert een verzoek, opent zijn eigen verbinding naar het doel, en alleen dat verzoek verschijnt vanaf de uitgang. Al het andere op de machine gebruikt nog steeds het echte adres.

Die splitsing verklaart de meeste verrassingen. Een browserextensie die naar een proxy wijst, verandert alleen wat de browser verstuurt en niets anders, dus een tweede toepassing op dezelfde host lekt nog steeds het oorspronkelijke adres. Een systeembrede VPN heeft de omgekeerde faalmodus: hij dekt verkeer dat je lokaal wilde houden en sluit alleen als de client daarvoor is geconfigureerd. Kiezen tussen de twee is echt kiezen welk verkeer moet bewegen.

Rotatie geldt dan voor de laag die je hebt gekozen. Met een proxy betekent rotatie dat het volgende verzoek een andere uitgang gebruikt. Met een VPN betekent het de tunnel afbreken en opnieuw opbouwen, wat langzamer is en zich toont als een zichtbare herverbinding.

Wat een HTTP-proxy kan lezen, en wat niet

Bij gewone HTTP ziet de proxy een absolute URI in de verzoekregel, elke header en de body. Hij kan dat allemaal loggen en elk deel herschrijven, en daarom doet een gratis proxy die een script in antwoorden injecteert precies wat het protocol toestaat. Authenticatie gebruikt Proxy-Authorization, en een ontbrekende of verkeerde inloggegeven levert 407 Proxy Authentication Required in plaats van een verbindingsfout.

Bij HTTPS stuurt de client CONNECT host:port en de proxy opent een ruwe tunnel, waarna hij versleutelde bytes ziet. Hij leert nog steeds de hostnaam uit de CONNECT-regel en meestal uit het SNI-veld in de TLS-handshake, dus logging op hostnaamniveau overleeft ook als de payload dat niet doet. De payload lezen vereist TLS beëindigen met een certificaat dat de client vertrouwt, wat een ander product met een ander risico is. De HTTP-semantiekspecificatie definieert CONNECT als een tunnelverzoek, wat het juiste denkmodel is voor wat een uitgang wel en niet kan zien.

curl -v -x http://proxy.example.net:8080 https://example.com 2>&1 | grep -E 'CONNECT|Proxy-'

De uitgebreide uitvoer toont de CONNECT-regel vóór enig TLS-verkeer, en dat is het moment waarop de proxy je bestemming leert. Een proxy die met 407 antwoordt, heeft de tunnel nooit geopend, dus opnieuw proberen met andere TLS-instellingen helpt niet.

De granulariteit van de rotatie bepaalt wat er breekt

Bij elk verzoek rouleren is de instelling die het veiligst lijkt en het meest breekt. Cookies, CSRF-tokens en sessies aan de serverkant zijn gebonden aan een identiteit, en een identiteit die tussen de login en de volgende aanroep verandert, ziet er voor het doel uit als sessiekaping. Veel providers bieden een plakkerige sessie door die in de proxy-gebruikersnaam te coderen, zodat de uitgang voor een gekozen venster vast blijft.

Kies de granulariteit op basis van de taak, niet van de standaard van de provider. Een crawler die onafhankelijke pagina's ophaalt, kan per verzoek rouleren, terwijl een betaalstroom of een geauthenticeerde API één uitgang voor de hele stroom moet vasthouden. De twee aanroepen hieronder tonen een plakkerige gebruikersnaam en een gewoon roterend eindpunt, en de socks5h regeling lost namen op bij de proxy in plaats van lokaal.

curl -sS -x http://user-session-a1b2:[email protected]:8080 https://ifconfig.me
curl -sS -x socks5h://127.0.0.1:1080 https://ifconfig.me

Lokale DNS is een stille lek. Als de client de naam oplost voordat hij verbindt, leert de resolver nog steeds elke host die je bezoekt, ook al verlaat het HTTP-verzoek elders de machine. De socks5h vorm en de oplossing aan de proxykant vermijden dat, en ze gebruiken kost niets.

Wat het doel naast het adres classificeert

De reputatie van het adres is één invoer naast meerdere. Doelen combineren de ASN en het label datacenter of woonwijk, de TLS-vingerafdruk van de client, HTTP/2-instellingen, de volgorde van headers, de verzoekfrequentie en de vorm van de navigatie. Een woonuitgang die door een headless browser wordt bestuurd, kan falen waar een datacenteruitgang met een echte sessie doorkomt.

Het type uitgang bepaalt wat je eerlijk over het verkeer kunt beweren, en elk brengt andere kosten met zich mee.

Een gedeelde uitgang is niet neutraal. Al het andere dat vanaf dat adres draait, belandt in dezelfde reputatie-emmer, en een adres dat andere huurders al hebben verbrand, faalt voordat je eerste verzoek wordt gelezen.

Kies een uitgang die je in een beleid kunt beschrijven

De nuttige vraag is niet hoe je het adres verbergt, maar wie verantwoordelijk is voor het verkeer dat eruit vertrekt. Je eigen clouduitgang per taak, een gecontracteerde provider met een gegevensverwerkingsovereenkomst en gepubliceerde bewaring, en een zelf gehoste VPN met één identiteit per taak zijn allemaal in één zin te beschrijven. Een gratis lijst niet, want de beheerder heeft geen verplichting aan jou en heeft elk belang om te loggen.

Houd je eigen limieten onder wat het doel tolereert, en verzamel alleen de velden die de taak nodig heeft, zodat een fout klein blijft. Sneller rouleren om een blokkade te ontwijken verhoogt meestal de verzoekfrequentie die haar veroorzaakte.

Schrijf de gekozen uitgang, het rotatievenster en de eigenaar in de taakconfiguratie vóór de eerste run. Als de blokkade komt, is die notitie wat je vertelt of je de uitgang of het gedrag moet veranderen.