Penghantaran tempatan SSH ke proksi HTTP sedia ada: dua alamat loopback

Proksi anda yang diluluskan berjalan pada hos lompat yang hanya mendengar pada loopback, jadi tiada apa-apa di luar mesin itu dapat mencapainya. Anda tidak memerlukan VPN atau proksi baharu; anda memerlukan satu port mesin itu dibawa ke satu port anda. Penghantaran tempatan melakukan tepat itu, dan ia memerlukan satu arahan serta satu tetapan aplikasi. Kekeliruan biasanya datang daripada mengelirukan alamat loopback mana milik mesin mana.

Tentukan sama ada proksi tetap sudah wujud

Teknik ini menghantar perkhidmatan yang sudah berjalan. Jika hos jauh hanya mempunyai daemon SSH dan tiada proksi, berapa banyak pun penghantaran tidak akan menciptanya, dan sambungan akan ditolak dari sebelah jauh. Sahkan proksi terikat, portnya, dan sama ada ia mendengar pada 127.0.0.1 atau pada alamat antara muka tertentu, kerana alamat itulah yang mesti disasarkan oleh penghantaran.

Mengesahkannya dahulu menyelamatkan anda daripada menyahpepijat terowong yang tidak pernah disambungkan kepada apa-apa.

Bina penghantaran dan baca arahan itu

Bentuk yang anda mahukan mengikat port loopback pada komputer riba anda dan menyambungkannya, dari sebelah pelayan, ke alamat proksi seperti yang dilihat oleh pelayan.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N menekan arahan jauh dan -T menekan peruntukan termios, kerana anda mahukan terowong dan bukan shell. Alamat loopback pertama ialah tempat komputer riba mendengar; yang kedua diselesaikan oleh pelayan SSH, jadi 127.0.0.1 di sana bermaksud proksi pada mesin itu. ExitOnForwardFailure membuat arahan gagal dengan kuat jika port tempatan sudah digunakan, bukannya memulakan sesi yang tidak menghantar apa-apa. Tulis alamat sasaran seperti pelayan menyelesaikannya, kerana nama yang hanya boleh diselesaikan oleh komputer riba anda akan gagal di sebelah sana.

Dasar pelayan itu sendiri terpakai sebelum apa-apa daripada ini berfungsi. AllowTcpForwarding mesti membenarkannya, dan PermitOpen boleh menghadkan destinasi dan port yang boleh dicapai oleh sesi, jadi penghantaran yang diterima klien masih boleh ditolak oleh pelayan. Penolakan muncul sebagai ralat penghantaran atau saluran pada klien, dan membaca mesej itu lebih pantas daripada menyunting arahan.

Halakan satu aplikasi ke penghantaran

Konfigurasikan aplikasi untuk menggunakan proksi HTTP pada http://127.0.0.1:13128, dengan kelayakan jika proksi jauh memerlukannya. Kekalkan pengesahan sijil aplikasi itu sendiri untuk destinasi HTTPS, kerana terowong proksi tidak menggantikannya. Ini penghantaran tetap bagi satu perkhidmatan, jadi aplikasi mesti diberitahu tentang proksi dan bukannya dibiarkan menemuinya sendiri.

Semakan pantas sebelum mengkonfigurasi apa-apa yang kekal: curl -x http://127.0.0.1:13128 -I https://example.com, yang melatih kaedah HTTP CONNECT yang mesti disokong oleh proksi.

Kekalkan kuasa di tempatnya

Proksi jauh masih menentukan destinasi dan kaedah yang dibenarkannya, dan log masuk SSH tidak sepatutnya memberikan setiap akaun relai web umum secara senyap. Mengikat pada 127.0.0.1 pada komputer riba mengelakkan port diterbitkan ke rangkaian tempatan anda, dan ia tidak menjadikan port itu peribadi daripada proses lain pada mesin yang sama. Menggantikan ikatan itu dengan alamat wildcard untuk berkongsi proksi ialah cara relai terbuka tidak terurus tercipta.

Pengangkutan SSH melindungi lompatan ke pelayan. Selepas titik itu proksi membuka sambungannya sendiri, jadi permintaan HTTP biasa ke destinasi kekal biasa di luar pelayan walaupun segmen pertama disulitkan.

Sahkan kedua-dua hujung, kemudian bersihkan

Persediaan terowong tempatan dan kejayaan perkhidmatan jauh ialah hasil yang berbeza, dan status keluar arahan hanya memberitahu anda tentang yang pertama. Periksa sama ada pendengar wujud dengan ss -ltn, kemudian buat permintaan aplikasi yang dibenarkan dan permintaan yang sepatutnya ditolak oleh proksi. Jika kedua-duanya berkelakuan seperti dijangka, laluan itu nyata; jika terowong hidup dan setiap permintaan gagal, proksi menolak atau tidak dapat mencapai destinasi.

Apabila selesai, hentikan proses SSH yang memilikinya, buang tetapan proksi daripada aplikasi, dan sahkan port tempatan telah hilang dan bukannya meninggalkan pendengar yang hidup lebih lama daripada tugas.