Hansı keçid cavab verir: split-tunnel VPN DNS üçün marşrutlaşdırma domenləri

Adi gəzintini yerli keçiddə saxlayın, şirkət adları isə tunelin təqdim etdiyi DNS serveri vasitəsilə həll olunsun. VPN-in standart marşrutunu söndürmək sizə birinci yarısını verir, ikinci yarısını isə qurulmamış qoyur. Bundan sonra gələn itkin ayar, mənasını dəyişən durğu işarəsi və hansı keçidin həqiqətən cavab verdiyini göstərən tək əmrdir. NetworkManager və systemd-resolved bütün boyu fərz olunur, çünki çaşqınlıq adətən məhz bu cütlükdə başlayır.

Birinci addım: marşrutu həlledicidən ayırın

ipv4.never-default marşrut sualına cavab verir və NetworkManager-in bu bağlantını bütün IPv4 trafiki üçün yol kimi quraşdırmasını dayandırır. DNS marşrutlaşdırma domeni başqa suala cavab verir: uyğun şəkilçi üçün sorğunu hansı keçidin ad serverləri alır. Heç biri digərini şərtləndirmir və profil illər boyu birini daşıyıb digərini itirə bilər. Yalnız-marşrut o deməkdir ki, tunel şirkət alt şəbəkələrini daşıyır və onun həlledicisi şirkət adlarına cavab verir, qalan hər şey isə toxunulmaz qalır.

Yalnız marşrut xassəsini qursanız, daxili adlar uğursuz olur, adətən pozulmuş tunel kimi oxunan fasilə ilə. Yalnız domeni qursanız, maşındakı hər qısa ada səssizcə axtarış şəkilçisi əlavə etmiş olursunuz. Hər iki səhv bileti VPN serverinə yönəldir, halbuki səhv olan hissə nadir hallarda oradadır.

İkinci addım: profilə yalnız-marşrut domeni əlavə edin

Tutaq ki, bağlantının adı corp-vpn-dir, şirkət şəkilçisi internal.example-dır və tunelin həlledicisi artıq əlçatandır. Əvvəlcə cari dəyərləri oxuyun, çünki aşağıdakı əmrlər artıq girişlər daşıya bilən xassələri dəyişir.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Öz bağlantı adınızı və şəkilçinizi qoyun, çünki yuxarıdakı dəyərlər nümunədir. Artı işarəsi göründüyündən daha vacibdir: onunla dəyər mövcud siyahıya əlavə olunur, onsuz isə xassə əvəz olunur və dünən işləyən profildən əlaqəsiz domenlər yox olur. Tilde üslubu deyil, davranışı dəyişir və aşağıdakı paraqraf onun nə seçdiyini əhatə edir. Oxumanı yazmadan əvvəl saxlayın ki, əvəzləmə forması sizi heç vaxt təəccübləndirməsin.

Başdakı tilde yalnız-marşrut domenini işarələyir, beləliklə uyğun sorğular bu keçidin serverlərinə gedir və şəkilçi qısa adlara əlavə olunmur. Tildeni götürsəniz, eyni sətir axtarış şəkilçisinə də çevrilir, bu isə insanların nadir hallarda nəzərdə tutduğu fərqli nəticədir. Yuxarıdakı hər iki ayar IPv4-dür, ona görə ikili stek profili ipv6.never-default və ipv6.dns-search-də eyni marşrutlaşdırma domenini tələb edir, əks halda IPv6 tərəfi standart marşrutu işlətməyə davam edir və daxili adlar orada uğursuz olur.

Üçüncü addım: resolvectl-dən hansı keçidin cavab verdiyini soruşun

resolvectl status əmrini işlədin və hər keçidin DNS serverlərini və domenlərini oxuyun, sonra sorğu etməyə icazəniz olan real daxili ad üzərində resolvectl query host.internal.example işlədin. İkinci əmr marşrutlaşdırma domeninin işini gördüyünə dair yeganə birbaşa sübutdur, çünki cavab verən keçidin adını çəkir. Tək status siyahısı konfiqurasiyanı sübut edir; sorğu isə həlli sübut edir.

systemd-resolved ən yaxşı uyğun gələn marşrutlaşdırma domenini seçir, ona görə başqa keçiddəki daha konkret domen yarışı yenə qazana bilər. Sorğu gözləmədiyiniz keçiddən qayıdırsa, VPN-in DNS serverinə toxunmazdan əvvəl domen siyahılarını oxuyun. ~. kök domeni hər şeyə uyğun gəlir və əgər artıq varsa, sizin konkret domeniniz öz adları üçün yenə qazanır, keçid isə soruşduğunuzdan qat-qat çoxuna cavab verir. Məqsəd yalnız şirkət adları idisə, o kök girişini silin və ya daraldın.

VPN keçidi ümumiyyətlə DNS serveri göstərmirsə, müştəri heç vaxt birini qeydiyyata almayıb. Arxasında server olmayan marşrutlaşdırma domeni itkin domenlə fərqli şəkildə uğursuz olur, ona görə əvvəlcə qeydiyyatı düzəldin.

Dördüncü addım: ad həll olunur, amma xidmət işləmir

Düzgün cavab yalnız həllin işlədiyini sübut edir və tətbiq hələ də aldığı ünvana marşrut lazımdır. Bu marşrut indicə qurduğunuz bölünmüş standartdan sağ çıxmalıdır, ona görə DNS-i yenidən günahlandırmazdan əvvəl onu yoxlayın. Sonra xidmətin portunda əlçatanlığı yoxlayın, çünki fayl paylaşımı və ya kataloq xidməti həlletmə, marşrutlaşdırma və ya autentifikasiya mərhələsində uğursuz olur və hər halda çox oxşar mesajlar verir. Nəticəni bildirərkən bu üç qatı ayrı saxlayın, əks halda növbəti şəxs artıq düzgün olan DNS-i yenidən yoxlayır.

Bu sualla yanaşı dolaşan Samba dəyişikliyi DNS seçiminə deyil, giriş qatına aiddir. Onu ad həlli nasazlığına tətbiq etmək kiçik problemin ikinci bir problem qazanması yoludur.

Beşinci addım: itkin domeni düzəltmək üçün həlledicini əvəz etməyin

Həlledici faylını üzərinə yazan və ya fərqli həlledici meneceri quraşdıran məsləhət başqa bir problemi həll edir. Bunlar öz nasazlıq rejimləri olan sistem inteqrasiyası dəyişiklikləridir və heç biri heç vaxt qurulmamış marşrutlaşdırma domeni əlavə etmir. Maşında ad həllinin hansı komponentə aid olduğunu onu əvəz etməzdən əvvəl müəyyənləşdirin, çünki systemd-resolved ilə NetworkManager masaüstündə bu sahiblik artıq müəyyən edilib. Onunla mübarizə işləyən quruluşun heç kimin təkrarlaya bilmədiyi bir şeyə çevrilməsi yoludur.

İş sırası: tunelin həlledici təqdim etdiyini təsdiqləyin, yalnız-marşrut domenini əlavə edin, profil nəzarətləri ilə yenidən qoşulun, cavab verən keçidi yoxlayın, sonra xidməti öz portunda sınayın. Bu ardıcıllıq ikinci müsahibə olmadan növbəti şəxsə ötürə biləcəyiniz nəticə qoyur.