Kerio di Linux: memberi kvnet MAC yang diharapkan server

Tiga hal harus sepakat sebelum terowongan Kerio membawa lalu lintas: alamat pada antarmuka kvnet, nilai yang dicatat klien, dan apa yang diharapkan kebijakan server atau DHCP. Ketika ketiganya tidak sepakat, terowongan tetap mengautentikasi dan tetap naik, dan itulah yang membuat kegagalannya membingungkan. Antarmuka dibuat per koneksi, jadi alamat yang disetel dengan tangan hanya milik sesi itu dan bukan yang lain. Itulah bentuk masalahnya, dan solusinya adalah hook, bukan berkas konfigurasi. Sisanya adalah dari mana membaca nilainya dan di mana menerapkannya.

Mengapa alamatnya terus kembali

kvnet adalah adaptor virtual yang dibuat klien saat koneksi dimulai dan dihapus saat koneksi berakhir. Jadi ip link set manual bertahan persis selama sesi tempat perintah itu diterapkan, dan koneksi berikutnya dimulai dari apa pun yang dialokasikan klien. Pada mesin tempat klien gagal menerapkan alamat yang diharapkan, setiap koneksi ulang memunculkan kembali ketidakcocokan yang sama, dan aturan sewa atau akses menolak perangkat itu lagi.

Pola itu sudah diagnostik dengan sendirinya. Terowongan yang bekerja pada satu sesi dan gagal pada sesi berikutnya bukan masalah kredensial, karena kredensial tidak berubah antar koneksi.

Baca nilainya dari klien, bukan dari antarmuka

Klien Linux menulis detail negosiasi ke log debug-nya, dan alamat yang hendak dipakainya muncul di sana sebagai token berbentuk alamat terakhir dalam urutan koneksi. Bandingkan dengan yang sebenarnya dipegang kernel, yang berjarak satu readlink: cat /sys/class/net/kvnet/address.

Jika keduanya berbeda, klien tahu nilai yang benar dan gagal menerapkannya, dan hook yang menerapkannya setelah antarmuka ada menutup celah itu. Jika log tidak memuat alamat sama sekali, masalahnya lebih awal dan termasuk pada versi klien atau profil server, bukan pada skrip.

Terapkan setelah antarmuka ada

Pengguna NetworkManager dapat menaruh skrip di direktori dispatcher-nya dan bertindak hanya ketika antarmuka VPN naik. Klien yang dikelola systemd memerlukan kehati-hatian lebih: drop-in yang berjalan saat layanan mulai biasanya aktif sebelum adaptor ada, jadi hook harus menunggu antarmuka alih-alih menganggapnya ada. Setel alamatnya saat itu, dan jika kernel menolak selagi link naik, turunkan link, setel alamat, lalu naikkan lagi. Baca kembali token yang diekstrak melalui pola MAC sebelum meneruskannya ke ip link, agar baris log yang tak terduga tidak bisa menjadi argumen.

Apa pun yang berjalan sebagai root dari log klien layak mendapat kepemilikan yang sempit: berkas milik root, tidak dapat ditulis orang lain, dan tanpa interpolasi shell melebihi alamat yang tervalidasi. Pertahankan pemeriksaan pola di dalam skrip. Jangan biarkan isi log menentukan perintah mana yang berjalan.

Verifikasi sewa, bukan link

ip -4 -o addr show dev kvnet seharusnya menampilkan alamat dalam rentang yang diharapkan, ip neigh show dev kvnet seharusnya menampilkan gateway, dan satu layanan di balik VPN seharusnya menjawab. Lalu putuskan dan sambungkan ulang sekali; jika alamatnya kembali, hook dipicu oleh peristiwa yang salah atau tidak dipicu sama sekali.

Antarmuka yang muncul dengan alamat benar dan tidak pernah mendapat sewa menunjuk ke sisi server. Itu pemeriksaan lain dan biasanya tim lain. Pastikan akun diizinkan dan kumpulan masih punya alamat sebelum menyunting hook lagi.

Tinjau kembali akal-akalan setelah peningkatan

Build klien yang menyetel alamat dengan benar membuat hook Anda menerapkan nilai yang kedaluwarsa, yang merupakan kesalahan baru yang diperkenalkan oleh perbaikan. Jangan pernah menyalin MAC dari mesin lain atau kiriman forum juga; gunakan nilai yang dicatat klien ini untuk akun ini, dan catat tanggal Anda memverifikasinya.

Jaga skrip cukup pendek untuk dibaca sekali duduk. Akal-akalan yang mengurai log bersifat sementara. Yang bertahan adalah yang bisa dipahami pembaca masa depan tanpa utas aslinya.