Nama klien OpenVPN dalam dnsmasq: skrip atau entri statik?
Alamat klien berubah, nama perkhidmatan tidak. Jana nama klien daripada sesi VPN, tetapkan nama perkhidmatan dalam fail drop-in, kemudian buat klien menggunakannya.
Dua masalah nama muncul pada hampir setiap gateway OpenVPN kecil. Anda tidak boleh mencapai komputer riba yang bersambung dengan nama pada sijilnya, dan perkhidmatan di belakang terowong tidak mempunyai nama langsung. Kedua-duanya kelihatan satu masalah dan memerlukan rawatan bertentangan, kerana satu alamat bergerak dengan setiap sesi dan satu lagi tidak. Tentukan jenis nama yang anda tambah sebelum mengedit apa-apa.
Tentukan setiap nama, bukan setiap gateway
Ujiannya mudah: adakah alamat ini berubah apabila klien menyambung semula? Jika ya, nama itu mesti dijana daripada sesi VPN. Jika tidak, ia tergolong dalam entri statik yang boleh anda baca dan semak.
| Name kind | Source of truth | Where it lives |
|---|---|---|
| Connected client | The address OpenVPN just assigned | Generated hosts file, rewritten per session |
| Service behind the tunnel | A fixed address you chose | Static address= drop-in |
| Anything with a certificate name | The certificate, not the pool | Either, but the name must match the certificate |
Mencampurkan keduanya ialah kegagalan biasa. Perkhidmatan yang ditetapkan dalam fail yang dijana hilang apabila skrip menulis semula fail itu buat kali pertama, dan klien yang ditulis dalam entri statik menunjuk kepada sesiapa yang memegang alamat itu terakhir. Kedua-dua kesilapan kekal tidak kelihatan sehingga sesuatu nama diselesaikan ke mesin yang salah. Pada masa itu, penyahpepijat menganggap DNS rosak, bukan fail itu.
Laluan dinamik: learn-address dan kolam
OpenVPN tahu peruntukan itu, jadi biarkan ia memberitahu anda. Pilihan pelayan ini menjadikan peruntukan tahan lama dan boleh diskrip:
client-config-dir /etc/openvpn/ccd
ifconfig-pool-persist /etc/openvpn/ip-pool 60
script-security 2
learn-address /etc/openvpn/learn-address.sh
learn-address menjalankan skrip anda setiap kali alamat ditambah, dikemas kini atau dipadam, dan menghantar operasi, alamat dan nama umum. Skrip minimum menambah satu baris bagi setiap klien dan mengeluarkannya semasa pemadaman:
#!/bin/sh
HOSTS=/etc/openvpn/hosts.lan
case "$1" in
add|update) echo "$2 $3" >> "$HOSTS" ;;
delete) sed -i "/^$2 /d" "$HOSTS" ;;
esac
kill -HUP $(cat /var/run/dnsmasq.pid)
Pada peranti tun, argumen kedua ialah alamat terowong klien, jadi baris itu boleh digunakan terus. Pada peranti tap, OpenVPN menghantar alamat MAC klien sebaliknya, kerana segmen tap boleh membawa protokol selain IPv4, dan kemudian anda perlu mencari alamat itu dalam fail kolam mengikut nama umum sebelum menulis apa-apa.
Jelaskan apa itu fail yang dijana: petret siapa yang bersambung sekarang. Nama hilang apabila terputus, yang memang anda mahukan untuk komputer riba yang berpindah antara rangkaian dan memang tidak anda mahukan untuk pelayan yang menyala sepanjang malam.
Laluan statik: address= dan pengembangan domain
Halakan dnsmasq ke fail yang dijana dan bukan fail hosts sistem, dan berikannya domain supaya nama pendek berkembang menjadi nama yang layak sepenuhnya:
domain=corp.example
no-hosts
addn-hosts=/etc/openvpn/hosts.lan
listen-address=127.0.0.1,10.8.0.1
bind-interfaces
Apabila domain ditetapkan, baris seperti 10.8.0.6 alice menjawab untuk alice dan juga alice.corp.example. Hadkan listen-address kepada gateway terowong dan loopback, kerana penyelesai yang diterbitkan secara tidak sengaja pada antara muka LAN ialah perkhidmatan yang anda tidak berniat untuk tawarkan.
Perkhidmatan yang tidak pernah datang dari kolam mendapat entri sendiri. Letakkannya dalam fail drop-in berasingan dalam direktori konfigurasi edaran supaya peningkatan pakej tidak boleh menimpanya:
address=/files.corp.example/10.8.0.20
address=/db.corp.example/10.9.0.5
Serahkan penyelesai atau tiada apa yang berlaku
Penyelesai yang tidak ditanya sesiapa tidak mengubah apa-apa. Pelayan mesti mengumumkannya:
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"
Klien Windows menggunakan kedua-dua pilihan sendiri. Kebanyakan klien Linux tidak: mereka memerlukan integrasi penyelesai yang disokong seperti cangkuk update-resolv-conf edaran atau pengendalian DNS NetworkManager, atau domain carian dan pelayan nama manual. Periksa penyelesai sebenar klien dan bukannya menganggap push dipatuhi, kerana push yang diabaikan kelihatan sama seperti pelayan yang tidak menjawab.
Sahkan pada tiga lapisan
Tanya pelayan secara langsung dahulu, kemudian klien, kemudian aplikasi:
dig +short @10.8.0.1 alice.corp.example
getent hosts files.corp.example
Jika pertanyaan langsung menjawab dan aplikasi tidak, kesalahannya pada penyerahan kepada klien dan bukan pada zon. Jika nama diselesaikan dan sambungan masih gagal, namanya betul dan perkara seterusnya untuk dilihat ialah laluan atau tembok api.
Tuliskan kedua-dua kategori di sebelah konfigurasi: nama mana yang dijana, mana yang ditetapkan, dan sijil mana yang perlu dipadankan oleh setiap satu. Orang seterusnya yang menambah pelayan akan menyalin corak pertama yang ditemuinya.