Redsocks mendengar pada loopback tetapi trafik VPN tidak pernah tiba
Pendengar yang terikat hanya pada loopback tidak pernah melihat trafik yang dialihkan dari tun0. Baca sasaran ubah hala dan ikatan soket, betulkan ikatan, kemudian uji dari klien sebenar.
Sebuah terowong naik, klien boleh ping gateway, dan setiap permintaan web melalui laluan proksi mati. Proses redsocks berjalan dan portnya mendengar, jadi perkhidmatan kelihatan sihat dari gateway itu sendiri. Yang gagal ialah langkah penghantaran: paket yang dialihkan dari terowong tidak mendarat pada soket yang anda mulakan. Alamat ikatan dan sasaran ubah hala mesti sepadan, dan biasanya hanya salah satunya diperiksa.
Ke mana paket yang dialihkan sebenarnya mendarat
Proksi telus pada gateway menggunakan REDIRECT dalam jadual nat di PREROUTING untuk menulis semula destinasi sambungan masuk ke port tempatan. Destinasi yang ditulis semula ialah alamat tempatan seperti yang dilihat dari antara muka tempat paket tiba, bukan alamat loopback proses yang dimulakan di tempat lain. Pendengar yang terikat hanya pada 127.0.0.1 menerima sambungan yang sudah tempatan pada hos, dan itulah tepatnya kes yang terus berfungsi semasa trafik terowong gagal. Loopback klien sendiri ialah alamat ketiga dan tidak pernah menjadi sasaran peraturan gateway.
Jadi sebelum menyentuh kelayakan huluan, tetapkan dua fakta: alamat tempatan mana yang ditulis semula oleh peraturan, dan alamat mana soket proksi terikat.
Baca pendengar dan peraturan ubah hala bersama-sama
Cetak jadual soket dan peraturan nat dalam satu laluan, kerana peraturan yang menunjuk ke port yang tiada pemilik kelihatan sama seperti peraturan yang menunjuk ke alamat yang salah. sudo ss -ltnp | grep redsocks menunjukkan alamat ikatan dan proses pemiliknya. sudo iptables -t nat -S PREROUTING menunjukkan sasaran REDIRECT, dan sudo iptables -t nat -L PREROUTING -v -n menunjukkan sama ada sesuatu sepadan dengannya.
Lompatan ke rantai pengguna bernama REDSOCKS tidak mencapai apa-apa melainkan rantai itu wujud dan membawa pengecualian yang dimaksudkan serta tindakan REDIRECT. Baca rantai yang dilompatinya dengan sudo iptables -t nat -S REDSOCKS dan bukannya menganggap namanya melakukan kerja itu.
Kemudian bandingkan kedua-dua nilai. Jika peraturan mengalihkan ke alamat gateway pada port 12345 dan pendengar melaporkan 127.0.0.1:12345, ketidakpadanan itu menjelaskan kegagalan tanpa sebarang diagnosis tambahan.
Ikat dengan sempit, kemudian hadkan apa yang boleh mencapainya
Konfigurasi contoh huluan menetapkan pendengar ke loopback atas sebab yang baik: proksi telus menerima sambungan bagi pihak sesiapa yang boleh mencapainya. Menukar ikatan kepada 0.0.0.0 membetulkan penghantaran dan pada masa yang sama membuka port pada setiap antara muka, yang merupakan perubahan keselamatan, bukan pembaikan neutral. Lebih baik ikat pada alamat tempatan tertentu yang disasarkan oleh ubah hala, dan biarkan port tertutup pada antara muka yang tidak dipercayai. Jika ikatan yang lebih luas tidak dapat dielakkan, tambah peraturan firewall hos yang hanya membenarkan julat sumber terowong dan trafik tempatan gateway itu sendiri.
Membuka port pada antara muka awam tidak pernah diperlukan untuk trafik VPN yang dialihkan, kerana sambungan tamat secara tempatan selepas penulisan semula. Jangan dedahkan proksi kepada internet untuk membuat ubah hala tempatan berfungsi.
Buktikan dengan sambungan baharu dari klien
Uji dari klien VPN sebenar dengan sambungan TCP baharu, bukan dari shell pada gateway. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com pada klien menjalankan laluan yang dialihkan dari hujung ke hujung.
Kemudian sahkan bahawa sambungan terus ke pendengar dari rangkaian yang tidak dipercayai masih ditolak, dan bahawa sambungan huluan proksi itu sendiri tidak ditangkap semula oleh peraturan yang sama. Penangkapan rekursif muncul sebagai proksi yang bersambung dengan dirinya sendiri dan tidak pernah menyelesaikan permintaan. Tambah destinasi proksi ke set pengecualian, atau tandakan paket keluarnya supaya rantai melangkaunya.
Akhir sekali, ingat apa yang tidak diliputi laluan ini. Ubah hala TCP redsocks biasa tidak menukar UDP, QUIC atau DNS menjadi trafik SOCKS, dan destinasi peribadi biasanya memerlukan pengecualian yang jelas. Ujian tempatan yang berjaya hanya membuktikan laluan loopback yang tidak pernah menjadi masalah.