İstifadəçi bildirir ki, daxili tətbiq bir maşından işləyir, digərindən isə uğursuz olur, şlüzdən işlətdiyiniz ping isə hər iki halda uğur qazanır. Bərabər məsrəfli bir neçə tunel olduqda bu ziddiyyət deyil. Hər axın öz növbəti hopuna yerləşdirilir, ona görə sizin yoxlamanız və istifadəçinin sessiyası sadəcə fərqli yollardan gedə bilər. Aşağıdakı gedişat heç nəyi dəyişməzdən əvvəl bu seçimi təkrar canlandırır.

Bir ping, bir neçə mümkün yol

Marşrutun eyni məsrəflə birdən çox növbəti hopu olduqda marşrutlaşdırıcı hər paket üçün birini seçməlidir. Əksər tətbiqetmələr paketin sahələrini heşləyir, adətən mənbə və təyinat ünvanlarını protokol və portlarla birlikdə, belə ki cavablar eyni yolda qalsın. Fərqli tətbiqlər, hətta bir tətbiqin fərqli bağlantıları fərqli heşlər yaradır.

Şlüzdən alınan diaqnostikanın bu qədər az sübut etməsinin səbəbi budur. Şlüzün öz yoxlaması öz ünvanlarına və portlarına, deməli öz heşinə malikdir. O, sağlam tunelə düşə bilər, istifadəçi isə pozulmuş tunelə düşməyə davam edir.

Platforma növbəti hopu necə seçir

Seçimi təxmin etmək əvəzinə təkrar canlandırın. Nüvədən soruşun ki, uğursuz sessiya ilə eyni mənbə və təyinat üçün hansı marşrutu istifadə edərdi. Bu axtarış adi təyinat axtarışının nəzərə almadığı sahələri əhatə edir. İşləyən müştəridən də icra edin və iki cavabı müqayisə edin:

ip route get 10.20.5.7 from 10.20.0.14

Daha yeni iproute2 buraxılışları protokolu və təyinat portunu da qəbul edir, bu da heş onları ehtiva etdikdə vacibdir. Həmin çıxışı işləyən müştəridən eyni axtarışla müqayisə edin və fərq çatışmayan sübutunuz olacaq.

ObservationLikely causeFirst check
Ping works, application failsA different flow hash selects another tunnelPer-flow lookup from the client's address
Some users fail, others do notOne tunnel lacks a prefix or selectorCompare both tunnels' installed routes
Fails only at larger sizesTunnels have different effective MTUProbe the same size over each path
Fails after a reconnectStateful asymmetry between pathsSession state on both gateways

Uğursuz axını izləyin, marşrut cədvəlini yox

Marşrut cədvəli hər iki tuneli sadalayır və tərifinə görə düzgün görünür. Sual odur ki, hər tunel seçildikdən sonra paketlə nə edir. Hər ikisinin eyni qorunan prefiksləri, eyni yönləndirmə icazəsini və eyni müştəriyə çatan geri dönüş yolunu daşıdığını yoxlayın.

Ortadakı vəziyyət saxlayan cihazlara diqqət yetirin. Əgər sorğu bir tuneldən çıxıb cavab digərindən qayıdırsa, orijinal axını heç vaxt görməmiş firewall və ya NAT onu atacaq. İki tunel də trafiki düzgün yönləndirir, amma bağlantı yenə də uğursuz olur.

Hər yol üzrə MTU-nu da yoxlayın. Əlavə inkapsulyasiyası olan yol istifadə oluna bilən ölçünü kiçildir və bir tuneldə uğurla gedən ötürmə digərində məhz kiçik olanın qırıldığı ölçüdə dayanır.

Hər dəfə bir yolu müqayisə edin

Dizayn texniki xidmətə icazə verdiyi yerlərdə bir tuneli xidmətdən çıxarın və istifadəçinin tapşırığını təkrarlayın. Əgər nasazlıq yox olarsa, problem çıxardığınız yola aiddir və növbəti addım onun konfiqurasiyasını qonşusu ilə müqayisə etməkdir, marşrut cədvəlini yenidən araşdırmaq deyil.

Təkrar pingləri deyil, real tətbiqi müqayisə edin. Nasazlığın müəyyən bir növbəti hopu, paket ölçüsünü və ya yenidən qoşulmadan sonrakı keçidi izləyib-izləmədiyini qeyd edin, çünki bu üç nümunə fərqli təmirlərə işarə edir.

Nəhayət, yolların niyə ekvivalent sayıldığını və nasazlığın birini necə xidmətdən çıxarmalı olduğunu yazın. Çoxyolluqluq yalnız yollar həqiqətən bir-birini əvəz edə bildikdə təhlükəsizdir və bu, fərz etmək deyil, yoxlamağa dəyər bir dizayn ifadəsidir.

Əlaqəli məqalələr