Neredeyse her küçük OpenVPN ağ geçidinde iki ad sorunu ortaya çıkar. Bağlı bir dizüstü bilgisayara sertifikasındaki adla ulaşamazsınız ve tünelin arkasındaki hizmetlerin hiç adı yoktur. Tek bir sorun gibi görünürler ve zıt tedaviler gerektirirler, çünkü bir adres her oturumda hareket eder, diğeri etmez. Herhangi bir şeyi düzenlemeden önce ne tür bir ad eklediğinize karar verin.

Ağ geçidine göre değil, ada göre karar verin

Test basittir: bir istemci yeniden bağlandığında bu adres değişiyor mu? Öyleyse ad VPN oturumundan üretilmelidir. Değilse, okuyup gözden geçirebileceğiniz statik bir girdiye aittir.

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

İkisini karıştırmak olağan başarısızlıktır. Üretilen dosyaya sabitlenen bir hizmet, betik onu ilk kez yeniden yazdığında kaybolur ve statik bir girdiye yazılan istemci, o adresi en son elinde tutanı gösterir. Her iki hata da bir ad yanlış makineye çözülene kadar görünmez kalır. O zamana kadar hata ayıklayan kişi DNS'in bozuk olduğunu düşünür, dosyanın değil.

Dinamik yol: learn-address ve havuz

OpenVPN atamayı bilir, bırakın size söylesin. Bu sunucu seçenekleri atamayı kalıcı ve betiklenebilir yapar:

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 bir adres eklendiğinde, güncellendiğinde veya silindiğinde betiğinizi çalıştırır ve işlemi, adresi ve ortak adı iletir. Asgari bir betik her istemci için bir satır ekler ve silindiğinde onu kaldırı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)

Bir tun aygıtında ikinci bağımsız değişken istemcinin tünel adresidir, bu yüzden satır doğrudan kullanılabilir. Bir tap aygıtında OpenVPN bunun yerine istemcinin MAC adresini iletir, çünkü bir tap segmenti IPv4 dışındaki protokolleri de taşıyabilir ve o zaman bir şey yazmadan önce adresi havuz dosyasında ortak ada göre aramanız gerekir.

Üretilen dosyanın ne olduğu konusunda net olun: şu anda kimin bağlı olduğunun anlık görüntüsü. Adlar bağlantı kesildiğinde kaybolur; bu, ağlar arasında gezen dizüstü bilgisayarlar için tam istediğiniz şeydir ve bütün gece açık kalan bir sunucu için tam istemediğiniz şeydir.

Statik yol: address= ve alan adı genişletme

dnsmasq'ı sistemin hosts dosyası yerine üretilen dosyaya yönlendirin ve kısa adların tam nitelikli adlara genişlemesi için ona bir alan adı verin:

domain=corp.example
no-hosts
addn-hosts=/etc/openvpn/hosts.lan
listen-address=127.0.0.1,10.8.0.1
bind-interfaces

domain ayarlandığında, 10.8.0.6 alice gibi bir satır hem alice hem de alice.corp.example için yanıt verir. listen-address seçeneğini yalnızca tünel ağ geçidinde ve loopback'te tutun, çünkü LAN arayüzünde yanlışlıkla yayımlanan bir çözümleyici sunmayı düşünmediğiniz bir hizmettir.

Havuzdan hiç gelmeyen hizmetler kendi girdilerini alır. Bunları dağıtımın yapılandırma dizininde ayrı bir drop-in dosyasına koyun, böylece bir paket yükseltmesi onların üzerine yazamaz:

address=/files.corp.example/10.8.0.20
address=/db.corp.example/10.9.0.5

Çözümleyiciyi devredin, yoksa hiçbir şey olmaz

Kimsenin sormadığı bir çözümleyici hiçbir şeyi değiştirmez. Sunucu onu duyurmalıdır:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Windows istemcileri iki seçeneği de kendileri uygular. Linux istemcilerinin çoğu uygulamaz: dağıtımın update-resolv-conf kancası veya NetworkManager'ın DNS işleyişi gibi desteklenen bir çözümleyici entegrasyonuna ya da elle ayarlanmış bir arama alan adına ve ad sunucusuna ihtiyaçları vardır. push'un uygulandığını varsaymak yerine istemcinin gerçek çözümleyicisini denetleyin, çünkü yok sayılan bir push tam olarak yanıt vermeyen bir sunucu gibi görünür.

Üç katmanda doğrulayın

Önce doğrudan sunucuya sorun, sonra bir istemciye, sonra uygulamaya:

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

Doğrudan sorgular yanıt verip uygulama vermiyorsa hata bölgede değil, istemciye devretmededir. Ad çözülüp bağlantı yine de başarısız oluyorsa ad doğrudur ve sırada rota ya da güvenlik duvarı vardır.

İki kategoriyi yapılandırmanın yanına yazın: hangi adlar üretilir, hangileri sabittir ve her birinin hangi sertifikayla eşleşmesi gerekir. Sunucu ekleyen bir sonraki kişi bulduğu ilk deseni kopyalayacaktır.

İlgili makaleler