ProxyChains-NG tidak membuat terowongan. Ia memuat lebih dahulu pustaka yang menggantikan panggilan libc terkait jaringan di dalam satu program yang diluncurkannya, jadi batasnya adalah panggilan dalam proses, bukan rute untuk seluruh perangkat. Perbedaan itulah yang menentukan apa yang sebenarnya dibuktikan oleh uji yang berhasil. curl yang berfungsi melalui rantai mengonfirmasi satu panggilan yang terkait, bukan bahwa resolusi nama, UDP atau setiap proses anak mengikuti jalur yang sama. Panduan di bawah memverifikasi cakupan dalam tiga langkah, lalu mendaftar apa yang tidak dapat dijangkau kait tersebut.

Bagaimana pramuat mencapai sebuah koneksi

Saat mulai, peluncur menempatkan libproxychains ke dalam LD_PRELOAD lalu menjalankan program target. Pustaka menyelesaikan simbol libc yang asli dan menggantinya dengan versinya sendiri untuk fungsi seperti connect dan getaddrinfo. Panggilan yang melewati simbol tersebut ditulis ulang ke proxy SOCKS atau HTTP dari berkas konfigurasi. Panggilan yang mengambil jalur lain tidak pernah bertemu kait, dan karena itu jaminannya berlaku per panggilan, bukan per mesin.

Hanya program yang ditautkan secara dinamis yang ikut serta, dan biner setuid di bawah eksekusi aman sama sekali mengabaikan pramuat. Proses anak mewarisi lingkungan, tetapi hanya selama peluncur menjaganya di tempatnya.

Pastikan pustaka termuat di proses itu

Mulai permintaan dan periksa proses yang hidup, bukan shell yang meluncurkannya. Berkas maps menunjukkan setiap objek bersama yang saat ini dipetakan ke proses.

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

Kecocokan memastikan pustaka yang terkait hadir, yang perlu tetapi tidak cukup. Hasil kosong biasanya berarti Anda memeriksa proses lain, misalnya peramban yang menyerahkan URL ke instans yang dimulai sebelum peluncur. Periksa dengan ldd bahwa biner ditautkan secara dinamis sebelum mengejar hal lain, karena build statis sama sekali tidak dapat memuat pramuat. Lalu baca daftar proxy dalam konfigurasi yang benar-benar dipakai peluncur, karena jalur yang usang atau port yang tertutup menghasilkan kait yang berfungsi tanpa rantai yang berfungsi.

Lacak koneksi yang meninggalkan proses

Kehadiran pustaka tidak membuktikan setiap panggilan ditulis ulang, jadi ikuti panggilan sistem. Jalankan satu permintaan di bawah pelacak dan baca ke mana soket benar-benar pergi.

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

Jejak seharusnya hanya menunjukkan koneksi ke titik akhir proxy Anda, dengan port yang cocok dengan entri di berkas konfigurasi. Jika alamat tujuan situs target muncul langsung di jejak, panggilan itu melewati kait, dan itulah temuan yang Anda cari. Bandingkan nomor port dengan daftar proxy alih-alih memercayai nama berkas, karena konfigurasi sisa dari proyek lain adalah sumber umum akses langsung yang senyap. Simpan jejak untuk catatan penerimaan; itu hanya butuh beberapa detik dan menyelesaikan perdebatan soal cakupan.

Putuskan apa yang tidak dapat dicakup kait

proyek proxychains-ng membatasi pengalihan ke TCP dan memperingatkan bahwa skrip, proses latar belakang dan modul yang dimuat dapat berperilaku berbeda dari program utama. UDP dan ICMP berada di luar mekanisme, jadi apa pun yang bergantung padanya memerlukan jalurnya sendiri yang didukung. DNS mengikuti pengaturan proxy_dns dan perilaku resolver aplikasi itu sendiri, yang berarti satu permintaan HTTPS yang berhasil tidak memberi tahu Anda apa pun tentang resolusi nama. Pertahankan juga validasi sertifikat di tempatnya: mencapai server melalui proxy bukan alasan untuk menonaktifkan pemeriksaan identitas.

Jika fallback langsung harus mustahil, gunakan batas penegakan yang mengendalikan lalu lintas itu sendiri, seperti ruang nama jaringan, aturan firewall atau VPN, dan jaga agar terpisah dari kait pustaka. Kait adalah alat kompatibilitas untuk program tertentu, bukan kill switch. Catat program, perintah persisnya, port proxy yang terlihat di jejak dan apakah DNS diselesaikan dari jarak jauh; keempat fakta itu adalah perbedaan antara cakupan yang terverifikasi dan cakupan yang berharap.

Artikel terkait