Redsocks mendengarkan di loopback tetapi lalu lintas VPN tidak pernah tiba
Pendengar yang hanya terikat ke loopback tidak pernah melihat lalu lintas yang dialihkan dari tun0. Baca target pengalihan dan pengikatan socket, perbaiki pengikatan, lalu uji dari klien sungguhan.
Sebuah terowongan menyala, klien dapat melakukan ping ke gateway, dan setiap permintaan web melalui jalur proxy mati. Proses redsocks berjalan dan portnya mendengarkan, jadi layanan tampak sehat dari gateway itu sendiri. Yang gagal adalah langkah pengiriman: paket yang dialihkan dari terowongan tidak mendarat di socket yang Anda jalankan. Alamat pengikatan dan target pengalihan harus sepakat, dan biasanya hanya salah satunya yang diperiksa.
Ke mana paket yang dialihkan sebenarnya mendarat
Proxy transparan di gateway memakai REDIRECT di tabel nat pada PREROUTING untuk menulis ulang tujuan koneksi masuk ke port lokal. Tujuan yang ditulis ulang adalah alamat lokal sebagaimana dilihat dari antarmuka tempat paket tiba, bukan alamat loopback proses yang dijalankan di tempat lain. Pendengar yang hanya terikat ke 127.0.0.1 menerima koneksi yang memang sudah lokal di host, dan itulah tepatnya kasus yang terus bekerja sementara lalu lintas terowongan gagal. Loopback milik klien sendiri adalah alamat ketiga dan tidak pernah menjadi target aturan gateway.
Jadi sebelum menyentuh kredensial hulu, tetapkan dua fakta: alamat lokal mana yang ditulis ulang oleh aturan, dan alamat mana socket proxy terikat.
Baca pendengar dan aturan pengalihan bersama-sama
Cetak tabel socket dan aturan nat dalam satu lintasan, sebab aturan yang menunjuk port yang tidak dimiliki siapa pun tampak identik dengan aturan yang menunjuk alamat yang salah. sudo ss -ltnp | grep redsocks menunjukkan alamat pengikatan dan proses pemiliknya. sudo iptables -t nat -S PREROUTING menunjukkan target REDIRECT, dan sudo iptables -t nat -L PREROUTING -v -n menunjukkan apakah ada yang cocok dengannya.
Lompatan ke rantai pengguna bernama REDSOCKS tidak mencapai apa pun kecuali rantai itu ada dan membawa pengecualian yang dimaksud serta aksi REDIRECT. Baca rantai yang menjadi tujuannya dengan sudo iptables -t nat -S REDSOCKS alih-alih menganggap namanya yang melakukan pekerjaan.
Lalu bandingkan kedua nilai. Jika aturan mengalihkan ke alamat gateway pada port 12345 dan pendengar melaporkan 127.0.0.1:12345, ketidakcocokan itu menjelaskan kegagalan tanpa diagnosis tambahan.
Ikat secara sempit, lalu batasi apa yang bisa mencapainya
Konfigurasi contoh hulu menjadikan loopback default bagi pendengar karena alasan bagus: proxy transparan menerima koneksi atas nama siapa pun yang bisa mencapainya. Mengubah pengikatan ke 0.0.0.0 memperbaiki pengiriman dan sekaligus membuka port di setiap antarmuka, yang merupakan perubahan keamanan, bukan perbaikan netral. Lebih baik ikat ke alamat lokal tertentu yang menjadi target pengalihan, dan biarkan port tertutup pada antarmuka yang tidak tepercaya. Jika pengikatan lebih lebar tidak terhindarkan, tambahkan aturan firewall host yang hanya mengizinkan rentang sumber terowongan dan lalu lintas lokal gateway itu sendiri.
Membuka port pada antarmuka publik tidak pernah diperlukan untuk lalu lintas VPN yang dialihkan, karena koneksi berakhir secara lokal setelah penulisan ulang. Jangan memaparkan proxy ke internet agar pengalihan lokal berfungsi.
Buktikan dengan koneksi baru dari klien
Uji dari klien VPN sungguhan dengan koneksi TCP baru, bukan dari shell di gateway. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com di klien menjalankan jalur yang dialihkan dari ujung ke ujung.
Lalu pastikan bahwa koneksi langsung ke pendengar dari jaringan tidak tepercaya masih ditolak, dan bahwa koneksi hulu proxy itu sendiri tidak tertangkap lagi oleh aturan yang sama. Penangkapan rekursif tampak sebagai proxy yang menyambung ke dirinya sendiri dan tidak pernah menyelesaikan permintaan. Tambahkan tujuan proxy ke himpunan pengecualian, atau tandai paket keluarnya agar rantai melewatinya.
Terakhir, ingat apa yang tidak dicakup jalur ini. Pengalihan TCP redsocks biasa tidak mengubah UDP, QUIC, atau DNS menjadi lalu lintas SOCKS, dan tujuan privat biasanya memerlukan pengecualian eksplisit. Uji lokal yang berhasil hanya membuktikan jalur loopback yang tidak pernah menjadi masalah.