openfortivpn DNS-i yenə üzərinə yazır? Əsl sahibi tapın

Bağlantını qalxdığı andan izləyin: müştəri autentifikasiya edir, pppd razılaşır, sonra nə isə əməliyyat sisteminə DNS parametrlərini yazır. Əgər yalnız VPN-in sizin həlledicinizi dəyişdiyini bilirsinizsə, hələ bilmirsiniz ki, bu mərhələlərdən hansı bunu edib. Onlardan ikisi bunu edə bilər və sənədləşdirilmiş pppd inteqrasiyasından istifadə edən müştəridə onlar tək bir iştirakçı kimi görünəcək qədər bir-birinə yaxın işləyir. Yazıcını adlandırmaq birinci addımdır; onun əvəzedicisini seçmək ikincidir və bu, öz uğursuzluq rejimləri olan ayrı bir qərardır.

Aşağıdakı ardıcıllıq müştərini bayıra doğru izləyir: bağlantı nəyi dəyişdi, hansı açar hansı yazıcını susdurur, kimin işi ələ almaqdır və nəticənin yenidən qoşulmadan sonra da qaldığını necə təsdiqləmək olar. Hər mərhələ fərqli iz qoyur və ötürmənin həqiqətən baş verib-vermədiyini sizə məhz həmin iz deyir.

Bağlantının həqiqətən nəyi dəyişdiyindən başlayın

Adi əmrinizlə bir dəfə qoşulun və həlli əvvəl və sonra müqayisə edin. systemd-resolved işlədən Linux hostunda resolvectl status hər bağlantı üzrə DNS serverlərini və axtarış domenlərini çap edir və öz serverlərini daşıyan yeni tun və ya ppp bağlantısı müştəri tərəfində yeniləmənin barmaq izidir. macOS-da scutil --dns həlledici konfiqurasiyasını tətbiqlərin ona müraciət etdiyi sıra ilə göstərir.

Bunu dəyişməsini gözlədiyiniz fayl ilə müqayisə edin. Bağlantıya bağlı görünüşdəki qeyd və yenidən yazılmış /etc/resolv.conf iki fərqli nəticədir və ikincisi tamamilə başqa bir şeyin idarə etdiyi simvolik keçid ola bilər. Həlledici ünvanını, axtarış domenlərini və interfeys adını eyni anda qeyd edin; onlardan hər hansı birindəki dəyişiklik fərqli bir yazıcıya işarə edir. Bu baza olmadan hər sonrakı düzəliş üç komponentdən hansının tərpəndiyi barədə təxmindir.

İki açar və hər birinin susdurduğu yazıcı

openfortivpn idarə edə bildiyi hər iki yazıcını söndürən opsiya fraqmentini sənədləşdirir və hər açarın təlimatın eyni parametr kimi qəbul etdiyi tam yazılı ekvivalenti var.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns müştərinin şlüzdən öyrəndiyi DNS serverlərini tətbiq etməsini dayandırır, --pppd-no-peerdns isə pppd-nin peer DNS-i sistemə ötürməsini dayandırır. Yuxarı axın təlimatı xəbərdarlıq edir ki, PPP DNS yeniləmələri müştərinin öz DNS yeniləmələri ilə yarışa bilər, buna görə də hər iki açar fraqmentə aiddir, heç biri kifayət hesab edilməməlidir.

Heç bir açar əvəzedici həlledici adlandırmır və heç biri şəbəkə menecerinin, DHCP müştərisinin və ya ayrı VPN inteqrasiyasının sonradan həll yazmasının qarşısını almır. İki yazıcını susdurmaq sahəni sahiblənmiş deyil, açıq qoyur. Əgər üçüncü komponent artıq DNS-i idarə edirsə, fraqment müşahidə edə bildiyiniz heç nəyi dəyişmir; əgər heç nə idarə etmirsə, siz sadəcə özəl ad həllinin yeganə mənbəyini silmisiniz. Bu, yalnız əvəzedici sahib əvvəlcə seçilib təkbaşına sınaqdan keçirildikdə etibarlı bir tənzimləmədir.

Nəyisə söndürməzdən əvvəl sahibi seçin

İş adları üzrə sorğulara kimin cavab verdiyini əvvəlcə qərar verin, çünki bu seçim sonrakı hər şeyi məhdudlaşdırır. Mövcud həlledicini saxlamaq özəl zonanın müştərinin oturduğu yerdən artıq əlçatan olması deməkdir və ofis daxilindəki özəl həlledici tunelin qalxmasına davam edən marşruta ehtiyac duyur. Hər sorğunu bir daxili xidmətə göndərmək daha kəskin uğursuzluq rejimi olan üçüncü siyasətdir: o xidmət əlçatmaz olduqda, ictimai adlar özəl adlarla birlikdə uğursuz olur.

Marşrut sahibliyi qəsdən ayrı qalır. Marşrut opsiyaları DNS-i dəyişdiyiniz üçün tələb olunmur və əvəzedici quraşdırmadan marşrut quraşdırılmasını söndürmək yenicə seçdiyiniz həlledicini əlçatmaz edə bilər. Marşrut cədvəlində məhz həlledici ünvanını yoxlayın, təsadüfən sınaqdan keçirdiyiniz tətbiq alt şəbəkəsini yox.

Həlli fayl üzrə deyil, bağlantı üzrə yoxlayın

Tək bir /etc/resolv.conf skoplu və ya domen üzrə həlli olan hostda tətbiqlərin həqiqətən nə istifadə etdiyinin inventarı deyil, ona görə həlledici vəziyyətini platformanın onu açdığı kimi oxuyun.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

Bağlantı qalxdıqdan sonra bir özəl ad və bir ictimai ad sorğu edin və hər birinə hansı bağlantının cavab verdiyini qeyd edin. VPN bağlantısı domen üzrə axtarış siyahısı daşıdıqda, özəl ad düzgün həll oluna bilər, ictimai ad isə hələ də yerli həllediciyə gedir və bu bölünmə nasazlıq deyil, dizaynın işləməsidir. Özəl sorğu uğursuz olarsa, DNS-ə yenidən toxunmazdan əvvəl həllediciyə gedən marşrutu yoxlayın; o uğurlu olduğu halda tətbiq yenə uğursuz olursa, tətbiq özünün keşlənmiş və ya ayrıca konfiqurasiya edilmiş həlledicisini oxuyur ola bilər.

Yenidən qoşulun və ayrılmış vəziyyəti təsdiqləyin

Bağlantını aşağı salın və hər iki sorğunu təkrarlayın. Seçilmiş sahibin quraşdırdığı şeyi həmin sahib silməli və ya bərpa etməlidir, sizin susdurduğunuz müştəri onu qoyub getməməlidir. Tuneldən daha uzun yaşayan köhnəlmiş bağlantı qeydi özəl sorğuları artıq əlçatmaz olan ünvana göndərməyə davam edir.

Sonra yenidən qoşulun və eyni üç dəyəri yenidən oxuyun: həlledici ünvanı, axtarış domenləri, interfeys.

Onlar yazdığınız siyasətə uyğun gəlirsə, ötürmə tamamlanıb və VPN müştərisi artıq yazıcılardan biri deyil. Bağlantı qurulduqdan bir neçə saniyə sonra dəyər geri sürüşürsə, başqa bir şey hələ də konfiqurasiya tətbiq edir və növbəti addım başqa bayraq əlavə etmək deyil, həmin komponenti müəyyən etməkdir. İstədiyiniz son vəziyyət hadisəsizdir: bir sahib, bir sənədləşdirilmiş siyasət və tunel mövcud olmazdan əvvəl necə həll edirdisə, tam eyni şəkildə həll edən ayrılmış host.