Имиња на OpenVPN клиенти во dnsmasq: скрипта или статични записи?

Адресите на клиентите се менуваат, имињата на услугите не. Генерирајте имиња на клиенти од 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 на дистрибуцијата или ракувањето со DNS во NetworkManager, или рачно поставен домен за пребарување и сервер за имиња. Проверете го вистинскиот резолвер на клиентот наместо да претпоставите дека push-от е почитуван, бидејќи игнориран push изгледа исто како сервер што не одговара.

Проверете на три слоја

Прашајте го серверот директно прво, потоа клиент, потоа апликацијата:

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

Ако директните барања одговараат, а апликацијата не, вината е во предавањето кон клиентот, а не во зоната. Ако името се реши, а врската уште не успева, името е во ред и следното што треба да се погледне е маршрутата или ѕидот за заштита.

Запишете ги двете категории до конфигурацијата: кои имиња се генерираат, кои се закачени и со кој сертификат треба да се совпаѓа секое. Следниот човек што ќе додаде сервер ќе го копира првиот шаблон што ќе го најде.

Поврзани статии