VPN son nöqtə adı və xüsusi xidmət adı: iki sahib

İki ad eyni filialı təsvir edə və tamamilə fərqli suallara cavab verə bilər. vpn.branch.example uzaq həmkarına VPN son nöqtəsinin harada olduğunu bildirir və hər hansı tunel yaranmazdan əvvəl həll olunmalıdır. inventory.branch.example səlahiyyətli istifadəçiyə xüsusi tətbiqin harada yerləşdiyini bildirir və yalnız tunel qurulduqdan sonra əhəmiyyət daşıyır. Onlardan birini saxlamaq digəri üçün heç nə etmir.

Hər hansı birini sazlamaqdan əvvəl iki qeydi adlandırın

İkisini də sahibləri ilə birlikdə yazın. Son nöqtə üçün ictimai ünvanı kimin yenilədiyini və VPN müştərisinin cavabını necə yenilədiyini qeyd edin. Xidmət üçün xüsusi ünvanın kimə aid olduğunu, qeydin hansı zonada saxlandığını və hansı həlledicilərin onun üçün cavab verməli olduğunu qeyd edin.

Bu qısa siyahı bu sahədə ən çox yayılmış səhv diaqnozun qarşısını alır: tamamilə içində yaşayan qeydi təmir etmək üçün işlək filial tunelini yenidən başlatmaq. Tunel xidmət adı üçün daşıyıcıdır; onun səlahiyyəti deyil.

Dəyişiklik təklif olunanda soruşun: iki qeyddən hansına toxunur. Heç kim cavab verə bilmirsə, dəyişiklik planlaşdırmağa hazır deyil.

Son nöqtə hər hansı tunel yaranmazdan əvvəl həll olunmalıdır

Tutaq ki, filialın internet bağlantısı yeni ictimai ünvan alır. Son nöqtə yeniləyicisi yeni ünvanı dərc edir və uzaq VPN tətbiqi dəyişmiş cavabı oxuya bilməlidir. Həmin cavabı hansı həlledici verirsə, o, tunel olmadan əlçatan olmalıdır, əks halda müştəri yalnız tapa bilmədiyi şeyə qoşulduqdan sonra həll edə biləcəyi adın arxasınca qaçır.

Bu ilkin yükləmə asılılığını açıq deməyə dəyər, çünki bütün daxili həlledicilər VPN-in arxasındadırsa, onu təsadüfən yaratmaq asandır. Son nöqtə axtarışı üçün tuneldən əvvəl yol saxlayın və yeni cavabın dərhal götürüldüyünü güman etmək əvəzinə müştərinin yenidən qoşulma davranışını təsdiqləyin.

Dinamik DNS-in də qeyd yeniləməsinin keçə bilmədiyi hədləri var. Qeydi yeniləmək heç bir firewall portu açmır, NAT xəritəsi yaratmır və həmkarın şəxsiyyətini sübut etmir. Bağlı portu olan dərc edilmiş ünvan düzgün həll edən və yenə də heç nəyə qoşula bilməyən müştəri verir.

Nəhayət, işləyən müştəri yenidən qoşulana qədər keşlənmiş son nöqtədən istifadə etməyə davam edə bilər. Qeydlərinizdə dərci, keşi və yenidən qoşulma siyasətini ayırın ki, köhnəlmiş həmkar pozulmuş yeniləyici ilə qarışdırılmasın.

Xidmət adı tətbiqin harada yerləşdiyini təsvir edir

İndi tutaq ki, tunel sağlam qalır, lakin inventar serveri 172.26.14.20 ünvanından 172.26.14.35 ünvanına keçir. İctimai son nöqtə qeydi təsirlənmir, xüsusi xidmət qeydi isə dəyişməlidir. Həmin xidmət üçün ayrılmış ünvandan və ya statik təyinatdan istifadə bunu daha nadir edir; səlahiyyətli yeniləmə yolu bunun nəzərdə tutulduğu halları həll edir.

Burada iki yeniləmə mexanizmi qarışdırılır. RFC 2136 zonada DNS qeydlərinin əlavə edilməsi və silinməsi üçün protokol müəyyən edir, kommersiya dinamik DNS təminatçısı isə fərqli məqsəd üçün tamamilə fərqli HTTP API təqdim edə bilər. Birinin istifadəsi digərinin mühitinizdə mövcud olduğunu ifadə etmir. Yeniləyici yazmazdan əvvəl zonanızın hansı mexanizmi həqiqətən qəbul etdiyini yoxlayın.

Düzgün xüsusi cavab yalnız ilk şərtdir. Uzaq zəng edənin ondan istifadə etməsi üçün müştəriyə xüsusi zonanı daşıyan həlledici, həmin həllediciyə sorğulara icazə verən siyasət və geri qayıdan ünvan üçün yönləndirmə lazımdır. Müştərinin çata bilmədiyi ünvana həll olunan ad server nasazlığı kimi görünən fasilə yaradır.

İki yolu ayrı-ayrılıqda sınaqdan keçirin

Son nöqtəni tuneldən kənardan, xidməti isə onun içindən yoxlayın və nəticələri iki müstəqil fakt kimi saxlayın:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Birinci sorğu uğursuz olarsa, problem ictimai dərc və ya tuneldən əvvəlki həll yolundadır və heç bir daxili dəyişiklik kömək etməyəcək. İkinci ünvan qaytarır, üçüncü isə tuneldən keçən marşrut göstərmirsə, DNS qatı qaydasındadır, yönləndirmə siyasəti isə deyil.

Hər ünvan dəyişikliyindən sonra cütü işə salın və hansı qeydin yer dəyişdiyini qeyd edin. Yalnız «DNS yeniləndi» deyən təhvil növbəti mühəndisi iki həyat dövründən hansının həqiqətən işlədiyini təxmin etməyə qoyur.