OpenVPN-in ötürdüyü DNS nəzərə alınmır: onu hansı komponent tətbiq edir

Jurnal serverin ötürdüyü seçimi göstərir, tunel işləyir, amma daxili adlar yenə uğursuz olur. Həllediciyə birbaşa sorğu cavab verir, yəni server qaydasındadır, buna baxmayaraq hər tətbiq yerli marşrutlaşdırıcıdan soruşmağa davam edir. Müştəriyə çatan şey təklifdir, həlledicidə dəyişiklik deyil və ad həllinə sahib olan komponent Linux, Windows və macOS-da fərqlidir. Seçimi sahibindən ayırdıqdan sonra dörd nasazlıq demək olar ki, hər hesabatı əhatə edir: qarmaq yoxdur, iki rəqabətli qarmaq var, bölünmüş DNS dizayn üzrə işləyir, ya da qısa ad serverə deyil, şəkilçiyə ehtiyac duyur.

Ötürülən seçim təklifdir, quraşdırma deyil

Serverdə iki direktiv niyyəti təsvir edir, nəticəni deyil:

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

Müştəri konfiqurasiya edilmiş həlledici almır. O, mühit dəyişənləri alır, foreign_option_1 və sonrası, hər ötürülən sətir üçün bir dənə, və yerli bir şey onları oxuyub əməliyyat sisteminin həlledici vəziyyətini yenidən yazmalıdır. Linux-da bunu defolt olaraq heç nə etmir, buna görə düzgün server və qoşulmuş müştəri yenə də LAN vasitəsilə həll edə bilir.

İki uc arasında üç mərhələ var: ötürmə getməlidir, müştəri onu göstərməlidir və bir qarmaq onu tətbiq etməlidir. Orta mərhələni müştəri jurnalında, son mərhələni isə həlledici vəziyyətində oxuyun, heç vaxt əksinə yox, çünki jurnal sətri yalnız ilk ikisini sübut edir.

Ötürmənin çatdığını təsdiqləyin və sahibini tapın

Başladıcını adlandırmaqla başlayın: sadəcə openvpn əmr, systemd nüsxəsi, NetworkManager və ya satıcı müştərisi. Bu, qarmağın harada yaşaya biləcəyini müəyyən edir. systemd-resolved işləyən hostda resolvectl status hər keçidi həqiqətən istifadə etdiyi DNS serverləri və axtarış domenləri ilə sadalayır, tunel keçidi isə həmişə tun0.

Əgər ötürülən ünvan jurnalda görünür, amma heç bir keçiddə yoxdursa, inteqrasiya yoxdur. Əgər keçiddə görünür və sorğular yenə başqa yerə çıxırsa, problem hansı sorğuların həmin keçidi seçməsidir. NetworkManager dns=dnsmasq ilə /etc/NetworkManager/NetworkManager.conf faylında yerli yönləndirici işlədir ki, bölünmüş DNS-i qəsdən tətbiq edir: VPN domeni daxilindəki adlar VPN həlledicisinə gedir, qalan hər şey əvvəlki yolunu saxlayır. Bu davranış bütün trafikin köçməsini gözlədiyiniz zaman nasazlıq kimi görünür; əlaqə üzrə parametrləri yoxlayın nmcli connection show "My VPN", burada ipv4.dns və ipv4.dns-search cihazın bildirdiyinin arxasındakı dəyərləri saxlayır, onu nasaz adlandırmazdan əvvəl. Hər sorğu həqiqətən VPN həlledicisinə çatmalıdırsa, silin dns=dnsmasq faylından NetworkManager.conf və NetworkManager-i yenidən başladın, bu ad həllini əlaqə parametrlərinə qaytarır; əks halda bölünmüş DNS-i saxlayın və ötürülən domen siyahısını düzəldin.

Linux: seçimləri həllediciyə verin

Distributiv paketləri bunun üçün qarmaq gətirir və müştəriyə onu işə salmaq icazəsi verilməlidir. systemd-resolved olmayan hostda tipik quruluş:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved ilə köhnə resolv.conf skripti vacib heç nəyi dəyişməyə bilər, çünki stub həlledici keçid üzrə vəziyyət saxlayır. update-systemd-resolved köməkçisi istifadə edilən qarmaq formasını sənədləşdirir up-restart və down-pre, bu, interfeys bir əlaqə cəhdindən daha uzun yaşadıqda önəm kəsb edir. Nə seçsəniz də, vəziyyətə bir komponent sahib olmalıdır. NetworkManager-in yanına əlaqəsiz qarmaq əlavə etmək eyni keçidə iki yazıçı verir və nəticə bundan sonra konfiqurasiyanızdan deyil, sıralamadan asılı olur.

NetworkManager-in ötürülən seçimi tamamilə nəzərə almaması halı da var: server ünvanı əlaqənin IPv4 parametrlərinə daxil edilənə qədər belə idi, sonra həlledici vəziyyəti onun istifadədə olduğunu göstərdi. Skriptləri yenidən yazmazdan əvvəl bunu sınamağa dəyər, çünki problem shell qarmağından tuneli artıq daşıyan əlaqə profilinin içinə keçir.

Windows və macOS müxtəlif hissələri tətbiq edir

Windows müştərisi VPN adapterinin DNS serverlərini həqiqətən qurur, amma Windows yenə metrikaya görə interfeys seçir və qısa adı genişləndirmək üçün hələ də şəkilçiyə ehtiyac duyur. Profili deyil, adapterin vəziyyətini təsdiqləyin:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Ünvan yoxdursa, onu bununla qurun Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, sonra şəkilçini adapterin IPv4 xassələrinə əlavə edin ki, fileserver olsun fileserver.corp.example. Maşın səviyyəsində SearchList altındakı dəyəri Tcpip\Parameters eyni işi görür. Uzun adın həll olub çılpaq adın həll olmadığı yerdə həlledici artıq düzgündür və günah axtarış siyahısındadır. Düzəlişlər ardıcıllıqla: müştərinin şəkilçini öyrənməsi üçün DOMAIN ötürün, həmin şəkilçini adapterin və ya əlaqənin axtarış siyahısına əlavə edin və müvəqqəti tədbir kimi adı orada sabitləyin hosts, ya da Windows-da LMHOSTS ; NetBIOS gəzintisi marşrutlaşdırıcıdan keçmir, buna görə ofis LAN-ında qısa ad tapan yayım tunel müştərisinə heç vaxt çatmır.

block-outside-dns block-outside-dns Windows müştərisinin davranışıdır, daşınan profil sətri deyil və onu Linux və ya macOS profilinə köçürmək bunu orada təkrarlamır. Windows-da ictimai adlar işləyib daxili adlar uğursuz olursa, adapter sırasını Əlavə parametrlər altında ipconfig /all ilə müqayisə edin. macOS-da xidmət üzrə həlledici sırası sistemə aiddir, ona görə hansı domen üçün hansı həlledicinin sorğulandığını görmək üçün scutil --dns istifadə edin və bildirilən hər hansı tək profil düzəlişini ümumi deyil, müştəridən asılı hesab edin.

Eyni noutbukdakı virtual maşın bundan heç nə miras almır. Qonağa daxili domen üçün öz həlledici qeydini verin və ya hipervizardorun NAT-ı sorğularını host vasitəsilə ötürsün, bu isə yalnız host tuneli işləyərkən düzgündür.

Tarixçə üçüncü səbəbdir. Əvvəlki profildən qalan DNS serverləri və ya şəkilçi parametrləri yenidən qoşulmalara dözə bilər, ona görə adapter düzgün görünəndə və axtarışlar yenə uğursuz olanda canlı adapteri Get-VpnConnection ilə müqayisə edin və serverə toxunmazdan əvvəl köhnə qeydi silin və ya üzərinə yazın.

Sorğunun hara getdiyini sübut edin

Bir axtarış zamanı çəkilən tutma mübahisəni həll edir: tcpdump -ni eth0 port 53 fiziki interfeysdə sorğular göstərir, yəni onlar tuneldən kənara çıxır və həlledici heç vaxt dəyişdirilməyib. dig @10.8.0.1 name.corp.example sonra qalan iki halı ayırır. Birbaşa sorğu cavab verirsə, həlledici işləyir və müştəri ondan istifadə etmir; əgər vaxt aşımı olursa, həlledici tuneldən əlçatmazdır və heç bir yerli dəyişiklik kömək etməyəcək.

Əgər hələ də istifadədə olan həlledici provayderin verdiyi həlledicidirsə, tunel trafiki şifrələyir, adlar isə həmin provayderə görünən qalır. Bu, funksional deyil, sızma məsələsidir və eyni tutma buna cavab verir: fiziki interfeysdəki sorğu tuneldən kənarda kiməsə gedir.

Əlçatanlığa VPN hostundakı firewall da daxildir, o, hovuzdan UDP və TCP 53-ə icazə verməlidir. Bağlanmış port tam olaraq pozulmuş ötürməyə bənzəyir, yalnız tunel şəbəkəsinin içindən cavab verən həlledici də belədir. Bir dəfə əlaqəni kəsib yenidən qoşulduqdan sonra tutmanı təkrarlayın, çünki birinci qoşulmada görünüb ikincidə yoxa çıxan parametrlər qarmaqdakı həyat dövrü nasazlığıdır, itkin seçim deyil.

Bir sahib saxlayın və ardıcıllıqla yoxlayın

Təxmin edilən tunel vəziyyətinə əsaslanaraq adapter DNS-ini yenidən yazan skript profilin artıq daşıdığı konfiqurasiyanı təkrarlayır və təxmin ilk dəfə səhv olanda səssizcə uğursuz olur. Əlaqənin öz DNS parametrlərini və ya bir sənədləşdirilmiş qarmağı üstün tutun və hansını seçdiyinizi qeyd edin ki, növbəti adam ikincisini əlavə etməsin.

Dövrəni dörd yoxlama ilə bağlayın: ötürülən ünvan tunel keçidindədir, daxili ad tam kvalifikasiya olunmuş ad kimi həll olunur, eyni ad şəkilçisiz həll olunur və hər ikisi bir yenidən qoşulmadan sonra da doğrudur. Bir tutma dördündən hansının uğursuz olduğunu deyir. OpenVPN 2.6 təlimatı bunları sadalayır dhcp-option və skript direktivlərini platforma qeydləri ilə birgə.