Kekalkan SSH setempat apabila hos menjalankan VPN keluar

Sebuah pelayan Linux kecil menjalankan VPN keluar untuk aplikasi yang dihoskannya, dan pentadbir masih mahu mencapainya melalui SSH dari meja sebelah. Itu keperluan yang wajar, dan biasanya ia tidak memerlukan pemajuan port, alamat penyedia atau lubang dalam tunnel. Yang diperlukannya ialah laluan pengurusan yang direka dengan sengaja dan bukannya diwarisi daripada apa yang klien VPN lakukan pada jadual penghalaan.

Langkah di bawah menganggap pentadbir berada pada LAN yang sama.Pentadbiran jauh ialah masalah lain dengan jawapan lain.

Ikat SSH pada alamat yang digunakan pentadbir

Mulakan dengan pendengar.ss -ltnp | grep :22 menunjukkan kepada apa sshd terikat, dan pendengar pada 0.0.0.0 menerima sambungan daripada setiap antara muka, termasuk tunnel. Mengikat pada alamat LAN lebih sempit dan menjadikan niat kelihatan:ListenAddress 192.168.10.20 dalam sshd_config, diikuti ujian konfigurasi dan muat semula. Kesilapan taip dalam alamat itu lebih kelihatan daripada kad liar, kerana sshd enggan bermula apabila alamat itu tidak wujud.

Kekalkan pemeriksaan kunci hos dan pengesahan setiap pengguna tepat seperti adanya. „Ini hanya rangkaian setempat“ bukan kaedah pengesahan, dan saluran pengurusan yang melangkau pengesahan kunci kerana laluan pendek ialah saluran pengurusan yang menunggu penyalahgunaan. Tempahan DHCP atau alamat statik menjadikan sasaran boleh dijangka tanpa menjadikannya identiti awam pelayan.

Kekalkan laluan LAN di luar tunnel

Hos dengan alamat pada 192.168.10.0/24 mempunyai laluan bersambung untuk awalan itu, dan laluan yang lebih khusus mengalahkan lalai VPN dalam jadual yang sama. Itulah sebabnya SSH setempat sering terus berfungsi sendiri apabila tunnel naik. Sahkan dan jangan andaikan:ip route get 192.168.10.50 menamakan antara muka dan alamat sumber yang akan digunakan oleh kernel, dan jawapannya sepatutnya peranti LAN, bukan tunnel. Ulang pemeriksaan dari mesin pentadbir juga, kerana jadualnya sendiri menentukan sama ada paket itu sampai. Dua hos pada wayar yang sama boleh berselisih tentang arah mana yang boleh dicapai.

Andaian itu pecah di dua tempat. Peraturan penghalaan berasaskan dasar boleh menghantar trafik ke jadual yang lalainya menunjuk ke tunnel sebelum jadual utama dirujuk. Klien VPN dengan ciri kunci atau kill switch juga boleh menyekat trafik yang tidak masuk ke tunnel, tanpa mengira apa yang dikatakan jadual penghalaan.

VLAN pengurusan yang dihalakan ialah kes yang lain. Jika pentadbir duduk pada 192.168.50.0/24 di belakang penghala setempat, pelayan memerlukan laluan eksplisit untuk awalan itu melalui 192.168.10.1, dan laluan itu mesti bertahan semasa sambungan semula. Kekalkan pengecualian khusus untuk awalan pengurusan; pengecualian luas untuk julat peribadi mengalahkan tujuan tunnel.

Jadikan pengecualian firewall sama sempit dengan peraturan

Jika hos menjalankan firewall, benarkan SSH hanya daripada sumber pengurusan dan hanya pada antara muka LAN. Peraturan yang membenarkan port 22 dari mana-mana lebih luas daripada keperluan dan lebih sukar dipertahankan dalam semakan. Pada hos nftables peraturan itu terletak dalam rantai input dengan antara muka dan sumber dipadankan; pada hos iptables yang setara ialah sepasang padanan pada -i dan -s. Komen peraturan itu dengan kumpulan pentadbir yang dilayaninya, supaya audit seterusnya tidak perlu meneka mengapa port 22 terbuka.

Periksa juga penapis klien VPN itu sendiri. Sesetengah klien memasang peraturan yang menggugurkan trafik setempat secara reka bentuk, dan peraturan firewall yang betul di atas guguran pada peringkat klien tidak mengubah apa-apa. Baca konfigurasi klien sebelum menyunting firewall hos, kerana dua penapis berturutan menghasilkan kegagalan yang tidak menyerupai mana-mana satu daripadanya.

Uji kedua-dua keadaan

Jalankan ujian dua kali: sekali dengan tunnel bersambung dan sekali dengan tunnel terputus. Dalam setiap keadaan, sahkan pendengar, laluan dan log masuk SSH sebenar dari mesin pentadbir. Laluan yang hanya berfungsi semasa tunnel naik bukan laluan pengurusan setempat; ia satu kebetulan.

Kemudian mulakan semula tunnel semasa sesi SSH terbuka. Sesi yang bertahan membuktikan penghalaan stabil; sesi yang terputus memberitahu anda klien menulis semula laluan atau penapis semasa sambungan semula, yang wajar diketahui sebelum insiden, bukan semasanya.

Catat alamat sumber yang anda uji, kerana peraturan yang ditulis untuk 192.168.10.50 gagal secara senyap apabila komputer riba pentadbir berpindah ke subnet lain.

Tulis laluan pemulihan dalam runbook

Putuskan sekarang apa yang berlaku jika VPN keluar merosakkan laluan setempat. Akses konsol, alamat pengurusan kedua atau prosedur terdokumen untuk menghentikan klien semuanya jawapan yang sah, dan mana-mana daripadanya lebih baik daripada menemui masalah pada saat anda perlu log masuk. Jika pelayan berada jauh, laluan setempat tidak wujud, dan reka bentuk yang betul ialah laluan akses jauh yang diluluskan secara berasingan atau bastion dan bukannya port awam yang terdedah.

Kekalkan kedua-dua peranan secara berasingan dalam dokumentasi: SSH setempat untuk pentadbir yang berdekatan dan tunnel keluar untuk trafik aplikasi. Apabila peranan itu ditulis, perubahan masa depan pada mana-mana satu daripadanya mempunyai tempat yang jelas untuk diperiksa, dan orang seterusnya tidak perlu menemui semula mengapa pelayan dengan VPN masih menjawab pada alamat LAN-nya.