Dua masalah nama muncul di hampir setiap gateway OpenVPN kecil. Anda tidak bisa menjangkau laptop yang terhubung dengan nama pada sertifikatnya, dan layanan di balik terowongan tidak punya nama sama sekali. Keduanya tampak seperti satu masalah dan justru butuh penanganan berlawanan, karena satu alamat bergerak di setiap sesi dan yang lain tidak. Putuskan jenis nama apa yang Anda tambahkan sebelum menyunting apa pun.

Putuskan per nama, bukan per gateway

Ujinya sederhana: apakah alamat ini berubah ketika klien tersambung ulang? Jika ya, nama harus dihasilkan dari sesi VPN. Jika tidak, ia termasuk entri statis yang bisa Anda baca dan tinjau.

Name kindSource of truthWhere it lives
Connected clientThe address OpenVPN just assignedGenerated hosts file, rewritten per session
Service behind the tunnelA fixed address you choseStatic address= drop-in
Anything with a certificate nameThe certificate, not the poolEither, but the name must match the certificate

Mencampur keduanya adalah kegagalan yang biasa. Layanan yang dipatok ke berkas hasil generate hilang saat skrip menulis ulang berkas itu untuk pertama kali, dan klien yang ditulis ke entri statis menunjuk ke siapa pun yang terakhir memegang alamat tersebut. Kedua kesalahan itu tidak terlihat sampai sebuah nama resolve ke mesin yang salah. Saat itu tiba, orang yang men-debug mengira DNS yang rusak, bukan berkasnya.

Jalur dinamis: learn-address dan pool

OpenVPN tahu penetapannya, jadi biarkan ia memberi tahu Anda. Opsi server ini membuat penetapan bertahan lama dan bisa 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 ditambahkan, diperbarui, atau dihapus, dan meneruskan operasi, alamat, serta nama umum. Skrip minimal menambahkan satu baris per klien dan menghapusnya saat penghapusan:

#!/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 perangkat tun argumen kedua adalah alamat terowongan klien, jadi baris itu bisa dipakai langsung. Pada perangkat tap OpenVPN meneruskan alamat MAC klien, karena segmen tap bisa membawa protokol selain IPv4, dan saat itu Anda harus mencari alamatnya di berkas pool berdasarkan nama umum sebelum menulis apa pun.

Jelaskan apa berkas hasil generate itu: potret siapa yang sedang terhubung. Nama hilang saat terputus, yang justru Anda inginkan untuk laptop yang berpindah antarjaringan dan justru tidak Anda inginkan untuk server yang menyala sepanjang malam.

Jalur statis: address= dan perluasan domain

Arahkan dnsmasq ke berkas hasil generate alih-alih berkas hosts sistem, dan beri ia domain agar nama pendek meluas menjadi nama berkualifikasi penuh:

domain=corp.example
no-hosts
addn-hosts=/etc/openvpn/hosts.lan
listen-address=127.0.0.1,10.8.0.1
bind-interfaces

Dengan domain disetel, baris seperti 10.8.0.6 alice menjawab untuk alice maupun alice.corp.example. Batasi listen-address hanya ke gateway terowongan dan loopback, karena resolver yang tanpa sengaja terbit di antarmuka LAN adalah layanan yang tidak Anda maksudkan.

Layanan yang tidak pernah datang dari pool mendapat entrinya sendiri. Taruh di berkas drop-in terpisah dalam direktori konfigurasi distribusi agar peningkatan paket tidak bisa menimpanya:

address=/files.corp.example/10.8.0.20
address=/db.corp.example/10.9.0.5

Serahkan resolver atau tidak terjadi apa-apa

Resolver yang tidak ditanyai siapa pun tidak mengubah apa pun. Server harus mengumumkannya:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Klien Windows menerapkan kedua opsi sendiri. Sebagian besar klien Linux tidak: mereka butuh integrasi resolver yang didukung seperti kait update-resolv-conf distribusi atau penanganan DNS NetworkManager, atau domain pencarian dan nameserver manual. Periksa resolver klien yang sebenarnya alih-alih menganggap push dipatuhi, karena push yang diabaikan tampak persis seperti server yang tidak menjawab.

Verifikasi di tiga lapis

Tanyakan langsung ke server dulu, lalu klien, lalu aplikasi:

dig +short @10.8.0.1 alice.corp.example
getent hosts files.corp.example

Jika kueri langsung menjawab dan aplikasi tidak, kesalahannya ada pada penyerahan ke klien, bukan pada zona. Jika nama ter-resolve dan koneksi tetap gagal, namanya baik-baik saja dan hal berikutnya yang perlu dilihat adalah rute atau firewall.

Tuliskan kedua kategori di samping konfigurasi: nama mana yang dihasilkan, mana yang dipatok, dan sertifikat mana yang harus cocok dengan masing-masing. Orang berikutnya yang menambahkan server akan menyalin pola pertama yang ia temukan.

Artikel terkait