Peerinq bağlantılı Azure VNet öz VPN şlüzünə ehtiyac duyurmu?
Peerinq bağlantılı VNet, dəstəklənən SKU ilə mərkəzin VPN şlüzündən istifadə edə bilər və hər peerinq istiqamətində bir parametr kifayətdir. Peerinq statusunu deyil, effektiv marşrutları yoxlayın.
Yeni bir filial VNet yaranır, mərkəzdə artıq işlək sayt-sayt şlüzü var və ağlabatan sual ikinci şlüz üçün ödəniş etməli olub-olmadığınızdır. Adətən yox: şlüz tranziti filialın peerinq vasitəsilə mərkəzin şlüzündən istifadə etməsinə imkan verir. Bunun işləyib-işləməyəcəyini üç şərt həll edir və onların heç biri peerinq status nişanından görünmür. Peerinq bağlantısı və başqasının şlüzündən istifadə icazəsi ayrı parametrlərdir, ona görə də bir-birini artıq ping edə bilən iki VM VPN yolu barədə heç nə sübut etmir.
Birinci şərt: şlüz və filialın onun olmaması
Azure, Basic-dən başqa VPN Gateway SKU-ları üçün şlüz tranzitini dəstəkləyir və həm regional, həm də qlobal peerinq bunu daşıya bilər. Filial sahibi olmadığı şlüzü istifadə edir, ona görə öz şlüzü ola bilməz: filialda artıq şlüz varsa və ya uzaq şlüz seçimi artıq seçilibsə, istədiyiniz tranzit parametri əlçatmaz və ya təsirsiz olacaq. Hər hansı sazlamağa başlamazdan əvvəl bunu yoxlayın, çünki deaktiv edilmiş onay qutusu simptomdur, nasazlıq deyil. Əvvəlcə SKU-nu və mövcud şlüzü oxuyun, sonra peerinq parametrlərinə baxın.
Onay qutusunun görünməsi üçün mövcud filial şlüzünü silməyin, ona nəyin bağlı olduğunu bilməyincə. Miqrasiya sırası onay qutusundan daha vacibdir.
İkinci şərt: hər peerinq istiqamətində bir parametr
Peerinq iki obyektdir, hər VNet-də bir dənə, və tranzit parametrləri bu cütün müxtəlif tərəflərindədir. Mərkəzin filiala doğru peerinqi mərkəz şlüzünün filiala xidmət etməsinə icazə verməlidir; filialın mərkəzə doğru peerinqi mərkəzin şlüzünü qəbul etməlidir. Microsoft-un şlüz tranziti təlimatı onları hər istiqamət üzrə adlandırır və onları düz saxlamağın yeganə yolu budur:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
remote etiketi daşıyan idarə elementi hansı VNet-in peerinqini redaktə etdiyinizə görə mənasını dəyişir, ona görə sözü deyil, istiqaməti oxuyun. Hər iki tərəfi qurun, yadda saxlayın və peerinqin hər iki yerdə qoşulmuş göstərildiyini təsdiqləyin.
Üçüncü şərt: ünvan məkanı və icazə sərhədləri
Tranzit eyni təyinat prefiksinin iki şəbəkə mənasını verməsinə imkan verə bilməz, ona görə mərkəz, filial və yerli diapazonlar bunlardan hər hansı işləməmişdən əvvəl bir-birindən ayrı olmalıdır. VNet-lər həmçinin müxtəlif abunəliklərdə və ya müxtəlif tenantlarda ola bilər; bu qadağa deyil, lakin hər peerinqi yaradan və ya yeniləyən identifikasiyanın həmin şəbəkədə tələb olunan icazələri olmalıdır. Abunəliklər arası dəyişikliklər çox vaxt icazə üzündən uğursuz olur və xətanı topologiya problemi kimi oxumaq asandır.
Dəyişiklikdən əvvəl diapazonları və sahiblərini yazın. Hər hansı birində təxmin etmək qoşulan, amma heç nəyə marşrut verməyən peerinq yaradır.
Peerinq statusu ilə deyil, effektiv marşrutlarla yoxlayın
Filial iş yükünün şəbəkə interfeysindəki effektiv marşrutlara baxın və faktiki yerli prefiksi tapın. Filialın marşrut cədvəlini və şlüz marşrutlarının yayılmasının deaktiv olub-olmadığını yoxlayın, çünki istifadəçi təyin etdiyi marşrut və ya yoxlama cihazı peerinq bayraqlarının təklif etdiyi yolu üstələyə bilər. Sonra digər istiqaməti təsdiqləyin: yerli şəbəkə filial prefiksinə sayt-sayt bağlantısı vasitəsilə necə çatmağı bilməlidir, istər öyrənilmiş reklamlar, istərsə də açıq marşrut və müştəri cihazında uyğun qorunan şəbəkə qeydi ilə. Prefiks hər iki tərəfdə yoxdursa, dəyişdirilməli olan şey peerinq bayraqları deyil.
Filial iş yükündən bir xidməti sınaqdan keçirin və cavabı izləyin. VPN şlüzündən və ya mərkəz VM-dən sınaq fərqli mənbə prefiksi və fərqli yol istifadə edir.
Topologiya həm də nöqtə-sayt müştərilərinə xidmət edirsə, onların quraşdırılmış marşrutlarını ayrıca yoxlayın. Windows müştəri paketləri topologiya dəyişikliyindən sonra yenidən yaradılmalı ola bilər, və bu, şlüz paylaşımının uğursuz olduğuna dair sübut deyil, müştəri marşrutlaşdırma tapşırığıdır.
Şlüzün paylaşılması nəyi vermir
Şlüz tranziti marşrutlaşdırma rahatlığıdır, səlahiyyət deyil. Şəbəkə təhlükəsizlik qrupları, yerli filtrlər və xidmət səviyyəli qaydalar hələ də filial iş yükünün nəyə çata biləcəyini müəyyən edir, ona görə paylaşılan tunelin arxasındakı hər şeyə icazə verdiyini güman etmək əvəzinə konkret mənbə-təyinat xidmətini aktivləşdirin.
Peerinq də insanların ümid etdiyi şəkildə keçirici deyil. Başqa bir filialın və ya şəxsi son nöqtənin əlavə edilməsi mövcud tranzit parametrinin əhatə etmədiyi öz marşrut və giriş tələblərini gətirir.