Pi şlüzünün host adı statik marşrutları öz-özünə yeniləyirmi?

Statik marşrutu şlüz adına yönəltmək, ünvan dəyişikliyindən sonra da işləyəcək kimi görünür, amma işləmir. Ad DNS-də yaşayır, marşrut isə müştərinin marşrut cədvəlində rəqəmsal növbəti hop kimi oturur. Pi başqa ünvana keçəndə, köhnə hopu artıq quraşdırmış hər istehlakçı trafiki eyni nömrəyə göndərməyə davam edir. Heç bir həlledici yönləndirmə cədvəlinə bağlanmayıb, ona görə də heç nə o qeydi sizin üçün yenidən yazmır.

DNS cavabı və marşrut fərqli obyektlərdir

Tutaq ki, Pi vpn-gw.lan ünvanına cavab verir və 10.44.0.0/16 şəbəkəsini tunelə yönləndirir. 192.168.30.0/24 şəbəkəsindəki müştərilər ona statik marşrutla çatır. Pi-nin ünvanı 192.168.30.4-dən 192.168.30.11-ə keçəndə qeyd öz TTL-i daxilində ardınca getdi, marşrutlar isə getmədi.

İki baxış asanlıqla gözdən qaça bilən şəkildə ziddiyyət təşkil edir, çünki onları ayrı-ayrılıqda sorğulayanda hər ikisi inandırıcı görünür:

$ ip route get 10.44.0.1
10.44.0.1 via 192.168.30.4 dev eth0 src 192.168.30.20
$ dig +short vpn-gw.lan
192.168.30.11

Yalnız birinci sətir paketlərin hara getdiyini müəyyən edir. İkinci sətir nüvənin heç vaxt vermədiyi suala cavab verir. Bir neçə A qeydi olan bir qeyd də ehtiyat plan siyasətinə çevrilmir, çünki hər ünvan yenə də o seqmentdə işlək növbəti hop olmalıdır.

Komanda bitdikdən sonra cədvəldə nə qalır

Linux marşrutu burada vacib olan iki şeyi qeyd edir: protokol ünvanı kimi növbəti hop, və indeks nömrəsi kimi çıxış interfeysi. rtnetlink marşrut atributları o ilk sahəni RTA_GATEWAY adlandırır və orada baytlar saxlanılır. Qeyd yerinə oturduqdan sonra ona heç bir TTL bağlanmır və heç bir fon axtarışı onu təzələmir.

Buna görə ip route add 10.44.0.0/16 via vpn-gw.lan işləyirmiş kimi görünə bilər. Alət komanda işləyərkən adı həll edir, nəticədə çıxan ünvanı yazır və adı tamamilə unudur. Sonra ip route show 10.44.0.0/16 işlədin və geriyə hərfi ünvan alırsınız.

Bu davranışı tuneli günahlandırmazdan əvvəl bilməyə dəyər.

Adı sizin üçün həll edən alətlər və bunun nə vaxt baş verdiyi

Bəzi marşrutlaşdırıcılar və firewall-lar həqiqətən marşrut və ya şlüz sahəsində host adlarını qəbul edir. Vacib olan həllin nə vaxt baş verdiyidir. Cihaz adı yalnız konfiqurasiyanı tətbiq edərkən həll edirsə, saxlanan qeyd yazılmış ünvan qədər statikdir və sonrakı ünvan dəyişikliyi başqa bir tətbiq tələb edir. Sahənin ad qəbul etməsi yenilənmə barədə sizə heç nə demir.

İdarə olunan qurğular işi bölməyə meyllidir. DHCP rezervasiyası və ya statik icarə Pi-ni bir ünvanda saxlayır və DNS qeydi sadəcə icarəni izləyir. Hərəkət edən hədəfi izləməyə ehtiyac yoxdur, çünki hədəf hərəkət etmir.

Nəzarət olunan yeniləyici digər qanuni nümunədir və onun sahibi olmalıdır.

Ünvanı bərkidin və ya yeniləyicini özünüz işlədin

Kiçik LAN üçün DHCP serverində rezervasiya ən ucuz həlldir. Dinamik hovuzdan kənar bir ünvan seçin, onu Pi-nin MAC ünvanına bağlayın və növbəti icarə yenilənməsindən sonra ip -4 addr show dev eth0 ilə təsdiqləyin. Sonra müştərilərin növbəti hopunu bir dəfə həmin ünvana yönəldin. Artıq sabit bir şlüzünüz və onu təsvir edən bir qeydiniz var; bu, münasibətin həqiqətən işlədiyi ardıcıllıqdır.

Əgər Pi həqiqətən yerini dəyişməlidirsə, hər müştərini əl ilə redaktə etmək əvəzinə marşrut bərpasını bir yerdə saxlayın. Həll edən, müqayisə edən və əvəz edən qısa bir skript addımı təkrarlana bilən etmək üçün kifayətdir:

new=$(dig +short vpn-gw.lan | head -n1)
cur=$(ip route get 10.44.0.1 | awk '{print $3}')
if [ "$new" != "$cur" ]; then
  ip route replace 10.44.0.0/16 via "$new"
fi
ip route get 10.44.0.1

Son komanda qəbul testidir, çünki nüvənin həqiqətən istifadə edəcəyi şlüzü çap edir. Çap olunan ünvan hələ də köhnədirsə, skript yanlış şəbəkə adlar fəzasında işləyib və ya icazəsi olmayıb, DNS tərəfi isə əlaqəsizdir.

Qayıdış yolunu da yoxlayın. Pi müştəri altşəbəkəsinə necə çatacağını bilməlidir və firewall-u tunel trafikinə icazə verməlidir. Uyğunsuzluğu ört-basdır etmək üçün əlavə edilən standart marşrut adətən əsl boşluğu gizlədir və bir həftə sonra başqa bir şeyi pozur.