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

Түз суроолор жооп берип, колдонмо бербесе, күнөө кардарга өткөрүп берүүдө, аймакта эмес. Ат чечилип, байланыш дагы эле ийгиликсиз болсо, ат жакшы жана кийинки кароо керек нерсе — маршрут же фаервол.

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

Тектеш макалалар