Diagnosticarea eșecurilor Proxychains LD_PRELOAD
Diagnosticați eșecurile LD_PRELOAD și limitele interceptării înainte de a presupune că o aplicație a folosit proxy-ul configurat.
Programul pornește, dar terminalul spune că o bibliotecă proxychains nu a putut fi preîncărcată. Tratați asta ca pe un pas de configurare eșuat, nu ca pe un avertisment inofensiv de ignorat când verificați IP-ul de ieșire.
Proxychains-ng se bazează pe o bibliotecă încărcată pentru a intercepta apelurile relevante. Dacă biblioteca lipsește, este incompatibilă sau nu este încărcată în proces, programul poate rula fără interceptarea așteptată.
Potrivirea bibliotecii cu procesul
Verificați locația reală a bibliotecii pachetului și arhitectura executabilului. Un răspuns vechi care fixează o cale pe 32 de biți nu este o reparație generală pentru un program pe 64 de biți. Nu adăugați o setare de preîncărcare neverificată global la fiecare sesiune shell.
Manualul încărcătorului dinamic din Linux explică căutarea bibliotecilor și restricțiile de execuție sigură. Unele situații de lansare a proceselor ignoră sau restricționează intenționat setările de preîncărcare. Un executabil static nu devine nici el interceptabil dinamic doar pentru că a fost setată o variabilă de mediu.
README-ul proiectului documentează modelul acceptat al wrapperului. Aplicațiile cu propria implementare de rețea, procese auxiliare separate sau instanțe deja în execuție pot introduce alte limite chiar și când biblioteca inițială se încarcă.
O setare nativă de proxy în aplicație poate fi o opțiune mai clară atunci când este disponibilă. Folosește interfața de rețea vizată de aplicație în loc să presupună că fiecare conexiune poate fi capturată din exterior.
La o configurare eșuată a wrapperului, opriți-vă și stabiliți ce a fost lansat de fapt. Doar starea de ieșire a procesului poate arăta că aplicația a rulat, nu că traficul ei a urmat proxy-ul. Păstrați încărcarea bibliotecii, apelurile interceptate și conexiunea de ieșire observată ca dovezi separate.