Mga pangalan ng kliyenteng OpenVPN sa dnsmasq: script o static na entry?

Dalawang problema sa pangalan ang lumilitaw sa halos bawat maliit na gateway ng OpenVPN. Hindi mo maabot ang konektadong laptop sa pangalan sa sertipiko nito, at ang mga serbisyo sa likod ng tunnel ay walang pangalan. Mukha silang isang problema at kailangan ng magkasalungat na pagtrato, dahil ang isang address ay gumagalaw sa bawat session at ang isa ay hindi. Magpasya kung anong uri ng pangalan ang idinadagdag mo bago mo i-edit ang anuman.

Magpasya bawat pangalan, hindi bawat gateway

Simple ang pagsubok: nagbabago ba ang address na ito kapag muling kumonekta ang kliyente? Kung oo, ang pangalan ay dapat buuin mula sa session ng VPN. Kung hindi, kabilang ito sa isang static na entry na mababasa at masusuri mo.

Ang paghahalo sa kanila ang karaniwang kabiguan. Ang serbisyong naka-pin sa nabuong file ay nawawala sa unang pagkakataon na isulat muli ito ng script, at ang kliyenteng nakasulat sa static na entry ay tumuturo sa kung sino ang huling may hawak ng address na iyon. Nananatiling hindi nakikita ang dalawang pagkakamali hanggang sa maresolba ang pangalan sa maling makina. Sa puntong iyon, ipinapalagay ng nagde-debug na sira ang DNS at hindi ang file.

Ang dinamikong landas: learn-address at ang pool

Alam ng OpenVPN ang pagtatalaga, kaya hayaan siyang sabihin ito sa iyo. Ginagawa ng mga opsyon ng server na ito ang pagtatalaga na matibay at maiskrip:

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 ay nagpapatakbo ng iyong script sa tuwing may address na idinagdag, ina-update, o tinatanggal, at ipinapasa ang operasyon, ang address, at ang common name. Ang pinakamaliit na script ay nagdaragdag ng isang linya bawat kliyente at tinatanggal ito kapag binura:

#!/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)

Sa isang tun device ang pangalawang argumento ay ang tunnel address ng kliyente, kaya direktang magagamit ang linya. Sa isang tap device, ipinapasa ng OpenVPN ang MAC address ng kliyente sa halip, dahil ang tap segment ay makakapagdala ng iba pang protocol bukod sa IPv4, at kailangan mong hanapin ang address sa pool file ayon sa common name bago magsulat ng anuman.

Maging malinaw kung ano ang nabuong file: isang snapshot kung sino ang konektado ngayon. Nawawala ang mga pangalan kapag nadiskonekta, na siyang eksaktong gusto mo para sa mga laptop na lumilipat sa pagitan ng mga network at eksaktong ayaw mo para sa isang server na bukas magdamag.

Ang static na landas: address= at pagpapalawak ng domain

Ituro ang dnsmasq sa nabuong file sa halip na sa hosts file ng system, at bigyan ito ng domain upang ang maiikling pangalan ay lumawak sa ganap na kwalipikadong pangalan:

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

Kapag nakatakda ang domain, ang linyang tulad ng 10.8.0.6 alice ay sumasagot para sa alice at alice.corp.example. Panatilihin ang listen-address sa tunnel gateway at loopback lamang, dahil ang resolver na aksidenteng na-publish sa LAN interface ay isang serbisyong hindi mo sinadyang ialok.

Ang mga serbisyong hindi kailanman nagmumula sa pool ay may sariling entry. Ilagay ang mga ito sa hiwalay na drop-in file sa configuration directory ng distribution upang hindi ito ma-overwrite ng pag-upgrade ng package:

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

Ipaubaya ang resolver o walang mangyayari

Ang resolver na walang nagtatanong ay walang binabago. Dapat itong ipahayag ng server:

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

Ang mga kliyenteng Windows ay naglalapat ng parehong opsyon sa kanilang sarili. Karamihan sa mga kliyenteng Linux ay hindi: kailangan nila ng suportadong integrasyon ng resolver tulad ng update-resolv-conf hook ng distribution o ang pamamahala ng DNS ng NetworkManager, o ng manu-manong search domain at nameserver. Suriin ang aktwal na resolver ng kliyente sa halip na ipagpalagay na sinunod ang push, dahil ang isang push na binabalewala ay mukhang eksaktong isang server na hindi sumasagot.

I-verify sa tatlong antas

Tanungin muna ang server nang direkta, pagkatapos ang isang kliyente, pagkatapos ang aplikasyon:

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

Kung sumasagot ang mga direktang query at ang aplikasyon ay hindi, ang kasalanan ay sa paghahatid sa kliyente at hindi sa zone. Kung naresolba ang pangalan at nabibigo pa rin ang koneksyon, maayos ang pangalan at ang susunod na titingnan ay ang ruta o firewall.

Isulat ang dalawang kategorya sa tabi ng configuration: aling mga pangalan ang nabubuo, alin ang naka-pin, at aling sertipiko ang dapat tugma ng bawat isa. Ang susunod na taong magdadagdag ng server ay kokopyahin ang unang pattern na makita niya.