SSH pada Laluan Peribadi Kedua Semasa VPN Kekal Aktif

Satu mesin mencapai mesin lain melalui VPN, dan seseorang kini mahukan shell yang sama melalui rangkaian peribadi penyedia. Laluan wujud, ping berjaya, tetapi SSH masih menolak. Punca biasa ialah daemon tidak pernah mendengar pada alamat baharu, jadi tiada apa untuk disambungkan. Ini masalah pengikatan alamat sebelum menjadi masalah firewall.

Mengapa laluan baharu tidak mencipta pendengar baharu

Soket pendengar dicipta oleh proses yang menamakan alamat yang akan diterimanya. Laluan hanya memberitahu paket ke mana hendak pergi; ia tidak mencipta pendengar di destinasi. Apabila sshd dikonfigurasikan dengan satu ListenAddress, sambungan ke mana-mana alamat tempatan lain ditolak walaupun antara muka aktif. Perkara sama berlaku untuk unit soket yang memiliki port, sebab itu pemeriksaan pertama sentiasa apa yang sebenarnya mendengar.

Bandingkan kedua-dua laluan mengikut alamat destinasi, bukan nama antara muka. Klien bersambung ke alamat, dan alamat itu mesti terikat sebelum sebarang peraturan firewall menjadi penting.

Senaraikan alamat dan pendengar

Sebelum mengedit apa-apa, catat alamat pada hos dan soket yang wujud sekarang.

ip -br addr
ss -ltnp | grep ':22'

Senarai alamat menunjukkan alamat peribadi mana yang sebenar dan pada antara muka mana, manakala senarai soket menunjukkan sama ada sesuatu terikat padanya. Pendengar pada 0.0.0.0:22 sudah menerima setiap alamat, jadi pengikatan baharu tidak menambah apa-apa. Pendengar pada satu alamat tertentu menjelaskan penolakan itu serta-merta. Jika port dimiliki oleh unit soket dan bukan daemon, konfigurasi daemon bukan keseluruhan cerita.

Tambah pengikatan dan kekalkan yang lama

OpenSSH menerima beberapa entri ListenAddress, jadi laluan VPN boleh kekal semasa laluan peribadi ditambah. Uji fail sebelum memuat semulanya.

sshd -t
systemctl reload sshd

Ujian konfigurasi yang gagal membiarkan daemon yang berjalan tidak tersentuh, dan itulah yang anda mahu semasa bersambung melalui laluan yang anda edit. Kekalkan entri sedia ada, tambah alamat tempatan baharu, dan pastikan perkhidmatan dimuat semula tanpa memutuskan sesi semasa. Pada pemasangan yang diaktifkan soket, tambah alamat itu pada unit soket dan muat semula unit tersebut. Kemudian baca senarai pendengar sekali lagi, kerana pengikatan yang tidak pernah muncul bermakna komponen yang salah telah diedit.

Sahkan sesi baharu sebelum menutup yang lama

Sambung ke alamat baharu semasa sesi asal masih terbuka, dengan menggunakan output terperinci untuk melihat alamat dan kunci mana yang digunakan. Biarkan sesi asal terbuka sehingga pemeriksaan berjaya dua kali.

ssh -v [email protected]

Baca baris nyahpepijat untuk alamat destinasi dan kunci hos yang dibentangkan. Sahkan cap jari kunci hos terhadap nilai yang anda sudah percayai, bukan menerima kunci tidak dikenali kerana rangkaian digambarkan sebagai peribadi. Destinasi baharu memerlukan entri known_hosts sendiri, dan itu dijangka. Sesi pengurusan lama hanya patut ditutup selepas laluan peribadi berfungsi.

SSH melindungi pengangkutan, tetapi ia tidak menjadikan dua rangkaian setara secara berasingan. Tentukan sama ada kepercayaan transit peribadi sepadan dengan data sebelum bergantung padanya.