Hook client-connect OpenVPN: ke mana alamat anda sebenarnya pergi

Memulangkan alamat daripada skrip client-connect kelihatan seolah-olah ia patut menetapkan IP klien. Ia tidak: satu-satunya saluran hook ke pelayan ialah fail sementara yang laluannya tiba sebagai argumen terakhir skrip, dan alamat mesti ditulis di sana dalam sintaks ifconfig-push. Skrip yang mencetak alamat atau keluar dengan sifar tanpa menulis apa-apa menghasilkan klien bersambung dengan alamat daripada kumpulan, dan log pelayan kelihatan sihat sepenuhnya.

Kekeliruan itu wajar, kerana beberapa hook lain memang membalas melalui kod keluar atau pemboleh ubah persekitaran. Yang ini mempunyai kontraknya sendiri, dan kontrak itu bermula dengan nama fail.

Hook menulis fail, bukan nilai pulangan

Pengisytiharan ialah dua baris: script-security 2 untuk membenarkan panggilan, kemudian client-connect /etc/openvpn/server/assign-address.sh. Apabila klien mengesahkan diri, pelayan menjalankan skrip itu dengan laluan fail yang dijana ditambah sebagai argumen terakhir, yang merupakan $1 hanya jika pengisytiharan tidak menghantar argumen tambahan sendiri. Semua yang digunakan pada klien itu masuk ke fail itu sebagai arahan biasa, satu setiap baris, tepat seperti yang akan muncul dalam konfigurasi. Pembalut yang menambah parameternya sendiri mengalihkan kedudukan, dan gejala klasik ialah skrip yang menulis ke laluan yang kelihatan seperti --verbose.

Status keluar ialah separuh lagi kontrak. Sifar bermaksud terima dan baca fail; apa-apa lagi menolak sambungan, dan begitulah identiti yang tidak dipetakan ditolak daripada kembali ke kumpulan secara senyap. Tulis arahan lengkap sebelum memulangkan kejayaan, supaya fail yang separuh ditulis tidak pernah menjadi konfigurasi klien.

Dua arahan patut diberi perhatian kerana ia berinteraksi dengan semua yang lain. ifconfig-push menetapkan alamat, manakala route yang ditolak memberitahu klien apa yang boleh dicapai melalui terowong; pulangkan yang pertama dan lupakan yang kedua dan anda mendapat klien dengan alamat tetapi tiada tempat untuk pergi. Urutan dalam fail tidak penting, tetapi kelengkapan penting. Hook yang menolak laluan untuk awalan yang tiada rakan setara boleh sampai ialah kesilapan yang sama dilihat dari hujung yang lain.

Input tiba melalui pemboleh ubah persekitaran: common_name, trusted_ip, ifconfig_pool_remote_ip dan selebihnya. Layannya semuanya sebagai rentetan dari luar pelayan, jangan sekali-kali sebagai serpihan shell.

Pemetaan alamat ialah dasar, bukan aritmetik

Jalan pintas yang menggoda ialah menghurai nama sijil dan menggunakan digitnya sebagai oktet terakhir. Itu bukan pengagih, dan ia gagal dengan cara biasa: dua nama dengan akhiran sama berlanggar, nama yang berakhir dengan 300 bukan alamat, dan sijil yang dinamakan semula oleh pentadbir memindahkan peranti secara senyap. Sahkan keahlian subnet, julat hos yang boleh digunakan, alamat terpelihara dan keunikan pada setiap panggilan, dan simpan pemetaan dalam jadual yang boleh dibaca manusia.

Sesiapa yang mengawal nama mengawal alamat, jadi tentukan apa yang sebenarnya diwakili common_name dalam penggunaan ini. Dengan username-as-common-name didayakan, identiti ialah log masuk dan bukan subjek sijil. Jangan sekali-kali menghantar nilai itu ke penilaian shell, dan jangan sekali-kali membenarkan klien mempengaruhi laluan fail.

Pengagih yang disokong daftar mesti bertahan daripada keselarian. Tempah alamat secara atomik, kendalikan tulisan yang gagal tanpa menerima klien yang separuh dikonfigurasi, dan tandakan setiap peruntukan dengan sambungan yang memilikinya, supaya pemutusan lewat daripada sesi lama tidak boleh melepaskan alamat yang sudah dipegang oleh sesi lebih baharu. Beberapa instans pelayan yang berkongsi satu kumpulan menjadikan keperluan itu lebih tajam, bukan pilihan.

Topologi menentukan maksud ifconfig-push

Dengan topology subnet pada 10.77.0.0/24, ifconfig-push 10.77.0.20 255.255.255.0 ialah alamat serta topeng rangkaiannya. Di bawah topology net30 argumen kedua bukan topeng langsung tetapi alamat rakan setara, jadi menyalin bentuk subnet ke pelayan net30 memberi anda klien yang bergabung dan tidak boleh melepaskan trafik. Tukar topologi dengan sengaja, jangan sekali-kali supaya contoh kelihatan konsisten. Pelayan yang sudah menjalankan net30 mempunyai klien hidup pada pengalamatan lama, jadi pertukaran itu ialah migrasi dengan tetingkap penyelenggaraan, bukan suntingan satu baris.

Alamat statik mesti berada di luar kumpulan dinamik dan di luar setiap peruntukan statik lain, termasuk yang diberikan oleh fail client-config-dir biasa. Jika dua mekanisme boleh menghasilkan alamat yang sama untuk klien berbeza, salah satunya akhirnya akan berbuat demikian.

Uji empat kes sebelum anda mempercayainya

Jalankan pemeriksaan yang sama terhadap identiti yang dipetakan, yang tidak dipetakan, sambungan semula dan kegagalan daftar yang disimulasikan. openvpn --config client.ovpn --verb 4 menunjukkan alamat yang diperuntukkan dalam balasan push, dan pada pelayan grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log mengesahkan apa yang sebenarnya dihantar. Untuk identiti yang tidak dipetakan, hasil yang dijangkakan ialah sambungan ditolak, bukan alamat daripada kumpulan.

Kemudian periksa direktori tempat daemon menulis fail sementara itu. Skrip berjalan dalam konteks perkhidmatan yang diturunkan, jadi laluan yang boleh ditulis oleh root tetapi tidak oleh daemon menjadikan setiap sambungan penolakan dengan ralat kebenaran yang tertimbus beberapa baris di bawah dalam log.

Peruntukan bukan kebenaran: alamat yang dipin masih tidak memberikan akses ke setiap destinasi di belakang pelayan. Kekalkan dasar penghalaan dan tembok api dalam lapisannya sendiri, dan sahkan terhadap alamat yang baru anda tetapkan.