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

Proksi menjawab, permintaan selesai, tetapi tujuan tetap mencatat alamat LAN. Tidak ada yang tampak salah di log proksi, dan baris yang Anda ubah memang baris yang disuruh dokumentasi untuk diubah. Pada host yang punya alamat LAN dan alamat terowongan, tiga direktif menentukan alamat mana muncul di mana, dan hanya satu di antaranya menyangkut sisi keluar. Membacanya dalam urutan salah membuat Anda masuk ke tabel perutean tanpa alasan.

Gejalanya: tujuan melihat alamat LAN

Klien terhubung ke proksi pada alamat LAN, dan proksi membuka koneksinya sendiri ke tujuan. Koneksi kedua itu memilih alamat sumber menurut aturan kernel, dan secara bawaan itulah yang dipilih pencarian rute. Karena itu tujuan mencatat alamat utama host meskipun setiap bita melewati proksi. Dari sisi penerusan tidak ada yang rusak, dan itulah sebabnya log proksi tidak punya apa pun untuk dikatakan.

Cermin dari kesalahan itu lebih mudah terlihat: patok sumber keluar ke alamat terowongan dan klien LAN sama sekali berhenti mencapai pendengar. Versi itu mengumumkan dirinya sendiri, sedangkan yang pertama bersembunyi di balik permintaan yang berhasil. Keduanya muncul dari memperlakukan satu direktif seolah menjawab kedua pertanyaan.

Tiga direktif, tiga alamat berbeda

Listen menamai alamat lokal yang menerima klien proksi. Bind memasok alamat sumber bagi koneksi yang dibuat proksi ke luar, dan BindSame menyuruhnya memakai ulang alamat lokal dari koneksi yang baru diterimanya. Itu tiga pertanyaan terpisah, dan satu baris hanya menjawab satu. Mencampuradukkannya adalah alasan biasa sebuah perubahan tampak tidak berefek.

Bacalah konfigurasi beranotasi yang disertakan bersama versi terpasang, karena nilai bawaan dan sintaksis yang diterima berubah antar rilis. Konfigurasi contoh proyek mendokumentasikan setiap direktif di samping yang lain. Bandingkan berkas itu dengan yang ada di disk, bukan dengan panduan yang ditulis untuk distribusi lain.

Atur pendengar dan sumber keluar secara terpisah

Ambil host yang alamat LAN-nya 192.168.50.10 dan alamat terowongannya 10.90.0.3. Jika klien LAN harus mencapai proksi sementara permintaan mereka keluar lewat terowongan, itu dua keputusan terpisah dan keduanya harus ditulis. Fragmen di bawah menyatakan tepat itu dan tidak lebih.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Ini bukan konfigurasi lengkap, jadi pertahankan porta yang disetujui, autentikasi, kendali akses klien, dan pembatasan tujuan. Kedua alamat harus milik host ini di dalam ruang nama jaringan Tinyproxy, karena nilai Bind yang tidak dapat dimiliki proses gagal saat menyambung, bukan saat mulai. BindSame yes menjelaskan kebijakan lain, yaitu alamat lokal koneksi yang diterima menjadi sumber keluar. Pada rilis terkini cabang itu lebih diutamakan daripada daftar Bind, dan begitulah sumber yang dikonfigurasi menghilang tanpa kesalahan.

Periksa rute yang disiratkan sumber

Memilih alamat sumber tidak membuat jalur, jadi tanyakan kepada kernel apa yang akan dilakukannya dengan sumber dan tujuan itu. Pencarian yang menyebut antarmuka terowongan adalah bukti minimum, dan yang menyebut antarmuka LAN berarti sumber itu tidak dapat bekerja seperti tertulis. Pencarian bersifat kontekstual: ia menilai aturan kebijakan dan tabel yang berlaku bagi ruang nama itu. Itu bukan koneksi, dan tidak mengatakan apa pun tentang apa yang akan ditampilkan NAT di hilir kepada layanan.

ip -4 route get 203.0.113.25 from 10.90.0.3

Gunakan alamat dokumentasi pada contoh dan ganti dengan layanan yang Anda berwenang uji. Jalankan pencarian di dalam ruang nama proksi bila proksi berjalan dalam kontainer, karena aturan host bukan aturan yang dilihat proses. Bila rute terowongan yang dimaksud tidak ada, biarkan pemilik jaringan memperbaikinya alih-alih menambahkan aturan khusus tujuan pada host proksi. Jangan bersihkan rute host atau menonaktifkan rute yang didorong server agar pencarian berhasil, meskipun panduan lama melakukannya, karena perubahan itu menggeser seluruh perilaku VPN host yang disetujui hanya untuk memperbaiki satu jalur proksi.

Konfirmasikan sumber di tujuan

Bacalah sumber di tempat permintaan tiba, bukan di tempat ia berangkat. Log aplikasi tujuan, atau perangkat tepi di depannya, mencatat alamat yang benar-benar dilihatnya, sedangkan proksi hanya dapat memberi tahu niatnya. Buat satu permintaan baru melalui pendengar yang dimaksud setelah perubahan, karena koneksi yang di-cache tidak membuktikan apa pun tentang pengikatan baru. Lalu bandingkan alamat tercatat itu dengan alamat yang Anda konfigurasi.

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

curl hanyalah pembangkit lalu lintas; alamat yang layak diverifikasi adalah yang dicatat sisi jauh, bukan rekan yang kebetulan dihubungi curl. Jika keduanya tidak cocok, tentukan apakah perbedaannya berasal dari pemilihan sumber atau dari penerjemahan lebih jauh, karena keduanya diperbaiki di tempat berbeda. Rencanakan perubahan alamat dan mulai ulang proksi bersama-sama, karena mengikat alamat yang tidak lagi dipegang terowongan gagal diam-diam setelah menyambung ulang. Tentukan juga perilaku DNS dan IPv6 secara terpisah, karena fragmen IPv4 di atas tidak membuktikan apa pun tentang keduanya.