Rotering av proxy-IP-ar utan VPN: kva utgangen ser

Proxyrotasjon og ein VPN endrar den offentlege adressa di på ulike lag, og den skilnaden avgjer kva som lek. Ein VPN flyttar kvar pakke inn i ein tunnel, så kjeldadressa målet ser, er endepunktet til tunnelen. Ein proxy sit over nettverkslaget: berre førespurnadene du sender gjennom han, blir synlege frå utgangen, medan alt anna på maskina held på den verkelege adressa. Får du denne delinga rett, blir rotasjon frå ein avkryssingsboks til eit designval.

Kvar den offentlege adressa eigentleg kjem frå

Adressa eit mål ser, er den trafikken din sist forlét, og på ein heimekopling er det adressa til leverandøren på rutaren din, ikkje noko maskina eig. Å starte rutaren på nytt kan gje same leiga tilbake, og å endre MAC-adressa gir stundom ei ny, men ingen av delane gir deg eit landval. Ein VPN byter ut kjeldadressa på IP-laget, så kvar pakke frå maskina, inkludert DNS og bakgrunnsoppdateringar, forlèt endepunktet til tunnelen. Ein proxy arbeider eitt lag høgare: han tek imot ein førespurnad, opnar si eiga kopling til målet, og berre den førespurnaden blir synleg frå utgangen. Alt anna på maskina brukar framleis den verkelege adressa.

Denne delinga forklarer dei fleste overraskingane. Ei nettlesarutviding retta mot ein proxy endrar berre det nettlesaren sender, og ingenting anna, så ein annan applikasjon på same vert lek framleis den opphavlege adressa. Ein systemdekkjande VPN har den motsette feilmodusen: han dekkjer trafikk du ville halde lokal, og stenger berre om klienten er konfigurert til det. Å velje mellom dei to er eigentleg å velje kva trafikk som må flytte seg.

Rotasjonen gjeld då for det laget du valde. Med ein proxy tyder rotasjon at neste førespurnad brukar ein annan utgang. Med ein VPN tyder det å rive tunnelen og byggje han opp att, noko som er tregare og viser seg som ein synleg attkopling.

Kva ein HTTP-proxy kan lese, og kva han ikkje kan

Ved vanleg HTTP ser proxyen ein absolutt URI i førespurnadslinja, kvar header og kroppen. Han kan logge alt dette og skrive om kva del som helst, og difor gjer ein gratis proxy som injiserer eit skript i svar, nøyaktig det protokollen tillèt. Autentisering brukar Proxy-Authorization, og ein manglande eller feil legitimasjon gir 407 Proxy Authentication Required i staden for ein tilkoplingfeil.

Ved HTTPS sender klienten CONNECT host:port og proxyen opnar ein rå tunnel, og etterpå ser han krypterte byte. Han lærer framleis vertsnamnet frå CONNECT-linja og vanlegvis frå SNI-feltet i TLS-handtrykket, så logging på vertsnamnnivå overlever sjølv når nyttelasta ikkje gjer det. Å lese nyttelasta krev å avslutte TLS med eit sertifikat klienten stolar på, som er eit anna produkt med ein annan risiko. Den HTTP-semantikkspesifikasjonen definerer CONNECT som ein tunnelanamodning, som er den rette tankemodellen for kva ein utgang kan og ikkje kan sjå.

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

Den detaljerte utskrifta viser CONNECT-linja før nokon TLS-trafikk, og det er augneblinken proxyen lærer destinasjonen din. Ein proxy som svarar med 407, opna aldri tunnelen, så eit nytt forsøk med andre TLS-innstillingar hjelper ikkje.

Rotasjonsgranulariteten avgjer kva som knekk

Å rotere ved kvar førespurnad er innstillinga som ser tryggast ut og knekk mest. Informasjonskapslar, CSRF-token og sesjonar på tenarsida er bundne til ein identitet, og ein identitet som endrar seg mellom innlogginga og neste kall, ser ut som sesjonskapring for målet. Mange leverandørar tilbyr ein kleibruten sesjon ved å kode han i brukarnamnet til proxyen, så utgangen blir verande fast i eit valt vindauge.

Vel granulariteten ut frå oppgåva, ikkje frå standarden til leverandøren. Ein crawler som hentar uavhengige sider, kan rotere per førespurnad, medan ein betalingsflyt eller eit autentisert API må halde éin utgang gjennom heile flyten. Dei to kalla nedanfor viser eit kleibrute brukarnamn og eit vanleg roterande endepunkt, og socks5h skjemaet løyser namn hos proxyen i staden 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 ein stille lekkasje. Viss klienten løyser namnet før han koplar til, lærer resolvaren framleis kvar vert du besøkjer, sjølv om HTTP-førespurnaden forlèt ein annan stad. Den socks5h forma og oppløysinga på proxysida unngår det, og det kostar ingenting å bruke dei.

Kva målet klassifiserer utover adressa

Omdømet til adressa er éin inngang blant fleire. Mål kombinerer ASN og etiketten datasenter eller bustad, TLS-fingeravtrykket til klienten, HTTP/2-innstillingar, headerrækkjefølgje, førespurnadsrate og forma på navigasjonen. Ein bustadutgang driven av ein hovudlaus nettlesar kan feile der ein datasenterutgang driven av ein ekte sesjon går gjennom.

Utgangstypen fastset kva du ærleg kan påstå om trafikken, og kvar av dei har ein annan kostnad.

Ein delt utgang er ikkje nøytral. Alt anna som køyrer frå den adressa, landar i same omdømmebøtte, og ei adresse som andre leigetakarar alt har brent, feilar før den første førespurnaden din blir lesen.

Vel ein utgang du kan skildre i ein policy

Det nyttige spørsmålet er ikkje korleis du skjuler adressa, men kven som er ansvarleg for trafikken som forlèt henne. Din eigen skylutgang per oppgåve, ein kontrahert leverandør med ein databehandlingsavtale og publisert oppbevaring, og ein sjølvhosta VPN med éin identitet per oppgåve kan alle skildrast i éin setning. Ei gratis liste kan ikkje, fordi operatøren ikkje har noka forplikting overfor deg og har kvar grunn til å logge.

Hald dine eigne rategrenser under det målet toler, og samle berre felta oppgåva treng, slik at ein feil blir liten. Raskare rotasjon for å sleppe unna ei blokkering aukar vanlegvis førespurnadsraten som skapte henne.

Skriv den valde utgangen, rotasjonsvindauget og eigaren inn i jobbkonfigurasjonen før første køyring. Når blokkeringa kjem, er det notatet som fortel deg om du skal byte utgang eller endre åtferd.