Lalu lintas aplikasi apa yang sebenarnya dibawa penerusan SSH?

Terminal terhubung, prompt muncul, dan semua orang setuju bahwa akses SSH berfungsi. Lalu klien basis data di laptop tetap tidak bisa menjangkau host privat, dan sesi disalahkan. Yang dibangun adalah shell, dan itu salah satu dari empat antarmuka yang cukup berbeda yang dapat ditawarkan SSH. Sebutkan antarmukanya lebih dulu, lalu uji bahwa aplikasi benar-benar memakainya. Urutannya penting, karena setiap antarmuka gagal dengan caranya sendiri.

Sebutkan antarmukanya sebelum membandingkan apa pun

manual klien OpenSSH membedakan empat mekanisme yang mudah dicampuradukkan. Shell atau perintah jarak jauh dijalankan di host SSH. Penerusan lokal membuka soket pendengar di klien dan membuat koneksi lanjutan dari sisi jarak jauh. Penerusan jarak jauh melakukan sebaliknya, mendengarkan di sisi server. Penerusan dinamis mengekspos titik akhir SOCKS bagi program yang tahu cara memakainya.

• Shell: program berjalan di mesin jarak jauh, tidak ada yang mendengarkan secara lokal.
• Penerusan lokal: laptop Anda memiliki port, host jarak jauh membuat koneksi keluar.
• Penerusan jarak jauh: sisi jarak jauh memiliki port, lalu lintas kembali ke arah Anda.
• Dinamis: proxy SOCKS di klien, hanya dipakai aplikasi yang memahami proxy.

Tidak satu pun dari ini memasang rute. Program yang mengabaikan pengaturan proxy, atau berbicara UDP, atau menyelesaikan nama sendiri, tidak terpengaruh oleh sesi SSH yang aktif. Itu bukan bug di SSH; itu adalah cakupan antarmuka yang Anda pilih.

Penerusan lokal, jarak jauh, dan dinamis berbeda dalam siapa yang mendengarkan

Perbedaan yang menentukan sebagian besar kasus adalah siapa yang memiliki soket pendengar. Pada penerusan lokal, klien mendengarkan dan ujung jauh memanggil tujuan, itulah sebabnya alamat tujuan diselesaikan dari sudut pandang server. Pada penerusan jarak jauh, server mendengarkan dan koneksi dibawa kembali ke sisi Anda, dan begitulah Anda mengekspos layanan lokal tanpa menerbitkannya secara langsung.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

Perintah pertama mengikat port 5432 di laptop dan meneruskannya ke basis data sebagaimana terlihat dari bastion. Yang kedua membuat proxy SOCKS pada port 1080. Perintah ketiga memastikan proses mana yang benar-benar mendengarkan, dan itulah satu-satunya bukti bahwa penerusan itu ada, bukan gagal diam-diam karena benturan port.

Penerusan dinamis layak mendapat peringatannya sendiri: ia hanya mencakup aplikasi yang menghormati SOCKS. Peramban dapat diarahkan ke sana, alat baris perintah dapat diminta memakainya, tetapi pengandar basis data dengan tumpukan koneksinya sendiri biasanya tidak bisa. Menganggap bahwa setiap program di mesin kini memakai terowongan adalah kesalahan paling umum di seluruh bidang ini.

Mode perangkat terowongan adalah satu-satunya pengecualian jaringan yang nyata

OpenSSH juga mendukung penerusan perangkat terowongan -w, yang meneruskan antarmuka titik ke titik alih-alih pendengar TCP. Itu terowongan jaringan sungguhan, dan dikonfigurasi dengan sengaja, bukan efek samping dari membuka shell.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Ini membutuhkan nomor antarmuka yang sesuai tersedia di kedua ujung, konfigurasi yang benar di server, dan hak istimewa yang cukup di klien untuk membuat perangkat. Ini juga membutuhkan rencana pengalamatan dan perutean, karena antarmuka telanjang tidak membawa kebijakan tentang tujuan mana yang harus memakainya.

Bahkan kemudian, terowongan berakhir di host jauh. Perlindungan apa pun yang diberikan transport SSH berakhir di sana, dan koneksi lanjutan adalah lompatan terpisah. Gateway VPN memiliki bentuk batas yang sama, itulah sebabnya perbandingan harus tentang cakupan dan pengakhiran, bukan tentang alat mana yang lebih kuat. Menyebutkan batas itu dengan lantang juga menyelesaikan perdebatan apakah terowongan «mengenkripsi semuanya», karena jelas tidak.

Uji bahwa aplikasi Anda memakai antarmuka yang Anda bangun

Verifikasi bersifat per aplikasi, bukan per sesi. Penerusan yang berfungsi membuktikan port terikat dan sisi jauh dapat memanggil; itu tidak membuktikan bahwa program yang Anda pedulikan terhubung melaluinya.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

Perintah pertama mengirim permintaan melalui titik akhir SOCKS dengan nama host diselesaikan dari jarak jauh, dan yang kedua menguji port basis data yang diteruskan dengan TLS masih diwajibkan. Jalankan pengujian yang sama dengan penerusan dihentikan untuk memastikan gagal, karena pengujian yang lolos kedua arah tidak pernah memakai terowongan.

Lalu bandingkan dengan VPN yang dirutekan hanya pada dimensi yang penting: tujuan mana yang tercakup, protokol mana yang berfungsi, di mana perlindungan berakhir, dan siapa yang harus menyetujui akses. Penerusan satu layanan bisa menjadi jawaban yang lebih sempit dan lebih baik, sedangkan VPN adalah bentuk yang tepat ketika banyak aplikasi membutuhkan jalur jaringan yang sama. Tidak satu pun memberikan semua yang dapat dijangkau dari titik akhir jauhnya.