SSH jarak jauh melalui VPN: apa yang tidak dilakukan terowongan

VPN memberi server SSH jalur privat dan menghapus kebutuhan pendengar publik pada port 22. VPN tidak mengautentikasi host, tidak mengotorisasi pengguna, dan tidak memutuskan akun mana yang boleh masuk. Itu tetap tugas SSH. Apakah VPN adalah cara yang tepat untuk mencapai server bergantung pada tiga kondisi, dan terowongan hanyalah salah satu jawaban yang mungkin.

Apa yang diubah terowongan dan apa yang masih diputuskan SSH

Terowongan mengubah keterjangkauan: alamat mana yang dapat dijangkau, dan dari mana. Terowongan tidak mengubah apa yang terjadi setelah koneksi TCP tiba, tempat server menyajikan kunci host dan meminta identitas pengguna.

Pisahkan kedua lapisan itu di kepala Anda dan dalam dokumentasi Anda. Login VPN membuktikan siapa yang boleh menggunakan jaringan. Itu tidak mengatakan apa pun tentang akun mana yang ada di target, dan itu bukan izin untuk masuk ke setiap mesin yang dapat dijangkau.

Mode kegagalannya juga terpisah, dan itulah yang membuat pemisahan itu berguna selama insiden.

Tiga kondisi yang menentukan model akses

Pertama, apakah server perlu dapat dijangkau oleh orang di luar jaringan Anda? Jika tidak, jalur privat plus bastion atau mesh adalah desain yang lebih kecil. Kedua, dapatkah populasi klien benar-benar menjalankan klien VPN, termasuk mereka yang berada di perangkat terkelola dengan pembatasan?

Ketiga, apakah Anda memerlukan kontrol per layanan atau kontrol per pengguna? VPN memberikan jangkauan jaringan; SSH memberikan akses akun. Jika persyaratannya adalah bahwa kontraktor mencapai satu host dan bukan yang lain, itu persyaratan otorisasi dan terowongan saja tidak dapat menyatakannya.

Jawab ketiganya dan model memilih dirinya sendiri. Lewati dan Anda akhirnya mengekspos SSH secara publik untuk menghindari peluncuran klien.

Pastikan jalur privat sebelum menyalahkan SSH

Hubungkan VPN yang disetujui dan gunakan nama atau alamat privat target yang didokumentasikan. Lalu periksa rute yang dipilih, izin gateway, dan jalur kembali ke klien. Nama yang diselesaikan dengan benar bukan bukti bahwa alamat tersebut mengambil terowongan yang dimaksud, karena prefiks lokal dan jarak jauh yang tumpang tindih dapat mengirim permintaan ke tempat lain sepenuhnya. Perbedaan itu layak ditulis di runbook.

Jika koneksi tidak pernah tiba, pastikan server mendengarkan pada antarmuka yang Anda harapkan dan bahwa firewall host-nya mengizinkan sumber yang benar-benar dilihatnya. NAT gateway dapat menulis ulang sumber itu, jadi daftar izin yang ditulis untuk alamat terowongan klien mungkin tidak pernah cocok.

Ketidakcocokan itu adalah kegagalan SSH yang paling umum disebabkan sendiri melalui VPN.

Baca tahap kegagalan, bukan kesalahan gabungan

Tiga tahap menghasilkan tiga pesan berbeda, dan hanya satu di antaranya tentang kredensial.

Gunakan kesalahan yang tepat dan log server itu sendiri alih-alih mereset kredensial VPN dan SSH bersamaan. Mereset keduanya adalah bagaimana diagnosis lima menit menjadi insiden identitas dua hari.

Keluaran verbose menunjukkan tahap mana yang Anda capai:

ssh -vv [email protected]

Jaga kunci host dan otorisasi tetap utuh

Validasi kunci host melalui proses tepercaya yang dimaksud, terutama setelah penggantian server. Peringatan kunci berubah yang tidak terduga adalah satu-satunya pesan yang tidak boleh Anda abaikan hanya karena VPN terhubung, karena terowongan privat tidak membuat tujuan menjadi mesin yang Anda kira. Periksa sidik jari terhadap sumber yang Anda percayai secara independen dari koneksi.

Di sisi server, pastikan akun diotorisasi dan metode autentikasi yang Anda konfigurasi adalah yang ditawarkan. Kunci yang ada tetapi diabaikan biasanya masalah izin atau konfigurasi, bukan jaringan.

Batasi akses layanan ke identitas yang diperlukan dan pertahankan jalur pemulihan yang diotorisasi untuk perubahan jaringan.