Listen, Bind dan BindSame dalam Tinyproxy: alamat mana yang menang

Proksi menjawab, permintaan selesai, namun destinasi masih merekodkan alamat LAN. Tiada apa dalam log proksi kelihatan salah, dan baris yang anda ubah itulah baris yang dokumentasi suruh ubah. Pada hos yang mempunyai alamat LAN dan alamat terowong, tiga arahan menentukan alamat mana muncul di mana, dan hanya satu daripadanya berkaitan sisi keluar. Membacanya dalam urutan yang salah membawa anda ke jadual penghalaan tanpa sebab.

Gejalanya: destinasi melihat alamat LAN

Klien menyambung ke proksi pada alamat LAN, dan proksi membuka sambungannya sendiri ke destinasi. Sambungan kedua itu memilih alamat sumber mengikut peraturan kernel, dan secara lalai ia adalah yang dipilih oleh carian laluan. Oleh itu destinasi merekodkan alamat utama hos walaupun setiap bait melalui proksi. Dari segi penghantaran tiada apa yang rosak, dan sebab itulah log proksi tiada apa untuk dikatakan.

Cermin bagi kerosakan itu lebih mudah dilihat: pakukan sumber keluar pada alamat terowong dan klien LAN tidak lagi sampai kepada pendengar langsung. Versi itu mengumumkan dirinya sendiri, manakala yang pertama bersembunyi di belakang permintaan yang berjaya. Kedua-duanya berpunca daripada memperlakukan satu arahan seolah-olah ia menjawab kedua-dua soalan.

Tiga arahan, tiga alamat berbeza

Listen menamakan alamat setempat yang menerima klien proksi. Bind membekalkan alamat sumber bagi sambungan yang dibuat proksi ke luar, dan BindSame menyuruhnya menggunakan semula alamat setempat sambungan yang baru diterimanya. Itu tiga soalan berasingan, dan satu baris hanya menjawab satu. Mengelirukannya ialah sebab biasa sesuatu perubahan kelihatan tidak berkesan.

Baca konfigurasi beranotasi yang disertakan dengan versi yang dipasang, kerana nilai lalai dan sintaks yang diterima berubah antara keluaran. Konfigurasi contoh projek mendokumentasikan setiap arahan di sebelah yang lain. Bandingkan fail itu dengan fail pada cakera, bukan dengan panduan yang ditulis untuk distribusi lain.

Tetapkan pendengar dan sumber keluar secara berasingan

Ambil hos yang alamat LAN-nya 192.168.50.10 dan alamat terowongnya 10.90.0.3. Jika klien LAN perlu sampai ke proksi sementara permintaan mereka keluar melalui terowong, itu dua keputusan berasingan dan kedua-duanya mesti ditulis. Serpihan di bawah menyatakan tepat itu dan tiada yang lain.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Ini bukan konfigurasi lengkap, jadi kekalkan port yang diluluskan, pengesahan, kawalan akses klien dan sekatan destinasi. Kedua-dua alamat mesti milik hos ini dalam ruang nama rangkaian Tinyproxy, kerana nilai Bind yang tidak dapat dimiliki proses gagal semasa menyambung, bukan semasa bermula. BindSame yes menerangkan dasar lain, iaitu alamat setempat sambungan yang diterima menjadi sumber keluar. Dalam keluaran semasa cabang itu diutamakan berbanding senarai Bind, dan begitulah sumber yang dikonfigurasikan hilang tanpa ralat.

Periksa laluan yang tersirat oleh sumber

Memilih alamat sumber tidak mencipta laluan, jadi tanya kernel apa yang akan dilakukannya dengan sumber dan destinasi itu. Carian yang menamakan antara muka terowong ialah bukti minimum, dan yang menamakan antara muka LAN bermakna sumber itu tidak boleh berfungsi seperti yang ditulis. Carian itu berkonteks: ia menilai peraturan dasar dan jadual yang berkuat kuasa bagi ruang nama itu. Ia bukan sambungan, dan ia tidak mengatakan apa-apa tentang apa yang akan ditunjukkan oleh NAT di hilir kepada perkhidmatan.

ip -4 route get 203.0.113.25 from 10.90.0.3

Gunakan alamat dokumentasi dalam contoh dan gantikan dengan perkhidmatan yang anda dibenarkan uji. Jalankan carian di dalam ruang nama proksi apabila proksi berjalan dalam kontena, kerana peraturan hos bukan peraturan yang dilihat proses. Jika laluan terowong yang dimaksudkan tiada, biarkan pemilik rangkaian membaikinya dan bukan menambah peraturan khusus destinasi pada hos proksi. Jangan bersihkan laluan hos atau lumpuhkan laluan yang ditolak pelayan supaya carian berjaya, walaupun panduan lama berbuat demikian, kerana perubahan itu mengalihkan seluruh tingkah laku VPN hos yang diluluskan untuk membaiki satu laluan proksi.

Sahkan sumber di destinasi

Baca sumber di tempat permintaan tiba, bukan di tempat ia bertolak. Log aplikasi destinasi, atau peranti tepi di hadapannya, merekodkan alamat yang benar-benar dilihatnya, manakala proksi hanya boleh memberitahu niatnya. Buat satu permintaan baharu melalui pendengar yang dimaksudkan selepas perubahan, kerana sambungan dalam cache tidak membuktikan apa-apa tentang ikatan baharu. Kemudian bandingkan alamat yang direkodkan itu dengan alamat yang anda konfigurasikan.

ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sS

curl hanyalah penjana trafik; alamat yang wajar disahkan ialah yang direkodkan oleh sisi jauh, bukan rakan yang curl kebetulan sambung. Jika kedua-duanya tidak sepadan, tentukan sama ada perbezaan itu datang daripada pemilihan sumber atau daripada terjemahan lebih jauh, kerana kedua-duanya dibaiki di tempat berbeza. Rancang perubahan alamat dan permulaan semula proksi bersama-sama, kerana mengikat alamat yang tidak lagi dipegang terowong gagal secara senyap selepas menyambung semula. Takrifkan juga tingkah laku DNS dan IPv6 secara berasingan, kerana serpihan IPv4 di atas tidak membuktikan apa-apa tentang kedua-duanya.