VPN qoşulur, lakin LAN cihazlarına çatmır: nəyi yoxlamaq lazımdır

Trafik tunelə daxil olur, şlüz öz ünvanında cavab verir və arxasında heç nə cavab vermir. Bu nümunə geniş yayılıb və bu ziddiyyət deyil: şlüzdən gələn cavab tunelin bitdiyini sübut edir və ondan kənara ünvanlanmış paketlə nə baş verdiyi barədə heç nə sübut etmir. İki test eyni maşında fərqli kod yollarını işə salır.

Bundan sonra şlüzün o biri tərəfində nəyisə yoxlayın. Şlüzün öz ünvanı yönləndirmə nə qədər pozulmuş olsa da cavab verməyə davam edəcək.

Şlüz öz yığınından cavab verir

Şlüzə ünvanlanmış paket onun yerli giriş yoluna çatdırılır və orada nüvə dinləyən soketin onu qəbul edib-etmədiyini qərarlaşdırır. Şlüzün arxasındakı hosta ünvanlanmış paket isə bunun əvəzinə yönləndirmə yoluna çatdırılır və orada fərqli yoxlamalar toplusu tətbiq olunur. Yönləndirmə tamamilə söndürülə bilər, ya da nüvə tərəfindən aktivləşdirilib sonra tuneli heç xatırlatmayan filtr qaydası ilə rədd edilə bilər. Bunların heç biri şlüzün öz cavabına təsir etmir, buna görə də simptom bu qədər etibarlı şəkildə çaşdırır.

Tuneldən keçərək əldə edilən idarəetmə səhifələri də birinci kateqoriyaya aiddir. Onlar tunel barədə sübutdur, arxasındakı şəbəkə barədə deyil.

Axını onu ilk atan sərhədə qədər izləyin

Müştəridən başlayın və axının istifadə edəcəyi marşrutu və mənbə ünvanını təsdiqləyin. Sonra şlüzdə həmin axının gəlişini, yenə də həmin axının LAN-a doğru gedişini izləyin. Əgər heç vaxt gəlmirsə, problem müştəri tərəfində və ya tunelin icazəli prefikslərindədir. Əgər gəlib heç vaxt getmirsə, problem yönləndirmədə və ya irəli yol filtrindədir və çəkiliş artıq hansının olduğunu deyib.

Eyni testi şlüzdən aparmaq maraqlı yarısını gizlədir, çünki şlüzdən yaranan paketin mənbəyi və geri dönüş tələbi fərqlidir. Hər addımda müştərinin axınından, onun öz mənbə ünvanı ilə istifadə edin. Yanlış interfeysdə götürülmüş çəkiliş arxayın cəfəngiyyat verir.

Geri marşrutlar və host firewall-ları ayrı-ayrılıqda uğursuz olur

Paket hosta çatdıqdan sonra daha üç şərt ödənməlidir. Xidmət paketin göndərildiyi ünvanda dinləməlidir, host firewall-u onu qəbul etməlidir və cavabın müştəri hovuzuna doğru geri marşrutu olmalıdır. Sonuncusu tez-tez uğursuz olur, çünki hostun defolt marşrutu tunel aralığından heç vaxt xəbəri olmayan marşrutlaşdırıcıya işarə edir. Nəticə hostun nöqteyi-nəzərindən qurulan və digər istiqamətdə səssizcə ölən bir bağlantıdır.

Cavab yolunu qəsdən yoxlayın: müştəridən göndərin və geri dönüşü izləyin. Birtərəfli çəkiliş bir saatlıq fərziyyənin həll etmədiyini saniyələr içində həll edir.

Hər addımı müştərinin mənbə ünvanı ilə təsdiqləyin

Yoxlamaları sıra ilə aparın və hər çıxışı saxlayın, çünki dəyər hər hansı tək sətirdə deyil, müqayisədədir. Aşağıdakı əmrlər mənbə ünvanını bərkidir, seçilmiş marşrutu göstərir və yönləndirmənin hər iki tərəfini çəkir. Öz LAN hostunuzu və tunel interfeysinizi əvəz edin.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

Marşrut sorğusu müştərinin o paketi ümumiyyətlə tunelə göndərib-göndərməyəcəyini göstərir, ping isə hostdan nəyinsə qayıdıb-qayıtmadığını göstərir. İki çəkilişi müqayisə etmək gəlişi çıxışdan ayırır, çünki tunel interfeysində olub LAN interfeysində qarşılığı olmayan kadr xidmət nasazlığı deyil, yönləndirmə qərarıdır. Hər iki çəkiliş sorğunu, yalnız biri cavabı göstərdikdə qalan şübhəli geri marşrutdur.

Hansı ünvanın cavab verdiyini və hansı yönləndirilmiş təyinatın uğursuz olduğunu qeyd edin. Bu cümlə hesabatı «server əlçatmazdır» iddiası yerinə fəaliyyətə yararlı edir.