Назвы кліентаў OpenVPN у dnsmasq: скрыпт ці статычныя запісы?
Адрасы кліентаў змяняюцца, назвы службаў — не. Стварайце назвы кліентаў з VPN-сесіі, замацуйце назвы службаў у drop-in файле, а затым прымусьце кліентаў карыстацца ім.
Дзве праблемы з назвамі ўзнікаюць амаль на кожным невялікім шлюзе OpenVPN. Вы не можаце дасягнуць падключанага ноўтбука па назве з яго сертыфіката, а службы за тунелем наогул не маюць назваў. Яны выглядаюць як адна праблема, але патрабуюць процілеглага падыходу, бо адзін адрас змяняецца з кожнай сесіяй, а другі — не. Вызначце, які тып назвы вы дадаяце, перш чым нешта рэдагаваць.
Вырашайце для кожнай назвы, а не для шлюза
Тэст просты: ці змяняецца гэты адрас, калі кліент перападключаецца? Калі так, назву трэба генераваць з VPN-сесіі. Калі не, яна належыць да статычнага запісу, які вы можаце прачытаць і перагледзець.
| 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 |
Змешванне іх — звычайная памылка. Служба, замацаваная ў згенераваным файле, знікае пры першым перазапісе скрыптом, а кліент, запісаны ў статычны запіс, паказвае на таго, хто трымаў гэты адрас апошнім. Абедзве памылкі застаюцца нябачнымі, пакуль назва не пачне вырашацца на няправільную машыну. На той момант чалавек, які яе адладжвае, мяркуе, што зламаны DNS, а не файл.
Дынамічны шлях: learn-address і пул
OpenVPN ведае прызначэнне, таму дазвольце яму сказаць вам. Гэтыя параметры сервера робяць прызначэнне ўстойлівым і прыдатным для скрыптоў:
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 запускае ваш скрыпт кожны раз, калі адрас дадаецца, абнаўляецца або выдаляецца, і перадае аперацыю, адрас і агульнае імя. Мінімальны скрыпт дадае адзін радок на кліента і выдаляе яго пры выдаленні:
#!/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)
На прыладзе tun другі аргумент — гэта тунельны адрас кліента, таму радок можна выкарыстоўваць напрамую. На прыладзе tap OpenVPN перадае замест гэтага MAC-адрас кліента, бо сегмент tap можа несці пратаколы, акрамя IPv4, і тады трэба знайсці адрас у файле пула па агульным імені, перш чым нешта запісваць.
Будзьце дакладнымі адносна таго, чым з'яўляецца згенераваны файл: здымак таго, хто падключаны прама зараз. Назвы знікаюць пры адключэнні, і гэта менавіта тое, што вам патрэбна для ноўтбукаў, якія перамяшчаюцца паміж сеткамі, і менавіта тое, чаго вы не хочаце для сервера, які працуе ўсю ноч.
Статычны шлях: address= і пашырэнне дамена
Направіце dnsmasq на згенераваны файл замест сістэмнага файла hosts і дайце яму дамен, каб кароткія назвы пашыраліся да поўных:
domain=corp.example
no-hosts
addn-hosts=/etc/openvpn/hosts.lan
listen-address=127.0.0.1,10.8.0.1
bind-interfaces
Калі domain усталяваны, радок выгляду 10.8.0.6 alice адказвае і для alice, і для alice.corp.example. Трымайце listen-address толькі на тунельным шлюзе і loopback, бо рэзалвер, выпадкова апублікаваны на інтэрфейсе LAN, — гэта паслуга, якую вы не збіраліся прапаноўваць.
Службы, якія ніколі не паходзяць з пула, атрымліваюць уласныя запісы. Змясціце іх у асобны drop-in файл у каталогу канфігурацыі дыстрыбутыва, каб абнаўленне пакета не магло іх перазапісаць:
address=/files.corp.example/10.8.0.20
address=/db.corp.example/10.9.0.5
Перадайце рэзалвер, інакш нічога не адбудзецца
Рэзалвер, які ніхто не запытвае, нічога не змяняе. Сервер павінен абвясціць яго:
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"
Кліенты Windows самі прымяняюць абодва параметры. Большасць кліентаў Linux — не: ім патрэбна падтрыманая інтэграцыя з рэзалверам, напрыклад хук update-resolv-conf дыстрыбутыва або апрацоўка DNS у NetworkManager, альбо ручны дамен пошуку і сервер імёнаў. Правярайце фактычны рэзалвер кліента замест таго, каб меркаваць, што push быў выкананы, бо праігнараваны push выглядае гэтак жа, як сервер, які не адказвае.
Праверце на трох узроўнях
Спачатку спытайце сервер напрамую, затым кліента, затым праграму:
dig +short @10.8.0.1 alice.corp.example
getent hosts files.corp.example
Калі прамыя запыты адказваюць, а праграма — не, вінаватая перадача кліенту, а не зона. Калі назва вырашаецца, а злучэнне ўсё яшчэ не ўдаецца, з назвай усё добра, і наступнае, на што трэба зірнуць, — гэта маршрут або фаервол.
Запішыце дзве катэгорыі побач з канфігурацыяй: якія назвы генеруюцца, якія замацаваныя і з якім сертыфікатам кожная павінна супадаць. Наступны чалавек, які дадасць сервер, скапіюе той узор, які знойдзе першым.