ifconfig-noexec tidak menyelamatkan sesi SSH Anda: apa yang sebenarnya dilakukannya

Di suatu utas forum, ifconfig-noexec ditawarkan sebagai perbaikan yang menjaga sesi SSH tetap hidup saat terowongan naik. Penalaran itu terdengar masuk akal sampai Anda memeriksa apa yang sebenarnya disentuh opsi ini. Opsi ini menghentikan OpenVPN mengonfigurasi alamat antarmuka terowongan dan menyerahkan nilai-nilai itu ke skrip; opsi ini tidak mengatakan apa pun tentang ke mana balasan koneksi manajemen Anda pergi. Mempercayai hal sebaliknya menghasilkan terowongan tanpa alamat yang bisa dipakai dan sesi SSH yang tetap mati.

Apa yang sebenarnya didelegasikan opsi ini

Secara bawaan, klien menaikkan perangkat terowongan dan menetapkan alamat lokal serta jarak jauh yang diberikan server kepadanya. Dengan ifconfig-noexec disetel, langkah itu dilewati, dan nilai yang dinegosiasikan diekspor ke lingkungan skrip agar sesuatu yang lain bisa menerapkannya.

Kepemilikan berpindah. Tidak ada yang diciptakan sebagai gantinya.

Jadi pertanyaan yang dijawab opsi ini adalah siapa yang mengonfigurasi antarmuka, dan pertanyaan yang tidak dijawabnya adalah bagaimana paket menemukan jalan kembali kepada Anda. Pisahkan keduanya, atau Anda akan menghabiskan satu malam menyunting rute untuk menutupi antarmuka tanpa alamat.

Tiga opsi serupa dengan tugas berbeda

Keluarganya mudah tertukar karena namanya berbeda satu kata dan gejalanya tumpang tindih. Baca apa yang ditekan masing-masing sebelum memilih salah satunya.

Ini adalah alternatif yang harus dipahami satu per satu, bukan kumpulan untuk ditempel bersama. Menekan konfigurasi alamat tidak menekan perubahan rute, aturan firewall, atau opsi dorong yang membawa DNS. Skrip yang didelegasikan juga bebas mengubah rute, yang merupakan keputusan yang Anda serahkan alih-alih hindari.

Jika klien vendor membungkus mesinnya, gunakan integrasi yang didukung alih-alih menaruh direktif tingkat rendah ke dalam profil dan berharap pembungkusnya menghormatinya. Pembungkus sering membuat ulang profil saat terhubung, sehingga suntingan manual hilang tanpa kesalahan. Periksa di mana klien menyimpan pengaturannya sebelum menghabiskan satu malam untuk file itu. Itu berlaku untuk setiap baris di tabel, bukan hanya yang Anda cari.

Sesi SSH yang ingin Anda lindungi

Koneksi SSH punya alamat sumber, alamat tujuan, dan jalur balasan. Di server yang baru memasang bawaan terowongan penuh, balasan ke alamat publik Anda cocok dengan terowongan, dan gateway VPN membuangnya.

Tidak ada apa pun dalam konfigurasi alamat antarmuka terowongan yang mengubah itu.

Yang memperbaikinya adalah rute yang lebih spesifik untuk alamat manajemen Anda melalui gateway sebelum terowongan, atau aturan kebijakan yang mengarahkan lalu lintas itu, ditambah pengaturan filter apa pun yang diterapkan host Anda. Kedua masalah kadang muncul bersamaan, dan begitulah satu disalahartikan sebagai obat bagi yang lain. Uji keduanya secara terpisah: naikkan terowongan tanpa opsi itu, lihat alamat antarmuka dan jalur balasan, lalu putuskan mana dari keduanya yang benar-benar rusak.

Apa yang harus diambil alih skrip yang didelegasikan

Jika Anda benar-benar ingin pemilik lain mengonfigurasi antarmuka, rincikan pekerjaannya: terapkan alamat lokal dan jarak jauh, naikkan perangkat, pulihkan atau hapus pengalamatan saat teardown, dan lakukan hal yang sama lagi setelah menyambung ulang. Nilai dari satu sesi yang berhasil tidak boleh dikodekan tetap, karena server mungkin memberikan pasangan berbeda lain kali.

Variabel lingkungan yang diekspor klien adalah satu-satunya masukan yang didukung untuk pekerjaan itu.

env | grep -E '^ifconfig_|^route_'

Di dalam skrip route-up variabel-variabel itu tersedia; dari tugas cron atau shell manual tidak. Pastikan hook siklus hidup mana yang dipakai versi Anda, dan pastikan hook berjalan dengan hak istimewa yang cukup untuk mengubah antarmuka, karena klien mungkin sudah turun ke pengguna tanpa hak istimewa.

Uji seluruh siklus hidup, bukan satu sesi

Naikkan terowongan, periksa alamat pada perangkat, lalu sambung ulang dan periksa lagi. Konfigurasi yang berhasil sekali dan gagal pada percobaan kedua biasanya berarti langkah yang didelegasikan hanya berjalan pada koneksi pertama.

Lalu uji kedua kriteria penerimaan bersamaan: koneksi SSH baru melalui jalur manajemen yang dimaksud berhasil, dan aplikasi yang diizinkan memakai terowongan dengan benar.

Sesi SSH lama yang kebetulan bertahan saat terowongan tidak punya alamat bukanlah keberhasilan, dan itulah tepatnya keadaan yang dihasilkan opsi ini ketika tidak ada yang mengambil alih pekerjaan. Periksa alamat antarmuka lebih dulu, lalu jalur balasan manajemen, lalu aplikasinya. Jika dua dari tiga salah, opsi ini memindahkan pekerjaan tanpa memberinya pemilik.