Pertahankan SSH lokal saat host menjalankan VPN keluar

Sebuah server Linux kecil menjalankan VPN keluar untuk aplikasi yang dihostingnya, dan administrator tetap ingin menjangkaunya lewat SSH dari meja sebelah. Itu kebutuhan yang wajar, dan biasanya tidak memerlukan port forwarding, alamat penyedia, atau lubang di tunnel. Yang dibutuhkan adalah jalur manajemen yang dirancang dengan sengaja alih-alih diwarisi dari apa yang dilakukan klien VPN terhadap tabel routing.

Langkah-langkah di bawah mengasumsikan administrator berada di LAN yang sama.Administrasi jarak jauh adalah masalah lain dengan jawaban lain.

Ikat SSH ke alamat yang digunakan administrator

Mulailah dari listener.ss -ltnp | grep :22 menunjukkan ke apa sshd terikat, dan listener pada 0.0.0.0 menerima koneksi dari setiap antarmuka, termasuk tunnel. Mengikat ke alamat LAN lebih sempit dan membuat maksudnya terlihat:ListenAddress 192.168.10.20 di sshd_config, diikuti uji konfigurasi dan pemuatan ulang. Salah ketik pada alamat itu lebih terlihat daripada wildcard, karena sshd menolak mulai ketika alamatnya tidak ada.

Biarkan pemeriksaan kunci host dan autentikasi per pengguna persis seperti adanya. „Ini hanya jaringan lokal“ bukan metode autentikasi, dan kanal manajemen yang melewati verifikasi kunci karena rutenya pendek adalah kanal manajemen yang menunggu disalahgunakan. Reservasi DHCP atau alamat statis membuat target dapat diprediksi tanpa menjadikannya identitas publik server.

Jauhkan rute LAN dari tunnel

Host dengan alamat pada 192.168.10.0/24 memiliki rute terhubung untuk prefiks itu, dan rute yang lebih spesifik mengalahkan default VPN di dalam tabel yang sama. Itulah sebabnya SSH lokal sering tetap berfungsi sendiri saat tunnel naik. Verifikasi alih-alih mengasumsikan:ip route get 192.168.10.50 menyebutkan antarmuka dan alamat sumber yang akan digunakan kernel, dan jawabannya harus perangkat LAN, bukan tunnel. Ulangi pemeriksaan dari mesin administrator juga, karena tabelnya sendiri yang menentukan apakah paket pernah tiba. Dua host pada kabel yang sama bisa berbeda pendapat tentang arah mana yang dapat dijangkau.

Asumsi itu patah di dua tempat. Aturan routing berbasis kebijakan dapat mengirim lalu lintas ke tabel yang default-nya menunjuk ke tunnel sebelum tabel utama diperiksa. Klien VPN dengan fitur kunci atau kill switch juga dapat memblokir lalu lintas yang tidak masuk ke tunnel, apa pun kata tabel routing.

VLAN manajemen yang dirutekan adalah kasus lainnya. Jika administrator duduk pada 192.168.50.0/24 di belakang router lokal, server memerlukan rute eksplisit untuk prefiks itu melalui 192.168.10.1, dan rute itu harus bertahan dari koneksi ulang. Jaga pengecualian tetap khusus untuk prefiks manajemen; pengecualian luas untuk rentang privat mengalahkan tujuan tunnel.

Buat pengecualian firewall sama sempit dengan aturannya

Jika host menjalankan firewall, izinkan SSH hanya dari sumber manajemen dan hanya pada antarmuka LAN. Aturan yang mengizinkan port 22 dari mana saja lebih luas daripada kebutuhan dan lebih sulit dibenarkan dalam tinjauan. Pada host nftables aturan itu berada di rantai input dengan antarmuka dan sumber dicocokkan; pada host iptables padanannya adalah sepasang pencocokan pada -i dan -s. Beri komentar pada aturan dengan grup administrator yang dilayaninya, agar audit berikutnya tidak perlu menebak mengapa port 22 terbuka.

Periksa juga filter klien VPN itu sendiri. Beberapa klien memasang aturan yang membuang lalu lintas lokal secara desain, dan aturan firewall yang benar di atas pembuangan di tingkat klien tidak mengubah apa pun. Baca konfigurasi klien sebelum mengedit firewall host, karena dua filter secara seri menghasilkan kegagalan yang tidak menyerupai salah satunya.

Uji kedua keadaan

Jalankan uji dua kali: sekali dengan tunnel tersambung dan sekali dengan tunnel terputus. Pada setiap keadaan, konfirmasi listener, rute, dan login SSH sungguhan dari mesin administrator. Jalur yang hanya berfungsi selama tunnel naik bukanlah jalur manajemen lokal; itu kebetulan.

Lalu restart tunnel saat sesi SSH terbuka. Sesi yang bertahan membuktikan routing stabil; sesi yang putus memberi tahu Anda bahwa klien menulis ulang rute atau filter saat tersambung ulang, yang layak diketahui sebelum insiden, bukan selama insiden.

Catat alamat sumber yang Anda gunakan untuk menguji, karena aturan yang ditulis untuk 192.168.10.50 gagal diam-diam ketika laptop administrator pindah ke subnet lain.

Tulis jalur pemulihan ke runbook

Putuskan sekarang apa yang terjadi jika VPN keluar merusak jalur lokal. Akses konsol, alamat manajemen kedua, atau prosedur terdokumentasi untuk menghentikan klien semuanya jawaban yang sah, dan salah satunya lebih baik daripada menemukan masalah pada saat Anda perlu masuk. Jika server berada jauh, jalur lokal tidak ada, dan desain yang benar adalah rute akses jarak jauh yang disetujui secara terpisah atau bastion, bukan port publik yang terbuka.

Jaga kedua peran tetap terpisah dalam dokumentasi: SSH lokal untuk administrator yang ada di dekatnya, dan tunnel keluar untuk lalu lintas aplikasi. Ketika peran itu tertulis, perubahan di masa depan pada salah satunya punya tempat yang jelas untuk diperiksa, dan orang berikutnya tidak perlu menemukan ulang mengapa server dengan VPN masih menjawab pada alamat LAN-nya.