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

Dalam satu utas forum, ifconfig-noexec ditawarkan sebagai pembaikan yang mengekalkan sesi SSH hidup apabila terowong naik. Penaakulan itu kedengaran munasabah sehingga anda semak apa yang sebenarnya disentuh pilihan ini. Ia menghalang OpenVPN daripada mengkonfigurasi alamat antara muka terowong dan menyerahkan nilai itu kepada skrip; ia tidak berkata apa-apa tentang ke mana balasan kepada sambungan pengurusan anda pergi. Percaya sebaliknya menghasilkan terowong tanpa alamat yang boleh digunakan dan sesi SSH yang tetap mati.

Apa yang sebenarnya diwakilkan oleh pilihan ini

Secara lalai, klien menaikkan peranti terowong dan menetapkan alamat tempatan dan jauh yang diberikan oleh pelayan. Dengan ifconfig-noexec ditetapkan, langkah itu dilangkau, dan nilai yang dirundingkan dieksport ke persekitaran skrip supaya sesuatu yang lain boleh menggunakannya.

Pemilikan berpindah. Tiada apa yang direka sebagai gantinya.

Jadi soalan yang dijawab oleh pilihan ini ialah siapa yang mengkonfigurasi antara muka, dan soalan yang tidak dijawabnya ialah bagaimana paket mencari jalan balik kepada anda. Asingkan kedua-duanya, jika tidak anda akan menghabiskan satu malam menyunting laluan untuk menampung antara muka tanpa alamat.

Tiga pilihan serupa dengan tugas berbeza

Keluarga ini mudah dikelirukan kerana namanya berbeza satu perkataan dan gejalanya bertindih. Baca apa yang ditekan oleh setiap satu sebelum memilih mana-mana.

Ini adalah alternatif yang perlu difahami satu demi satu, bukan set untuk ditampal bersama. Menekan konfigurasi alamat tidak menekan perubahan laluan, peraturan tembok api atau pilihan yang ditolak yang membawa DNS. Skrip yang diwakilkan juga bebas menukar laluan, iaitu keputusan yang anda serahkan dan bukan elakkan.

Jika klien vendor membalut enjin, gunakan integrasi yang disokongnya dan bukan meletakkan arahan peringkat rendah ke dalam profil dan berharap pembalut mematuhinya. Pembalut sering menjana semula profil semasa menyambung, jadi suntingan manual hilang tanpa ralat. Semak di mana klien menyimpan tetapannya sebelum menghabiskan satu malam pada fail itu. Itu terpakai pada setiap baris dalam jadual, bukan hanya yang anda datang.

Sesi SSH yang anda mahu lindungi

Sambungan SSH mempunyai alamat sumber, alamat destinasi dan laluan balasan. Pada pelayan yang baru memasang lalai terowong penuh, balasan ke alamat awam anda sepadan dengan terowong, dan get laluan VPN membuangnya.

Tiada apa dalam konfigurasi alamat antara muka terowong mengubahnya.

Yang membaikinya ialah laluan yang lebih khusus untuk alamat pengurusan anda melalui get laluan sebelum terowong, atau peraturan dasar yang mengarahkan trafik itu, serta tetapan penapis yang digunakan oleh hos anda. Kedua-dua masalah kadang-kadang muncul bersama, dan begitulah satu disalah anggap sebagai penawar yang lain. Uji kedua-duanya secara berasingan: naikkan terowong tanpa pilihan itu, lihat alamat antara muka dan laluan balasan, kemudian tentukan mana antara keduanya yang benar-benar rosak.

Apa yang perlu diambil alih oleh skrip yang diwakilkan

Jika anda benar-benar mahu pemilik lain mengkonfigurasi antara muka, senaraikan kerja itu: gunakan alamat tempatan dan jauh, naikkan peranti, pulihkan atau buang pengalamatan semasa teardown, dan lakukan perkara yang sama sekali lagi selepas menyambung semula. Nilai daripada satu sesi yang berjaya tidak boleh dikodkan keras, kerana pelayan mungkin memberikan pasangan yang berbeza lain kali.

Pemboleh ubah persekitaran yang dieksport oleh klien ialah satu-satunya input yang disokong untuk kerja itu.

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

Di dalam skrip route-up pemboleh ubah itu tersedia; daripada tugas cron atau shell manual ia tidak. Sahkan cangkuk kitaran hayat mana yang digunakan versi anda, dan sahkan cangkuk itu berjalan dengan keistimewaan yang cukup untuk menukar antara muka, kerana klien mungkin sudah turun kepada pengguna tanpa keistimewaan.

Uji seluruh kitaran hayat, bukan satu sesi

Naikkan terowong, semak alamat pada peranti, kemudian sambung semula dan semak sekali lagi. Konfigurasi yang berjaya sekali dan gagal pada percubaan kedua biasanya bermakna langkah yang diwakilkan hanya berjalan pada sambungan pertama.

Kemudian uji kedua-dua kriteria penerimaan bersama: sambungan SSH baharu melalui laluan pengurusan yang dimaksudkan berfungsi, dan aplikasi yang dibenarkan menggunakan terowong dengan betul.

Sesi SSH lama yang kebetulan bertahan semasa terowong tidak mempunyai alamat bukanlah kejayaan, dan itulah keadaan yang dihasilkan oleh pilihan ini apabila tiada siapa mengambil alih kerja itu. Semak alamat antara muka dahulu, kemudian laluan balasan pengurusan, kemudian aplikasi. Jika dua daripada tiga salah, pilihan ini memindahkan kerja tanpa memberinya pemilik.