Azure S2S VPN qoşulub, amma trafik yoxdur: IKE jurnalını oxuyun

Portal Connected yazır, tunelin işləmə sayğacı var, amma virtual maşınınızdan çıxan trace ikinci hopda kəsilir. Bağlantı statusu IKE və IPsec danışıqlarını təsvir edir, hər iki tərəfdə bir paketin siyasət qatından keçib-keçmədiyini deyil. Bu biletlərin çoxunu iki qüsur izah edir və heç biri Azure marşrutunu dəyişməklə düzəlmir. Hər ikisi artıq şlüzün yaratdığı jurnalda yazılıb, buna görə də marşrut cədvəlindən deyil, oradan başlayıram.

Connected əslində nəyə zəmanət verir

Qoşulmuş saytlar arası bağlantı faza 1 və faza 2-nin tamamlandığını və təhlükəsizlik assosiasiyalarının qurulduğunu bildirir. Bu, danışıq haqqında bir ifadədir: hər iki peer təklif üzərində razılaşdı, açarları mübadilə etdi və SA cütünü quraşdırdı. Bu, trafik seçicilərinin qorunduğunu düşündüyünüz subnetlərlə uyğun olub-olmadığı barədə heç nə demir və uzaq tərəfin paketi deşifrə etdikdən sonra hara yönləndirəcəyi barədə də heç nə demir. Tunel həftələrlə işlək qala bilər, halbuki hər maraqlı axın atılır — insanları sağlam şlüzü yenidən qurmağa vadar edən məhz bu mənzərədir.

İlk yoxlanmalı iki qüsur qarşı tərəfin ESP əvəzinə AH təklif etməsi və şlüzün daxili saymayacağı məkanda nömrələnmiş virtual şəbəkədir.

Marşrutlara toxunmadan əvvəl ixrac edilmiş jurnalı açın

Portalda virtual şəbəkə şlüzünü açın və bağlantı üzərində VPN troubleshooter əməliyyatını işə salın, sonra yaratdığı paketi endirib açın. İçində faza 1 və faza 2 mübadilələrini əks etdirən, vaxt damğası olan və düz mətn kimi oxuna bilən IKE jurnalı var. Yuxarıdan aşağı oxumaq əvəzinə transform sətrini axtarın, çünki maraqlı qeyd adətən bir neçə yüz sətirdən sonra gəlir. Portal girişiniz yoxdursa, diaqnostika parametrləri aktiv olduqda eyni diaqnostika şlüzün jurnal təyinatında görünür.

Ən çox dəyəri iki qeyd daşıyır. Birincisi təxminən belə oxunur: expected ESP with combined authentication and cipher, received AH. İkincisi IKE mübadiləsi zamanı invalid payload xətasıdır ki, bu da adətən səhv qurulmuş və ya dəstəklənməyən təklif sahəsi deməkdir.

Hər ikisi yerli cihazın nə təklif etdiyini təsvir edir, yəni hər ikisi qarşı tərəfin parametrləridir. Bağlantının Azure tərəfini yenidən yaratmaq firewall-unuzun göndərdiyi təklifi dəyişmir və bunu etmək bu iş axınında ən çox itirilən saatdır. Qarşı tərəfdə faza 2-ni birləşmiş autentifikasiya və şifrələmə ilə ESP-yə qoyun və alqoritmi danışığa buraxın, sonra yoxlayın ki, combined mode kimi adlanan vendor checkbox-ı altında səssizcə AH təklifi seçmir.

Virtual şəbəkənin ünvan məkanını təsdiqləyin

Şlüz virtual şəbəkənin özəl diapazonlarda yerləşməsini gözləyir. İctimai blokda nömrələnmiş şəbəkə, məsələn 111.x ilə başlayan, tuneli qaldıra bilər, halbuki Azure həmin məkanı daxili saymaqdan imtina edir; bağlantı sağlam görünür və heç bir axın qəbul olunmur. Seçicilərə bütöv bir gün sərf etməzdən əvvəl ünvan məkanını təsdiqləyin. Əgər nömrələmə köhnə ayırmadan qalan qəti tələbdirsə, həll başqa şlüz deyil, ünvan planının dəyişdirilməsidir.

Ünvan məkanı bıçağında olarkən yerli diapazonlarla kəsişməni qeyd edin, çünki üst-üstə düşən prefikslər müştəri tərəfdən oxşar görünən fərqli bir nasazlıq yaradır.

Prefiksləri hər iki istiqamətdə yoxlayın

Yerli şəbəkə şlüzü resursu yerli prefiksləri saxlayır və onlar uzaq cihazın həqiqətən qoruduğu subnetlərlə uyğun olmalıdır. Cihazın atdığı ünvanları əhatə edən xülasə bəzi axınları keçirəcək, bəzilərində isə uğursuz olacaq; bu da konfiqurasiya uyğunsuzluğu kimi deyil, aralıq marşrut nasazlığı kimi görünür. Uzaq tərəfi də yoxlayın: bir ucun /16, digərinin onun içində üç /24 sadalaması klassik qismən nasazlıqdır. Heç bir siyahı tək başına etibarlı deyil, ona görə də gördüyünüzə güvənmək əvəzinə ikisini yan-yana müqayisə edin.

Prefiksin dəyişməsi həmişə öz-özünə tutulmur, ona görə də bağlantı obyektini yenidən saxlamağı və ya yenidən yaratmağı planlaşdırın, sonra yeni prefikslərin hər iki tərəfdə göründüyünü təsdiqləyin.

Ping deyil, yol yoxlayın

İşlək tuneli işlək marşrutdan ayıran trace belə görünür: birinci hop yerli şlüz, sonra bir neçə cavab verməyən hop, sonra uzaq host cavab verir. Trace hosta heç çatmırsa, tətbiqin həqiqətən istifadə etdiyi TCP portunu yoxlayın, çünki ICMP kifayət qədər tez-tez filtrlənir və uğursuz ping çox az şey sübut edir. Eyni trace-i uzaq hostdan Azure-dakı virtual maşına doğru işə salın. İki nəticə arasındakı asimmetriya çatışmayan qayıdış marşrutunu və ya yalnız bir istiqamətə icazə verən qaydanı tapmağın ən sürətli yoludur.

Qarşı tərəfin təklifini, hər iki ünvan məkanını və bağlantının yaradılma vaxtını bilete yazın ki, növbəti mühəndis hansı dəyərlərin yenidən qurulduğunu, hansılara isə heç toxunulmadığını bilsin.

Jurnal boş qayıdırsa, şlüz bağlantınızı ümumiyyətlə sonlandırmır ola bilər. Yerli şəbəkə şlüzündəki qarşı tərəf ünvanının jurnalı oxuduğunuz cihazla uyğun olduğunu təsdiqləyin, çünki bir abunəlikdə iki şlüzü yenidənqurma zamanı qarışdırmaq asandır. Bu səhv bir günə başa gəlir və heç bir jurnalda iz qoymur.