Bərabər məsrəfli marşrutlar VPN nasazlıqlarını niyə çətin görünən edir
Bir neçə tunel eyni məsrəfi paylaşdıqda hər axın fərqli birini seçə bilər. Uğurlu ping tətbiqinizin həqiqətən istifadə etdiyi yol haqqında heç nə demir.
İ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.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session 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.