Vad ProxyChains fångar upp och vad det lämnar i fred

ProxyChains-NG skapar ingen tunnel. Det förinläser ett bibliotek som ersätter nätverksrelaterade libc-anrop inne i det enda program det startar, så gränsen är ett anrop i en process, inte en rutt för hela enheten. Den skillnaden avgör vad ett lyckat test faktiskt bevisar. En fungerande curl genom kedjan bekräftar ett enda krokrat anrop, inte att namnuppslagning, UDP eller varje barnprocess följde samma väg. Handledningen nedan verifierar täckningen i tre steg och listar sedan vad kroken inte kan nå.

Hur förinläsningen når en anslutning

Vid start lägger startaren libproxychains i LD_PRELOAD och kör sedan målprogrammet. Biblioteket slår upp de riktiga libc-symbolerna och ersätter dem med egna versioner av funktioner som connect och getaddrinfo. Anrop som går genom dessa symboler skrivs om till SOCKS- eller HTTP-proxyn från konfigurationsfilen. Anrop som tar en annan väg möter aldrig kroken, och därför gäller garantin per anrop och inte per maskin.

Bara dynamiskt länkade program deltar, och setuid-binärer under säker körning ignorerar förinläsningen helt. Barnen ärver miljön, men bara så länge startaren håller den på plats.

Bekräfta att biblioteket är inläst i den processen

Starta begäran och undersök den levande processen i stället för skalet som startade den. Filen maps visar varje delat objekt som för närvarande är mappat in i processen.

proxychains4 -q curl -sS --max-time 8 https://example.com/ -o /dev/null &
pgrep -a curl
grep libproxychains /proc/$(pgrep -n curl)/maps

En träff bekräftar att det krokade biblioteket finns, vilket är nödvändigt men inte tillräckligt. Ett tomt resultat betyder oftast att du undersökte en annan process, till exempel en webbläsare som lämnade URL:en till en instans som startades före startaren. Kontrollera med ldd att binären är dynamiskt länkad innan du jagar något annat, eftersom en statisk bygge inte kan läsa in förinläsningen alls. Läs sedan proxy-listan i den konfiguration som startaren faktiskt använde, eftersom en inaktuell sökväg eller en stängd port ger en fungerande krok utan en fungerande kedja.

Spåra anslutningarna som lämnar processen

Bibliotekets närvaro bevisar inte att varje anrop skrevs om, så följ systemanropen. Kör en begäran under spåraren och läs vart socketarna faktiskt tog vägen.

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 -u

Spåret bör bara visa anslutningar till din proxy-slutpunkt, med porten som matchar posten i konfigurationsfilen. Om målsidans destinationsadresser dyker upp direkt i spåret kringgick det anropet kroken, och det är precis det fynd du letade efter. Jämför portnumren med proxy-listan i stället för att lita på filnamnet, eftersom en kvarbliven konfiguration från ett annat projekt är en vanlig källa till tyst direkt åtkomst. Spara spåret för acceptansprotokollet; det tar sekunder och avgör diskussioner om täckning.

Avgöra vad kroken inte kan täcka

proxychains-ng-projektet begränsar omdirigering till TCP och varnar för att skript, bakgrundsprocesser och inlästa moduler kan bete sig annorlunda än huvudprogrammet. UDP och ICMP ligger utanför mekanismen, så allt som förlitar sig på dem behöver sin egen stödda väg. DNS följer inställningen proxy_dns och applikationens egen resolverbeteende, vilket betyder att en lyckad HTTPS-begäran inte säger dig något om namnuppslagning. Behåll också certifikatvalideringen där den hör hemma: att nå en server via en proxy är inte skäl att stänga av identitetskontroller.

Om direkt återfall måste vara omöjligt, använd en verkställighetsgräns som styr trafiken själv, som ett nätverksnamnrymd, brandväggsregler eller en VPN, och håll den åtskild från bibliotekskroken. Kroken är ett kompatibilitetsverktyg för ett namngivet program, inte en kill switch. Anteckna programmet, det exakta kommandot, proxyporten som sågs i spåret och om DNS löstes på distans; de fyra fakta är skillnaden mellan en verifierad omfattning och en förhoppningsfull.