Kva ProxyChains fangar opp, og kva det lèt vere
ProxyChains hektar bibliotekkall i programmet det startar. Stadfest TCP-dekninga med maps, strace og éin førespurnad, og slutt å tru at DNS eller UDP følgjer etter.
ProxyChains-NG lagar ingen tunnel. Det førehandslastar eit bibliotek som erstattar nettverksrelaterte libc-kall inne i det eine programmet det startar, så grensa er eit kall i ein prosess, ikkje ei rute for heile eininga. Den skilnaden avgjer kva ein vellukka test faktisk provar. Ein fungerande curl gjennom kjeda stadfestar eitt hekta kall, ikkje at namneoppslag, UDP eller kvar barneprosess følgde same veg. Rettleiinga nedanfor stadfestar dekninga i tre trinn og listar deretter opp kva hekta ikkje kan nå.
Korleis førehandslastinga når ei tilkopling
Ved oppstart legg startaren libproxychains inn i LD_PRELOAD og køyrer deretter målprogrammet. Biblioteket slår opp dei ekte libc-symbola og erstattar dei med eigne versjonar av funksjonar som connect og getaddrinfo. Kall som går gjennom desse symbola, vert skrivne om til SOCKS- eller HTTP-proxyen frå konfigurasjonsfila. Kall som tek ein annan veg, møter aldri hekta, og difor gjeld garantien per kall og ikkje per maskin.
Berre dynamisk lenka program deltek, og setuid-binærfiler under sikker køyring ignorerer førehandslastinga heilt. Borna arvar miljøet, men berre så lenge startaren held det på plass.
Stadfest at biblioteket er lasta inn i den prosessen
Start førespurnaden og undersøk den levande prosessen i staden for skalet som starta han. Fila maps viser kvart delt objekt som for tida er mappa inn i prosessen.
proxychains4 -q curl -sS --max-time 8 https://example.com/ -o /dev/null &
pgrep -a curl
grep libproxychains /proc/$(pgrep -n curl)/mapsEit treff stadfestar at det hekta biblioteket er til stades, noko som er naudsynt, men ikkje tilstrekkeleg. Eit tomt resultat tyder vanlegvis at du undersøkte ein annan prosess, til dømes ein nettlesar som gav URL-en vidare til ein instans som vart starta før startaren. Kontroller med ldd at binærfila er dynamisk lenka før du jagar noko anna, fordi eit statisk bygg ikkje kan lasta førehandslastinga i det heile. Les deretter proxy-lista i konfigurasjonen som startaren faktisk brukte, sidan ein utdatert stig eller ein lukka port gjev ei fungerande hekte utan ei fungerande kjede.
Spor tilkoplingane som forlèt prosessen
Tilveret av biblioteket provar ikkje at kvart kall vart skrive om, så følg systemkalla. Køyr éin førespurnad under sporinga og les kvar soklane faktisk gjekk.
strace -f -e trace=connect -o /tmp/pc.trace proxychains4 -q curl -sS https://example.com/ -o /dev/null
grep -o "sin_port=htons([0-9]*)" /tmp/pc.trace | sort -uSporet skal berre visa tilkoplingar til proxy-endepunktet ditt, med porten som svarar til oppføringa i konfigurasjonsfila. Viss destinasjonsadressene til målområdet viser seg direkte i sporet, tyder det at det kallet gjekk utanom hekta, og det er nettopp funnet du leitte etter. Samanlikn portnummera med proxy-lista i staden for å stole på filnamnet, fordi ein restkonfigurasjon frå eit anna prosjekt er ei vanleg kjelde til stille direkte tilgang. Ta vare på sporet for akseptprotokollen; det tek sekundar og avgjer diskusjonar om dekning.
Avgjer kva hekta ikkje kan dekkje
proxychains-ng-prosjektet avgrensar omdirigering til TCP og åtvarar om at skript, bakgrunnsprosessar og innlasta modular kan oppføre seg annleis enn hovudprogrammet. UDP og ICMP ligg utanfor mekanismen, så alt som er avhengig av dei treng sin eigen støtta veg. DNS følgjer innstillinga proxy_dns og åtferda til resolvaren til applikasjonen sjølv, noko som tyder at éin vellukka HTTPS-førespurnad ikkje seier deg noko om namneoppslag. Hald òg sertifikatvalideringa der ho høyrer heime: å nå ein tenar gjennom ein proxy er ikkje grunn til å slå av identitetskontrollar.
Viss direkte tilbakefall må vere umogeleg, bruk ei handhevinggrense som styrer trafikken sjølv, som eit nettverksnamnerom, brannmurreglar eller ein VPN, og hald ho skild frå bibliotekhekta. Hekta er eit kompatibilitetsverktøy for eit namngjeve program, ikkje ein kill switch. Noter programmet, den nøyaktige kommandoen, proxy-porten som vart sett i sporet og om DNS vart løyst eksternt; desse fire fakta er skilnaden mellom eit stadfesta omfang og eit håpefullt eit.