Pemajuan Dinamik SSH sebagai Proksi SOCKS di Atas VPN Anda

Aplikasi yang hanya bertutur SOCKS tiada apa-apa untuk diajak bicara pada VPN biasa, kerana terowong membawa paket dan aplikasi mahukan titik akhir proksi. OpenSSH boleh menyediakan titik akhir itu apabila pemilik akses mengizinkannya, kerana pemajuan dinamik menjadikan satu sesi SSH sebagai proksi tempatan. Selepas itu ada dua lompatan yang perlu dipegang berasingan: terowong yang sampai ke hos SSH, dan sambungan yang hos itu buka seterusnya. Mengasingkan keduanya menjelaskan mengapa susunan ini berfungsi dan apa yang tidak akan pernah dilakukannya.

Apa yang pendengar SSH menjadi dan apa yang tidak

Pemajuan dinamik memaksa klien SSH mendengar secara tempatan dan bertutur SOCKS4 atau SOCKS5 dengan apa sahaja yang bersambung. Setiap permintaan menamakan destinasi dan pelayan SSH membuka sambungan seterusnya, sebab itu carian destinasi boleh berlaku di sebelah sana. Ini pemajuan TCP pada peringkat aplikasi, bukan VPN untuk seluruh peranti. Ia tidak membawa persekutuan UDP, tidak ICMP, dan tidak apa-apa untuk aplikasi yang mengabaikan tetapan proksi sepenuhnya. Lompatan daripada pelayan SSH ke aplikasi juga bukan di dalam terowong anda, yang penting apabila destinasi hanya menerima trafik daripada rangkaian yang diketahui.

Prasyaratnya nyata: laluan ke hos SSH, akaun yang dibenarkan, kunci hos pelayan yang disahkan dan kebenaran untuk memajukan. Tiada satu pun dicipta oleh proksi, dan yang terakhir biasanya yang pertama hilang. Sahkan keempat-empatnya sebelum menyahpepijat apa-apa lagi, kerana dari sisi klien kegagalan kelihatan sama, mana pun yang hilang.

Lancarkannya pada loopback dengan port yang jelas

Pilih port tempatan yang tidak digunakan dan ikatkannya secara jelas pada loopback daripada membiarkan alamat kosong. Ketiga-tiga pilihan di bawah wujud masing-masing atas satu sebab.

ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  [email protected]

-N melangkau arahan jauh dan -T melangkau pseudoterminal, jadi sesi hanya wujud untuk memajukan. ExitOnForwardFailure membuat klien keluar apabila pendengar tidak dapat dicipta, bukan berjalan tanpa pemajuan yang anda minta. ControlPath=none menyimpan sesi di luar sambungan bermultipleks sedia ada yang mungkin menambah pemajuannya sendiri. Loopback menyimpan pendengar di luar LAN, tetapi pada mesin kongsi itu bukan sempadan kebenaran, kerana proses tempatan lain juga boleh mencapainya. Rujukan klien OpenSSH mendokumenkan semua bendera ini, dan amaran loopback datang daripada apa itu soket yang mendengar.

Hantar nama melalui proksi, bukan mengelilinginya

Klien SOCKS5 boleh menyelesaikan destinasi sendiri atau meminta proksi melakukannya, dan pilihan itu menentukan penyelesai mana yang menjawab. Dengan socks5h curl menghantar nama hos melalui proksi, jadi carian berlaku pada pelayan SSH. Dengan socks5 biasa, komputer riba menyelesaikan dahulu dan hanya sambungan bergerak, yang senyap merosakkan tujuannya apabila nama itu dalaman. Permintaan di bawah juga mengosongkan senarai tanpa proksi, jadi nilai NO_PROXY yang diwarisi tidak boleh membawanya mengelilingi proksi.

curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/health

Pengesahan sijil dan log masuk aplikasi itu sendiri masih terpakai, kerana proksi tidak menggantikan mana-mana daripadanya. Tinggal dua carian: komputer riba mesti sampai ke hos SSH melalui laluan VPN dan DNS yang dibenarkan, dan pelayan SSH mesti menyelesaikan nama aplikasi itu sendiri. Yang kedua boleh diuji bersendirian sebelum sebarang trafik melalui proksi.

ssh [email protected] getent hosts app.corp.example

Buktikan satu destinasi yang dibenarkan, kemudian tutup sesi itu

Uji destinasi yang dibenarkan oleh dasar dan satu yang sepatutnya ditolaknya, kerana pemajuan yang berfungsi hanya membuktikan pendengar berfungsi dan tidak lebih. Aplikasi melihat alamat sumber yang dipilih pelayan SSH, dan itu bukan alamat terowong komputer riba anda. Di mana hujung jauh merekodkan sambungan mengikut sumber, perbezaan itulah perkara pertama yang perlu diperiksa apabila permintaan ditolak.

Hentikan sesi melalui proses yang memilikinya dan bukan dengan membunuh shell yang tidak berkaitan. Kemudian sahkan pendengar sudah tiada, kerana port yang masih menjawab ialah sesi yang tidak benar-benar anda tutup. Buang hanya tetapan proksi yang diperkenalkan latihan ini, dan biarkan baki konfigurasi aplikasi tidak diusik. Terminal tanpa pengawasan yang memegang peraturan pemajuan bukan perkhidmatan, dan proksi kekal memerlukan kitaran hayat yang diluluskan, bukan tetingkap yang dilupakan.

ss -ltn | grep 1080

Kegagalan yang tidak dapat dibaiki susunan ini

Sesetengah simptom menunjuk terus kepada had di atas, dan mengenalinya awal menjimatkan satu petang penyahpepijatan proksi. Jadual memetakan apa yang anda lihat kepada apa yang biasanya bermakna. Apa-apa dalam lajur terakhir ialah persoalan reka bentuk, bukan kesilapan konfigurasi.

Tiga baris pertama ialah yang orang salah diagnosis, kerana setiap satu menghasilkan percubaan sambungan dan bukan ralat tentang proksi itu sendiri. Nama yang diselesaikan pada komputer riba tidak berkata apa-apa tentang penyelesai pelayan, dan kegagalan dibaca sebagai masalah sijil atau had masa. Aplikasi hanya-UDP berdiri di luar reka bentuk, bukan rosak di dalamnya, dan tiada pilihan ssh tambahan mengubahnya. Baris pelayar ialah peringatan biasa bahawa tetapan proksi adalah bagi setiap aplikasi. Baris terakhir ialah sebab pemeriksaan penutupan wujud: port yang masih mendengar bermakna sesuatu yang lain memilikinya sekarang.