Mengapa Aturan Port Sumber Merusak Salah Satu Jalur SSH Anda

Dua entri manajemen pada satu host, satu port layanan, dan aturan kebijakan yang dimaksudkan membantu keduanya. Aturan itu cocok dengan port sumber 22, mengirim pencarian ke tabel yang hanya mengenal default WAN, dan entri VPN berhenti menjawab login baru sementara entri langsung tetap berfungsi. Tidak ada yang misterius begitu selektornya dibaca dengan benar. Port sumber mengidentifikasi layanan, bukan jalur tempat suatu koneksi tiba.

Dua entri, satu port layanan

Host memiliki alamat di sisi LAN dan alamat VPN, dan sshd mendengarkan keduanya. Sesi langsung dan sesi terowongan karena itu berbagi port layanan dan hanya berbeda pada alamat lokal mana yang menerima koneksi.

Perbedaan itu cukup untuk memilih jalur balasan, dan justru itulah perbedaan yang dibuang oleh aturan berbasis port. Kedua sesi menghasilkan balasan yang port sumbernya 22, sehingga aturan yang cocok dengan port itu tidak dapat memisahkannya. Aturan itu mengirim kedua pencarian ke tabel yang sama, dan salah satunya menerima jawaban yang tidak cocok. Perbaikannya adalah mencocokkan atribut yang benar-benar berbeda.

Memberi setiap entri portnya sendiri juga akan berfungsi, dan memperlakukannya sebagai syarat adalah pilihan desain, bukan sifat SSH.

Baca aturannya, lalu tabelnya

Aturan kebijakan adalah selektor terurut, dan aturan pertama yang mengembalikan jawaban yang dapat dipakai mengakhiri pencarian. Baca daftar itu berurutan dan catat aturan mana yang bisa menang.

Lalu baca tabel yang ditunjuk aturan itu, karena aturan yang berhasil diselesaikan bukan berarti aturan yang diselesaikan secara berguna. Tabel yang hanya berisi rute default mengirim balasan bersumber VPN keluar melalui antarmuka WAN. Rute yang lebih spesifik di tabel berikutnya tidak pernah diperiksa, dan itulah sebabnya menambah tabel kedua begitu sering tidak mengubah apa pun. Tabel yang dipilih adalah hal yang perlu diperiksa.

ip -4 rule show
ip route show table 100
ip route show table main

Kedua keluaran itu bersama-sama menjelaskan hasilnya; masing-masing sendiri mengundang kesimpulan yang salah.

Batasi aturan pada alur yang Anda maksud

Atribut yang memisahkan kedua entri adalah alamat sumber lokal. Aturan yang cocok dengan alamat itu hanya mengirim sesi terowongan ke tabel privat dan membiarkan sesi langsung di tabel utama.

Aturan itu harus dipasangkan dengan tabel yang berisi rute privat dan jalur kembali untuk subnet tersebut. Batasi keduanya pada lalu lintas manajemen alih-alih setiap layanan di host. Aturan yang menangkap semua lalu lintas dari alamat itu juga akan mengalihkan apa pun yang dikirim host dari sana. Yang sempit mengalahkan yang cerdik di sini, karena orang berikutnya harus membacanya.

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

Jika kedua entri diterjemahkan ke satu alamat lokal, perbedaan itu hilang dan desainnya membutuhkan status yang sadar koneksi sebagai gantinya.

Pisahkan pendengar, izin, dan pemilihan balasan

Tiga hal terpisah harus benar sebelum sesi berfungsi: alamatnya ada, layanannya mendengarkan di sana, dan balasannya menemukan jalan kembali. Perubahan rute hanya memperbaiki yang ketiga.

Konfigurasi pendengar adalah berkasnya sendiri dan pemuatan ulangnya sendiri, dan beberapa alamat pendengaran adalah hal normal. Autentikasi adalah keputusan ketiga lagi, dan pengecualian perutean tidak memberi siapa pun akses. Pertahankan verifikasi kunci host, autentikasi akun, dan pembatasan sumber pada kedua entri, dan tahan dorongan untuk melemahkan kontrol terowongan lainnya agar satu jalur manajemen berfungsi.

Pertahankan saluran pemulihan yang tidak bergantung pada jalur yang Anda ubah, karena kesalahan di sini mengunci perbaikannya sendiri.

Buktikan dengan sesi baru, bukan yang lama

Terminal yang sudah terbentuk tidak membuktikan apa pun, karena ia diterima sebelum perubahan. Buka sesi baru melalui setiap entri yang dimaksud.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

Lalu ulangi penyambungan ulang VPN dan coba lagi, karena rute yang bertahan dari penyambungan ulang tidak sama dengan rute yang ditambahkan ke tabel yang dikosongkan oleh penyambungan ulang. Amati sumber yang ditolak secara terpisah dari yang diizinkan, agar upaya yang diblokir tidak bersembunyi di balik sesi yang berfungsi. Simpan alamat lokal, aturan, dan tabel di samping hasilnya. Jika Anda memisahkan port sebagai gantinya, catat itu sebagai keputusan operasional, bukan batasan SSH.