Niyə təsdiqlənmiş Tailscale subnet marşrutu hələ də vaxt aşımına uğrayır

İnzibati konsolda təsdiq son addım kimi görünür, amma deyil. Əvvəlcə tətbiq vaxt aşımına uğrayır, yalnız sonra marşrutlaşdırıcının onlayn və marşrutun təsdiqlənmiş olduğunu görürsünüz. Təsdiq paylama addımıdır, nə icazə, nə də yönləndirmə zəmanətidir. Paketin subnet marşrutlaşdırıcısı arxasındakı hosta çatması üçün dörd mərhələ uyğunlaşmalıdır və hər biri növbəti uğursuz olarkən uğurlu ola bilər. Onları sıra ilə işləyin və özünü doğrultmayan ilk mərhələdə dayanın.

Dörd mərhələ, bir uğursuzluq

Marşrutlaşdırıcı prefiksi elan edir, tailnet bu elanı təsdiqləyir, müştəri aldığı marşrutu qəbul edir və giriş siyasəti konkret bağlantıya icazə verir. Bunlar üç fərqli komponentin verdiyi dörd ayrı qərardır. Buna görə təsdiqlənmiş marşrut yalnız şəbəkənin artıq tailnet-in marşrut cədvəlinin hissəsi olduğunu bildirir.

Dördüncü mərhələ ən çox atlanan mərhələdir, çünki ilk üçü görünən vəziyyət yaradır. Marşrutlaşdırıcının öz tailnet ünvanını əhatə edən icazə onun arxasındakı şəxsi subnete avtomatik aid deyil. Bunlar fərqli təyinat yerləridir və siyasət hər təyinat üzrə qiymətləndirilir.

Linuxda üçüncü mərhələnin insanları təəccübləndirən defolt davranışı da var: subnet marşrutlarının qəbulu könüllüdür. Bir neçə GUI müştərisi elan edilmiş marşrutları defolt olaraq qəbul edir, buna görə qarışıq park bir maşının uğursuzluğunu göstərə bilər, halbuki qalanları işləyir.

Platformanı fərz etmək əvəzinə uğursuz maşında tərcihi təsdiqləyin. İşləyən maşınlarda marşrut heç vaxt çatışmayan hissə deyildi, qoy onlar tailnet tərəfinin sağlam olduğunu sübut etsin. Tailscale-in subnet marşrutlaşdırıcıları sənədi təsdiqi, müştərinin marşrut qəbulunu və siyasət mərhələsini əhatə edir.

Marşrutu müştərinin işlədiyi yerdə yoxlayın

Marşrutlaşdırıcıda deyil, uğursuz olan müştəridə başlayın. Marşrutun mövcud olduğunu və müştəri tərcihinin ümumiyyətlə marşrut qəbuluna icazə verdiyini təsdiqləyin.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

Birinci əmr peer siyahısını və subnet marşrutlaşdırıcısının əlçatan olub-olmadığını göstərir, ikincisi marşrut qəbulu bayrağı daxil olmaqla müştərinin tərcihlərini çap edir, üçüncüsü isə nüvədən subnete real host üçün hansı interfeysi istifadə edəcəyini soruşur. Əgər sonuncu əmr Tailscale interfeysi əvəzinə fiziki interfeysi göstərirsə, marşrut heç vaxt cədvələ düşməyib. Çatışmayan marşrut müştəri tərəfindəki problemdir, təsdiq problemi deyil. Siyasətə baxmadan əvvəl onu düzəldin.

Linuxda marşrutları qəbul etmək üçün bayrağın qoyulduğunu fərz etmək əvəzinə onunla yenidən qoşulun: tailscale up --accept-routes. Fərqli bayraqlarla qoşulmuş müştəri onları dəyişdirilənə qədər saxlayır, buna görə başqa birini əlavə etməzdən əvvəl cari tərcihi yoxlayın. Dəyişiklikdən sonra birinci əmri yenidən işlətmək marşrutu cədvəldə göstərməlidir.

Yönləndirməni və qayıdış yolunu sübut edin

Təsdiq marşrutlaşdırıcını paketləri yönləndirmək üçün qurmur və cavabı təşkil etmir. Hər ikisi marşrutlaşdırıcının LAN tərəfində host səviyyəli məsələlərdir. Onları müştəridə deyil, marşrutlaşdırıcıda sınayın.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

Birinci əmr 1 bildirməlidir, əks halda nüvə yönləndirilən paketi atır. İkincisi subnet marşrutu maskaradının mənbəni yenidən yazıb-yazmadığını göstərir, bu defolt davranışdır və adətən istədiyinizdir. Üçüncüsü sorğunun təyinat yerinə çatıb-çatmadığını və nəyinsə qayıdıb-qayıtmadığını göstərir; cavabsız sorğu qayıdış yolu problemidir, təsdiq problemi deyil. Hər hansı birini dəyişməzdən əvvəl üç nəticəni birlikdə oxuyun.

Maskarad söndürülübsə, təyinat şəbəkəsinə tailnet ünvanlarına qayıdan marşrut lazımdır və aralarındakı hər hop bunu bilməlidir. Maskaradı yenidən açmaq tək xidmət üçün daha sürətli həlldir, lakin orijinal müştəri ünvanı təyinatdan gizlədilir. Bu güzəşt təyinat mənbə ünvanlarını audit üçün qeyd etdikdə vacibdir, buna görə hadisə zamanı bayrağı çevirmək əvəzinə bunu qəsdən qərarlaşdırın. Hansı seçimi etdiyinizi sənədləşdirin, çünki növbəti şəxs iki davranışdan yalnız birini görəcək.

Resurs üçün giriş qaydasını oxuyun

Marşrut mövcud və yönləndirmə sübut edilmişsə, qalan şübhəli siyasətdir. Bağlantıya icazə verməli olan icazəni oxuyun və yalnız mənbəyini deyil, təyinatını da yoxlayın. Müştərinin öz kimliyi də siyasət seçicisinə uyğun olmalıdır, buna görə onu uğursuz olan maşının özündən götürün.

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

Status çıxışı müştərinin öz ünvanlarını və görə bildiyi peer-ləri müəyyən edir, siyasət mənbə seçicisi də bunlara uyğun olmalıdır. tailscale ping tailnet yolunu subnet marşrutlaşdırıcısının özünə sübut edir; o, peer adlarını və tailnet ünvanlarını həll edir, elan edilmiş subnet daxilindəki hostları deyil. Üçüncü əmr subnet marşrutu ilə adi ICMP əks-sədası göndərir, buna görə nəticəsi marşrutlaşdırıcını deyil, təyinatı təsvir edir. Tailnet səviyyəsində rədd adətən rədd kimi qayıdır, çıxıb heç qayıtmayan paket isə vaxt aşımına uğrayır.

Uğursuz ad uğursuz ünvandan fərqli sualdır; marşrutu günahlandırmadan əvvəl hostu birbaşa həll edin. İcazəni bütün subnetə deyil, faktiki resurs tələbinə görə yazın. Bir tətbiqin işləməsi üçün bütöv /24-ü açmaq dar tələbin sonradan heç kimin silməyə cürət etmədiyi geniş icazəyə çevrilmə üsuludur.

Məqsəd şəxsi subnet deyil, internet çıxışı idisə, düzgün komponent subnet marşrutlaşdırıcısı deyil, çıxış qovşağıdır və siyasət ilə marşrutlaşdırma da buna uyğun fərqlənir. İcazəni genişlətməzdən əvvəl bu qərarı yoxlayın. Çıxış qovşağı defolt marşrutu dəyişir; subnet marşrutlaşdırıcısı yalnız prefiks elan edir.