dnsmasq-da OpenVPN müştəri adları: skript, yoxsa statik?
Müştəri ünvanları dəyişir, xidmət adları isə yox. Müştəri adlarını VPN sessiyasından yaradın, xidmət adlarını drop-in faylında bərkidin, sonra müştəriləri ondan istifadə etdirin.
Demək olar ki, hər kiçik OpenVPN şlüzunda iki ad problemi ortaya çıxır. Sertifikatındakı adla qoşulmuş noutbuka çata bilmirsiniz, tunelin arxasındakı xidmətlərin isə heç adı yoxdur. Onlar bir problem kimi görünür və əks müalicə tələb edir, çünki ünvanlardan biri hər sessiya ilə dəyişir, digəri isə dəyişmir. Nəyisə redaktə etməzdən əvvəl hansı növ ad əlavə etdiyinizə qərar verin.
Şlüz üzrə deyil, ad üzrə qərar verin
Test sadədir: müştəri yenidən qoşulanda bu ünvan dəyişirmi? Cavab bəlidirsə, ad VPN sessiyasından yaradılmalıdır. Cavab xeyirdirsə, o, oxuya və nəzərdən keçirə biləcəyiniz statik qeydə aiddir.
| 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 |
Onları qarışdırmaq adi uğursuzluqdur. Yaradılmış faylda bərkidilmiş xidmət skript onu ilk dəfə yenidən yazanda yox olur, statik qeydə yazılmış müştəri isə o ünvanı sonuncu dəfə tutanı göstərir. Hər iki səhv ad yanlış maşına çevrilənə qədər görünməz qalır. O vaxta qədər onu sazlayan şəxs DNS-in xarab olduğunu güman edir, faylın yox.
Dinamik yol: learn-address və hovuz
OpenVPN təyinatı bilir, qoy sizə desin. Bu server seçimləri təyinatı davamlı və skriptlə idarə olunan edir:
client-config-dir /etc/openvpn/ccd
ifconfig-pool-persist /etc/openvpn/ip-pool 60
script-security 2
learn-address /etc/openvpn/learn-address.shlearn-address hər dəfə ünvan əlavə edildikdə, yeniləndikdə və ya silindikdə skriptinizi işə salır və əməliyyatı, ünvanı və ümumi adı ötürür. Minimal skript hər müştəri üçün bir sətir əlavə edir və silinəndə onu çıxarır:
#!/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 cihazında ikinci arqument müştərinin tunel ünvanıdır, ona görə sətir birbaşa istifadə oluna bilər. tap cihazında isə OpenVPN bunun əvəzinə müştərinin MAC ünvanını ötürür, çünki tap seqmenti IPv4-dən başqa protokollar da daşıya bilər, və o zaman nəyisə yazmazdan əvvəl ünvanı hovuz faylında ümumi ada görə axtarmalısınız.
Yaradılmış faylın nə olduğunu aydın bilin: hazırda kimin qoşulu olduğunun anlıq görüntüsü. Adlar bağlantı kəsiləndə yox olur, bu da şəbəkələr arasında hərəkət edən noutbuklar üçün tam istədiyiniz şeydir və bütün gecə işləyən server üçün tam istəmədiyiniz şeydir.
Statik yol: address= və domen genişlənməsi
dnsmasq-ı sistemin hosts faylı yerinə yaradılmış fayla yönəldin və ona domen verin ki, qısa adlar tam kvalifikasiyalı adlara genişlənsin:
domain=corp.example
no-hosts
addn-hosts=/etc/openvpn/hosts.lan
listen-address=127.0.0.1,10.8.0.1
bind-interfacesdomain təyin edildikdə, 10.8.0.6 alice kimi bir sətir həm alice, həm də alice.corp.example üçün cavab verir. listen-address parametrini tunel şlüzü və loopback ilə məhdudlaşdırın, çünki LAN interfeysində təsadüfən yayımlanan rezolver təklif etmək istəmədiyiniz bir xidmətdir.
Hovuzdan heç vaxt gəlməyən xidmətlər öz qeydlərini alır. Onları paylanmanın konfiqurasiya qovluğunda ayrı bir drop-in faylına qoyun ki, paket yeniləməsi onların üzərinə yaza bilməsin:
address=/files.corp.example/10.8.0.20
address=/db.corp.example/10.9.0.5Rezolveri təhvil verin, yoxsa heç nə olmayacaq
Heç kimin sorğu göndərmədiyi rezolver heç nəyi dəyişmir. Server onu elan etməlidir:
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"Windows müştəriləri hər iki seçimi özləri tətbiq edir. Linux müştərilərinin çoxu etmir: onlara dəstəklənən rezolver inteqrasiyası lazımdır, məsələn paylanmanın update-resolv-conf qarmağı və ya NetworkManager-in DNS idarəetməsi, yaxud əl ilə axtarış domeni və ad serveri. Push-un yerinə yetirildiyini güman etmək yerinə müştərinin faktiki rezolverini yoxlayın, çünki nəzərə alınmayan push cavab verməyən server kimi görünür.
Üç qatda yoxlayın
Əvvəlcə birbaşa serverdən soruşun, sonra müştəridən, sonra tətbiqdən:
dig +short @10.8.0.1 alice.corp.example
getent hosts files.corp.exampleBirbaşa sorğular cavab verir və tətbiq vermirsə, qüsur zonada deyil, müştəri ötürülməsindədir. Ad həll olunur və bağlantı hələ də uğursuz olursa, ad qaydasındadır və növbəti baxılacaq şey marşrut və ya firewall-dır.
İki kateqoriyanı konfiqurasiyanın yanında yazın: hansı adlar yaradılır, hansılar bərkidilir və hər birinin hansı sertifikatla uyğunlaşmalı olduğu. Server əlavə edəcək növbəti şəxs ilk tapdığı nümunəni kopyalayacaq.