dnsmasq ішіндегі OpenVPN клиент атаулары: скрипт пе әлде статикалық жазбалар ма?

Клиент мекенжайлары өзгереді, қызмет атаулары өзгермейді. Клиент атауларын VPN сессиясынан жасаңыз, қызмет атауларын drop-in файлында бекітіңіз, содан кейін клиенттерге оны қолдандырыңыз.

Кез келген шағын OpenVPN қақпасында екі атау мәселесі пайда болады. Қосылған ноутбукке оның сертификатындағы атаумен жете алмайсыз, ал туннель артындағы қызметтердің мүлде атауы жоқ. Олар бір мәселе сияқты көрінеді, бірақ қарама-қарсы шешім қажет, өйткені бір мекенжай әр сессияда қозғалады, екіншісі қозғалмайды. Бірдеңені өңдеу алдында қандай атау түрін қосып жатқаныңызды шешіңіз.

Қақпа бойынша емес, атау бойынша шешіңіз

Сынақ қарапайым: клиент қайта қосылғанда бұл мекенжай өзгере ме? Егер иә болса, атау VPN сессиясынан жасалуы керек. Егер жоқ болса, ол оқып, қарап шығуға болатын статикалық жазбаға жатады.

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

Оларды араластыру — әдеттегі сәтсіздік. Жасалған файлға бекітілген қызмет скрипт оны бірінші рет қайта жазғанда жоғалады, ал статикалық жазбаға жазылған клиент бұл мекенжайды соңғы рет ұстаған адамды көрсетеді. Екі қате де атау қате машинаға шешілгенше көрінбейді. Сол кезде жөндеуші 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 ілгегі немесе NetworkManager-дің DNS өңдеуі, немесе қолмен орнатылған іздеу домені мен атау сервері. push орындалды деп болжаудың орнына клиенттің нақты резолверін тексеріңіз, өйткені еленбеген push жауап бермейтін серверге дәл ұқсайды.

Үш деңгейде тексеріңіз

Алдымен серверден тікелей сұраңыз, содан кейін клиенттен, содан кейін қосымшадан:

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

Тікелей сұраулар жауап беріп, қосымша бермесе, кінә клиентке тапсыруда, аймақта емес. Атау шешіліп, байланыс әлі де сәтсіз болса, атау дұрыс, келесі қарайтын нәрсе — маршрут немесе фаервол.

Екі санатты конфигурацияның қасына жазып қойыңыз: қай атаулар жасалады, қайсысы бекітілген және әрқайсысы қай сертификатқа сәйкес келуі керек. Келесі сервер қосатын адам бірінші тапқан үлгіні көшіреді.

Қатысты мақалалар