Şlüz üzərində OpenVPN DNS: dnsmasq və firewall əhatəsi

dnsmasq-ı tunel ünvanında işə salın, DNS-ə yalnız müştəri hovuzundan icazə verin, həlledicini push edin, sonra birbaşa sorğuları və tətbiqin öz axtarışını yoxlayın.

Tuneldəki müştərilər şlüzə çata bilir, şlüz də daxili həllediciyə çata bilir, ona görə DNS işləməlidir. Amma işləmir, çünki bunlar iki fərqli icazədir və işlək DNS xidməti üçüncü şeydir. Dinləyici müştərilərin çata bildiyi ünvanda mövcud olmalı, firewall həmin ünvana sorğulara icazə verməli və müştəriyə ondan istifadə etməsi deyilməlidir. Tuneli hər iki istiqamətdə açmaq ilk ikisini təsadüfən həll edir və üçüncünü yarımçıq qoyur.

Dinləyici iki istiqamətli yerli xidmətdir

Daxil olan istiqamətdə müştəri şlüzün tunel ünvanına 53 portuna sorğu göndərir. Çıxan istiqamətdə demon həmin sorğunu konfiqurasiya edilmiş yuxarı axına ötürür. Hər iki yarı işləməlidir və onlar fərqli şəkildə sıradan çıxır.

Müştərinin bildirdiyi timeout ilə şlüzdə görünən timeout eyni nasazlıq deyil.

Tunel ünvanını bağlayın, hər ünvanı yox

Bu iş üçün ayrılmış dnsmasq nüsxəsinə açıq dinləmə ünvanı, başlamadan sonra tunelin görünməsinə dözən bağlama rejimi və bir aydın yuxarı axın lazımdır. İstifadə etdiyim ən kiçik versiya budur:

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

bind-dynamic ayrı-ayrı ünvanları bağlayır və tun0 sonra göründükdə onunla bacarır, bu da VPN xidmətinin yenidən başladığı hostda vacibdir. loopback-in siyahıya salınması yerli alətləri işlək saxlayır və ictimai dinləyici əlavə etmir. no-resolv demonun hostun həlledici konfiqurasiyasından yuxarı axınları miras almasının qarşısını alır, no-hosts isə bu nüsxənin şlüzün hosts faylını yayımlamasının qarşısını alır. Bu seçimlərin heç biri heç kimə xidmətə sorğu vermək icazəsi vermir.

Başlamazdan əvvəl 53 portunda mövcud dinləyicini yoxlayın və yanlış qovluqdakı təsadüfi fayl yerinə distributivin konfiqurasiya sahibindən istifadə edin.

DNS girişinə icazə verin, tunel tranzitinə yox

Bunu işlədən firewall qaydaları tunel interfeysinə, müştəri hovuzuna, şlüz ünvanına və 53 portuna məhdudlaşdırılmış yerli giriş qaydalarıdır. Protokol başına bir qayda, iki qayda kifayətdir:

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 ilə yanaşı TCP üzərindən də işləyir, ona görə yalnız UDP qaydası böyük cavabları fasiləli görünən şəkildə uğursuz qoyur. Bunlar ufw route icazələri deyil və tun0 üzərində geniş icazəyə çevrilməməlidir. Sıra məzmun qədər vacibdir: bütün girişi tun0 ünvanından atan əvvəlki qayda yenə qalib gəlir və son atma altında icazə əlavə etmək heç nə yaratmır.

Əgər şlüz DNS-i artıq dizaynın hissəsidirsə, həmin əvvəlki siyasəti qəsdən yeniləyin və səbəbini qeyd edin.

Yuxarı axın yarısı ayrı yoldur

Sorğular şlüzdən öz ünvanı ilə yuxarı axın həlledicisinə çıxır, ona görə şlüzün marşrutu və həmin həllediciyə doğru çıxış siyasəti mübadiləyə icazə verməlidir. Bu, müştərilərin dinləyiciyə çatmasına imkan verən qaydadan fərqli qaydadır və fərqli simptomla sıradan çıxır.

Cavabların işləməsi üçün məhdudiyyətsiz tunel çıxışı əlavə etməyin; izlənən cavablar buna ehtiyac duymur.

Seçimi push edin, sonra ötürməni yoxlayın

Server həlledicini müştərilərə push edilmiş seçimlə elan edə bilər. Bu seçimdir, əməliyyat sisteminin yerinə yetirməli olduğu əmr deyil:

push "dhcp-option DNS 10.90.0.1"

Linux əmr sətri müştərisi öz bağlantı menecerinin həlledici inteqrasiyasına ehtiyac duya bilər, idarə olunan cihaz isə idarəetmə profilinin yenilənməsini istəyə bilər. Qoşulduqdan sonra müştəridə aktiv həlledicini təsdiqləyin, push-un tətbiq olunduğunu fərz etməyin. İki mexanizm eyni vaxtda DNS qurmağa çalışdıqda, dalğalanan həll kimi görünən yarış yaranır.

Məqsəd müştərinin həlledici konfiqurasiyası üçün bir sahibdir və push adətən o sahib yalnız müştəri platforması razılaşdıqda olur.

Həqiqətən qurduğunuzu yoxlayın

Bir özəl tam kvalifikasiyalı adı və bir icazəli xarici adı birbaşa tunel ünvanına qarşı, həm UDP, həm TCP üzərindən sorğulayın. Sonra tətbiqin adi axtarış yolu ilə təkrarlayın.

Birbaşa sorğular işləyir, tətbiq isə yenə uğursuz olursa, nasazlıq serverdə deyil, ötürmədədir:

  • Müştəri push edilmiş seçimi heç vaxt tətbiq etməyib.
  • Başqa həlledici sonra qurulub və yarışı qazanıb.
  • Tətbiq öz həlledici kitabxanasını və ya keşlənmiş cavabı istifadə edir.

Təsdiqləyərək bitirin ki, təsdiqlənmiş VPN yolu xaricindəki mənbə dinləyicidən heç cür istifadə edə bilməz. Uğurlu həll qaytardığı ünvana səlahiyyət vermir, ona görə bu iki sualı ayrı saxlayın.

Əlaqəli məqalələr