Ağ geçidinde OpenVPN DNS: dnsmasq ve güvenlik duvarı kapsamı

dnsmasq'ı tünel adresinde çalıştırın, DNS'e yalnızca istemci havuzundan izin verin, çözümleyiciyi gönderin, ardından doğrudan sorguları ve uygulamanın kendi aramasını test edin.

Tüneldeki istemciler ağ geçidine ulaşır ve ağ geçidi iç çözümleyiciye ulaşır, bu yüzden DNS çalışmalıdır. Ama çalışmıyor, çünkü bunlar iki farklı izindir ve çalışan bir DNS hizmeti üçüncü bir şeydir. Dinleyici, istemcilerin ulaştığı bir adreste bulunmalı, güvenlik duvarı o adrese sorgulara izin vermeli ve istemciye onu kullanması söylenmelidir. Tüneli iki yönde açmak ilk ikisini tesadüfen çözer ve üçüncüsünü yarım bırakır.

Dinleyici iki yönlü yerel bir hizmettir

İçeri doğru, istemci ağ geçidinin tünel adresine 53 numaralı bağlantı noktasından sorgu gönderir. Dışarı doğru, daemon bu sorguyu yapılandırılmış üst akışına iletir. İki yarının da çalışması gerekir ve farklı biçimlerde başarısız olurlar.

İstemcinin bildirdiği zaman aşımı ile ağ geçidinde görülen zaman aşımı aynı arıza değildir.

Tünel adresini bağlayın, her adresi değil

Bu iş için ayrılmış bir dnsmasq örneği açık bir dinleme adresi, başlatmadan sonra tünelin ortaya çıkmasına dayanan bir bağlama kipi ve tek bir açık üst akış gerektirir. Kullandığım en küçük sürüm budur:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic tek tek adresleri bağlar ve tun0 daha sonra ortaya çıktığında baş eder; VPN hizmetinin yeniden başladığı bir makinede bu önemlidir. loopback'i listelemek genel bir dinleyici eklemeden yerel araçları çalışır tutar. no-resolv daemon'ın makinenin çözümleyici yapılandırmasından üst akışları devralmasını engeller, no-hosts ise bu örneğin ağ geçidinin hosts dosyasını yayımlamasını engeller. Bu seçeneklerin hiçbiri kimseye hizmeti sorgulama izni vermez.

İkinci bir daemon başlatmadan önce 53 numaralı bağlantı noktasında zaten bir dinleyici olup olmadığını denetleyin ve yanlış dizindeki başıboş bir dosya yerine dağıtımın yapılandırma sahibini kullanın.

DNS girişine izin verin, tünel geçişine değil

Bunu çalıştıran güvenlik duvarı kuralları tünel arabirimine, istemci havuzuna, ağ geçidi adresine ve 53 numaralı bağlantı noktasına sınırlı yerel giriş kurallarıdır. Protokol başına bir tane olmak üzere iki kural yeterlidir:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS UDP'nin yanı sıra TCP üzerinden de çalışır, bu yüzden yalnızca UDP kuralı büyük yanıtları aralıklı görünen bir biçimde başarısız bırakır. Bunlar ufw route izin değildir ve tun0 üzerinde geniş bir izne dönüşmemelidir. Sıra içerik kadar önemlidir: tun0 adresinden tüm girişi düşüren önceki kural yine kazanır ve son düşüşün altına izin eklemek hiçbir şey yaratmaz.

Ağ geçidi DNS'i artık tasarımın parçasıysa o önceki ilkeyi bilerek gözden geçirin ve nedenini kaydedin.

Üst akış yarısı ayrı bir yoldur

Sorgular ağ geçidinden kendi adresinden üst akış çözümleyicisine doğru çıkar, bu yüzden ağ geçidinin rotası ve o çözümleyiciye yönelik çıkış ilkesi bu değişime izin vermelidir. Bu, istemcileri dinleyiciye ulaştıran kuraldan farklı bir kuraldır ve farklı bir belirtiyle başarısız olur.

Yanıtların çalışması için sınırsız tünel çıkışı eklemeyin; izlenen yanıtların buna gereksinimi yoktur.

Seçeneği gönderin, sonra devri denetleyin

Sunucu, çözümleyiciyi istemcilere gönderilen bir seçenekle duyurabilir. Bu bir seçenektir, işletim sisteminin uyması gereken bir buyruk değildir:

push "dhcp-option DNS 10.90.0.1"

Komut satırı Linux istemcisi, bağlantı yöneticisinin çözümleyici bütünleşmesine gereksinim duyabilir ve yönetilen bir aygıt güncellenmiş bir yönetim profiline gereksinim duyabilir. Bağlandıktan sonra istemcideki etkin çözümleyiciyi doğrulayın, gönderimin uygulandığını varsaymak yerine. İki mekanizma aynı anda DNS ayarlamaya çalıştığında, titreyen çözümleme gibi görünen bir yarış oluşur.

Hedef, istemcinin çözümleyici yapılandırması için tek bir sahiptir ve gönderim genellikle bu sahip yalnızca istemci platformu kabul ettiğinde olur.

Gerçekten kurduğunuzu test edin

Bir özel tam nitelikli adı ve bir izinli dış adı doğrudan tünel adresine karşı, hem UDP hem TCP üzerinden sorgulayın. Ardından uygulamanın olağan arama yoluyla yineleyin.

Doğrudan sorgular çalışıyor ama uygulama hâlâ başarısız oluyorsa arıza sunucuda değil devirde:

  • İstemci gönderilen seçeneği hiçbir zaman uygulamadı.
  • Daha sonra başka bir çözümleyici ayarlandı ve yarışı kazandı.
  • Uygulama kendi çözümleyici kitaplığını ya da önbelleğe alınmış bir yanıtı kullanır.

Onaylanmış VPN yolunun dışındaki bir kaynağın dinleyiciyi hiç kullanamadığını doğrulayarak bitirin. Başarılı çözümleme döndürdüğü adrese yetki vermez, bu yüzden bu iki soruyu ayrı tutun.

İlgili makaleler