Bölünmüş tunel marşrutları üst-üstə düşəndə: hansı prefiks qalib gəlir

İki bölünmüş tunel profili, iki özəl prefiks və hər ikisinin sahib çıxdığı bir host. Simptom nadir hallarda təmiz nasazlıq olur: xidmət bazar ertəsi işləyir, ikinci müştəri yenidən qoşulduqdan sonra cavab vermir, yenidən başlatmadan sonra yenə işləyir. Müştəriləri hansı sıra ilə qoşduğunuz nəticəni müəyyən etmir, müştərinin interfeysindəki sətirlərin sırası da etmir. Bu yoxlamaları sıra ilə aparın və uyğun gəlməyən ilk yoxlamada dayanın, çünki sonrakılar yalnız əvvəlkilər doğru olduqda məna kəsb edir.

1. Təyinatı və mənbəyi yazın

Uğursuz sorğunun getdiyi dəqiq ünvanla başlayın, host adı ilə və ya tətbiqin adı ilə deyil. Adı bir dəfə həll edin, hər cavabı qeyd edin və uğursuz axının həqiqətən istifadə etdiyi cavabı seçin. Sonra həmin axının yerli ünvanını qeyd edin, çünki mənbə ünvanı hansı siyasət qaydasının uyğun gəldiyini və buna görə də hansı cədvələ baxıldığını dəyişə bilər.

Bir neçə A qeydindən birinə gedən sorğu uğursuz ola bilər, halbuki qardaş ünvan uğur qazanır; bu qeyri-sabit tunel kimi görünür, əslində isə iki fərqli yoldur. Əgər təyinat bir neçə cavabı olan addırsa, hər hansı dəyişiklik etməzdən əvvəl hər cavabı ayrıca yoxlayın.

2. Nüvədən hansı marşrutu seçdiyini soruşun

Marşrut cədvəlini oxuyub cavabı təxmin etməyin. Stekin verdiyi sualı eyni mənbə ünvanı ilə verin: Linux-da ip route get 10.20.4.10 from 10.8.0.2, PowerShell-də Find-NetRoute -RemoteIPAddress 10.20.4.10. Çıxış həqiqətən istifadə olunacaq marşrutu göstərir və bu, çox vaxt cədvəli oxuyarkən gözlədiyiniz marşrut olmur.

Uyğun gələn marşrutlar arasında adətən daha dəqiq prefiks qalib gəlir: hər ikisinin içində olan ünvan üçün /24 /16-nı üstələyir. Bərabər uzunluqlu uyğunluqlar arasında aşağı metrika qalib gəlir və söndürülmüş keçid üzərində quraşdırılmış marşrut atlanır. Eyni /24-ü eyni metrika ilə təqdim edən iki tunel başqa haldır: nüvə hər iki marşrutu saxlayır və onlar arasında seçim edir, buna görə nəticə müştərilərin qoşulma sırasını izləmək əvəzinə dəyişə bilər. Bu, bazar ertəsi işləyir-çərşənbə axşamı uğursuz olur nümunəsini yaradan məhz həmin vəziyyətdir və fərqli sıra ilə yenidən qoşulmaq onu dəyişmir.

3. Siyasət qaydasının axtarışı yönləndirib-yönləndirmədiyini yoxlayın

Marşrut cədvəlinə baxılmazdan əvvəl nüvə öz siyasət qaydalarını gəzir. Qayda müəyyən mənbədən, istifadəçidən və ya firewall işarəsindən gələn trafiki tamamilə başqa cədvələ yönləndirə bilər, buna görə əsas cədvəldəki qalib prefiksə həmin axın üçün heç vaxt baxılmaya bilər. ip rule show onları qiymətləndirmə sırası ilə sadalayır, ip route show table 100 isə seçilmiş cədvəlin həqiqətən nə saxladığını göstərir.

Burada iki tələ var. Boş cədvələ baxan qayda növbəti qaydaya düşən axtarış yaradır, buna görə qayda heç nə etmirmiş kimi görünür. Digəri prioritet nömrəsinin özüdür: qaydalar artan sıra ilə oxunur və daxili dəyərlər 0 local, 32766 main və 32767 default-dur. Nömrəsi 32767-dən aşağı olan qaydaya hər şeyi tutan default qaydasından əvvəl baxılır. Nömrəsi 32767-dən yuxarı olan qayda onun arxasında durur və yalnız əvvəlki heç bir cədvəl cavab vermədikdə ona çatılır; main-dəki adi default marşrut bunun qarşısını alır, buna görə praktikada ona heç vaxt çatılmır və quraşdırılmış görünərkən səssizcə heç nə etmir. Əgər müştəri həm qayda, həm marşrut yazıbsa, hər ikisini yoxlayın və yenidən qoşulmadan sonra yenə yoxlayın, çünki yenidən yazılmış profil fərqli prioritetli ikinci qayda əlavə edə bilər.

4. Marşrut bərabərliyini təkrarlanan ünvan planından ayırın

Bəzən prefiks heç də problem deyil. İki saytın ikisinin də 192.168.1.0/24 istifadə etməsi o deməkdir ki, eyni ünvan iki fərqli hostu göstərir və heç bir marşrut onları ayıra bilməz. İki cavabdan birinə host marşrutu yalnız o vaxta qədər işləyir ki, digər sayt eyni ad üçün cavab verir, sonra istisna səssizcə xətanın özünə çevrilir.

İpucu budur ki, təyinat ünvanı hər iki yolda eynidir və yalnız nəzərdə tutulan sahib fərqlənir. Bu, marşrut düzəlişi deyil, ünvan planı qərarıdır: bir tərəfi yenidən nömrələyin, bir tərəfi tərcümə edən şlüz arxasına qoyun və ya ikinci sayta öz adlarını həll edən vasitəçi ilə çatın. Default marşrutu aşağı salmaq və ya host istisnalarını yığmaq yalnız toqquşmanı başqa yerə köçürür.

5. Həlledicinin marşrutla razılaşdığını təsdiqləyin

Səhv özəl ünvana həll olunan ad marşrut konfliktinin bütün simptomlarını yaradır, səbəblərindən isə heç birini. Hostun aldığı cavabı təyinatın həqiqətən istifadə etdiyi ünvanla müqayisə edin və hansı həlledicinin cavab verdiyini yoxlayın. Əgər tunel həlledici təqdim edirsə, müştəri onu tuneldən istifadə edən axınlar üçün quraşdırmalıdır; etmirsə, host yerli həlledicidən soruşmağa davam edir və o, axtarış domenindən və ya keşlənmiş qeyddən cavab verə bilər.

Həllediciyə birbaşa sorğu göndərin və cavab verən serveri qeyd edin. Qısa TTL ilə keşlənmiş cavab həm də yenidən qoşulmadan sonra ilk sorğunun beşincidən niyə fərqli davrandığını izah edə bilər.

6. Yenidən qoşulun, tətbiq olunmuş vəziyyətə baxın, sonra hər iki axını yoxlayın

Düzəlişdən sonra yenidən qoşulun və profil redaktoruna güvənmək əvəzinə müştərinin həqiqətən nə quraşdırdığına baxın. Qaydaları, cədvəlləri və nəticədə alınan ip route get cavabını yenidən oxuyun. İkinci müştəri qoşularkən öz marşrutunu yenidən quraşdıra və konflikti yenidən yarada bilər, buna görə vəziyyət yoxlaması sonuncu müştəri qoşulduqdan sonra aparılmalıdır, ondan əvvəl deyil.

Bir deyil, iki axını yoxlayın: əvvəllər uğursuz olan sorğu və digər tuneldən istifadə etməli olan resurs. Bütün özəl trafiki bir bağlantıya köçürmək birinci yoxlamanı keçirəcək, ikincini isə pozacaq və bunu yalnız cüt yoxlama aşkar edir. Saxladığınız hər istisnanı təyinat və səbəblə birlikdə qeyd edin ki, növbəti şəxs qəsdən edilmiş host marşrutunu qalıq marşrutdan ayıra bilsin.