Rotering av proxy-IP-er uten VPN: hva utgangen ser

Proxyrotasjon og en VPN endrer den offentlige adressen din på forskjellige lag, og den forskjellen avgjør hva som lekker. En VPN flytter hver pakke inn i en tunnel, så kildeadressen målet ser, er tunnelens endepunkt. En proxy sitter over nettverkslaget: bare forespørslene du sender gjennom den, vises fra utgangen, mens alt annet på maskinen beholder den virkelige adressen. Får du denne delingen riktig, blir rotasjon fra en avkrysningsboks til en designbeslutning.

Hvor den offentlige adressen egentlig kommer fra

Adressen et mål ser, er den trafikken din sist forlot, og på en hjemmeforbindelse er det leverandørens adresse på ruteren din, ikke noe maskinen eier. Å starte ruteren på nytt kan gi samme leie tilbake, og å endre MAC-adressen gir noen ganger en ny, men ingen av delene gir deg et landvalg. En VPN erstatter kildeadressen på IP-laget, så hver pakke fra maskinen, inkludert DNS og bakgrunnsoppdateringer, forlater tunnelens endepunkt. En proxy jobber ett lag høyere: den godtar en forespørsel, åpner sin egen forbindelse til målet, og bare den forespørselen vises fra utgangen. Alt annet på maskinen bruker fortsatt den virkelige adressen.

Denne delingen forklarer de fleste overraskelsene. En nettleserutvidelse rettet mot en proxy endrer bare det nettleseren sender, og ingenting annet, så en annen applikasjon på samme vert lekker fortsatt den opprinnelige adressen. En systemdekkende VPN har den motsatte feilmodusen: den dekker trafikk du ville holde lokal, og lukker seg bare hvis klienten er konfigurert til det. Å velge mellom de to er egentlig å velge hvilken trafikk som må flytte seg.

Rotasjon gjelder da for det laget du valgte. Med en proxy betyr rotasjon at neste forespørsel bruker en annen utgang. Med en VPN betyr det å rive tunnelen og bygge den opp igjen, noe som er langsommere og viser seg som en synlig gjenoppkobling.

Hva en HTTP-proxy kan lese, og hva den ikke kan

Ved vanlig HTTP ser proxyen en absolutt URI i forespørselslinjen, hver header og kroppen. Den kan logge alt dette og skrive om hvilken som helst del, og derfor gjør en gratis proxy som injiserer et skript i svar, nøyaktig det protokollen tillater. Autentisering bruker Proxy-Authorization, og en manglende eller feil legitimasjon gir 407 Proxy Authentication Required i stedet for en tilkoblingsfeil.

Ved HTTPS sender klienten CONNECT host:port og proxyen åpner en rå tunnel, og deretter ser den krypterte byte. Den lærer fortsatt vertsnavnet fra CONNECT-linjen og vanligvis fra SNI-feltet i TLS-håndtrykket, så logging på vertsnavnnivå overlever selv når nyttelasten ikke gjør det. Å lese nyttelasten krever å avslutte TLS med et sertifikat klienten stoler på, som er et annet produkt med en annen risiko. Den HTTP-semantikkspesifikasjonen definerer CONNECT som en tunnelanmodning, som er den riktige tankemodellen for hva en utgang kan og ikke kan se.

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

Den detaljerte utskriften viser CONNECT-linjen før noen TLS-trafikk, og det er øyeblikket proxyen lærer destinasjonen din. En proxy som svarer med 407, åpnet aldri tunnelen, så et nytt forsøk med andre TLS-innstillinger hjelper ikke.

Rotasjonsgranulariteten avgjør hva som knekker

Å rotere ved hver forespørsel er innstillingen som ser sikrest ut og knekker mest. Informasjonskapsler, CSRF-tokens og sesjoner på serversiden er bundet til en identitet, og en identitet som endres mellom innloggingen og neste kall, ser ut som sesjonskapring for målet. Mange leverandører tilbyr en klebrig sesjon ved å kode den i proxyens brukernavn, så utgangen forblir fast i et valgt vindu.

Velg granulariteten ut fra oppgaven, ikke fra leverandørens standard. En crawler som henter uavhengige sider, kan rotere per forespørsel, mens en betalingsflyt eller et autentisert API må holde én utgang gjennom hele flyten. De to kallene nedenfor viser et klebrig brukernavn og et vanlig roterende endepunkt, og socks5h skjemaet løser navn hos proxyen i stedet for lokalt.

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

Lokal DNS er en stille lekkasje. Hvis klienten løser navnet før den kobler til, lærer resolvøren fortsatt hver vert du besøker, selv om HTTP-forespørselen forlater et annet sted. Den socks5h formen og oppløsningen på proxysiden unngår det, og det koster ingenting å bruke dem.

Hva målet klassifiserer utover adressen

Adressens omdømme er én inngang blant flere. Mål kombinerer ASN og dens etikett datasenter eller bolig, klientens TLS-fingeravtrykk, HTTP/2-innstillinger, headerrækkefølge, forespørselsrate og navigasjonens form. En boligutgang drevet av en hodeløs nettleser kan feile der en datasenterutgang drevet av en ekte sesjon går gjennom.

Utgangstypen fastsetter hva du ærlig kan påstå om trafikken, og hver av dem har en annen kostnad.

En delt utgang er ikke nøytral. Alt annet som kjører fra den adressen, lander i samme omdømmebøtte, og en adresse som andre leietakere allerede har brent, feiler før den første forespørselen din leses.

Velg en utgang du kan beskrive i en policy

Det nyttige spørsmålet er ikke hvordan du skjuler adressen, men hvem som er ansvarlig for trafikken som forlater den. Din egen skylutgang per oppgave, en kontrahert leverandør med en databehandlingsavtale og publisert oppbevaring, og en selvhostet VPN med én identitet per oppgave kan alle beskrives i én setning. En gratis liste kan ikke, fordi operatøren ikke har noen forpliktelse overfor deg og har hvert insentiv til å logge.

Hold dine egne rategrenser under det målet tåler, og samle bare feltene oppgaven trenger, slik at en feil forblir liten. Raskere rotasjon for å slippe unna en blokkering øker vanligvis forespørselsraten som forårsaket den.

Skriv den valgte utgangen, rotasjonsvinduet og eieren inn i jobbkonfigurasjonen før første kjøring. Når blokkeringen kommer, er det notatet som forteller deg om du skal bytte utgang eller endre atferd.