AWS-dən Azure-a sayt-sayt VPN: əvvəlcə qayıdış marşrutunu yazın
Qoşulmuş buludlararası tunel, hər iş yükü alt şəbəkəsi uzaq prefiksə marşrutlaşdırana qədər heç nə sübut etmir. Planı sıra ilə işləyin, sonra xidməti sınayın.
Tunel qalxacaq. Bu adətən belə olur, çünki IKE yalnız uyğun təkliflər və əlçatan peer ünvanı tələb edir. Sonra uğursuz olan qayıdış yoludur: AWS iş yükü paketləri tunelə göndərir, lakin Azure tərəfində heç nə 10.10.0.0/16 ünvanına necə cavab verəcəyini bilmir, ya da Azure marşrutu iş yükü alt şəbəkəsinin istifadə etmədiyi cədvəldə durur. Marşrut planını hər iki konsola toxunmadan yazın və tunel işin ən az maraqlı hissəsinə çevrilsin.
Addım 1: ünvan planını dondurun
Konkret dəyərlərlə işləyin. AWS iş yükü 10.10.0.0/16 daxilində 10.10.1.20 ünvanında oturur və 10.20.0.0/16 daxilində 10.20.1.30 ünvanındaki Azure xidmətinə TCP 443 lazımdır. İki aralıq üst-üstə düşməməlidir və qəbul testi tunel deyil, xidmət cütüdür.
Bu dörd faktı hər şeydən əvvəl yazın, çünki sonrakı hər addım onlara görə yoxlanılır.
Addım 2: hər uca sahib olan şlüzü adlandırın
AWS Site-to-Site VPN virtual private gateway və ya transit gateway üzərində bitə bilər və bunlar fərqli marşrut sahibləridir. Azure idarə olunan VPN Gateway və ayrıca müştərilərin özlərinin idarə etdiyi VM əsaslı cihazlar təklif edir. Hansı cütə sahib olduğunuzu qeyd edin, çünki növbəti hop hər kombinasiyada fərqlənir.
İdarə olunan şlüz üçün təxmin edilən özəl cihaz ünvanına işarə edən marşrutu kopyalamayın. Cihaz üçün isə bulud marşrut yayımının qonaq əməliyyat sistemini konfiqurasiya etdiyini güman etməyin, çünki etmir.
Bunu səhv etmək tam görünən, lakin paketləri heç vaxt cavab verməyən ünvana yönəldən plan yaradır.
Addım 3: hər iş yükünün həqiqətən istifadə etdiyi marşrutu yazın
Aşağıdaki hər sərhəd ayrı bir axtarışdır və onlardan birindəki marşrut paket üçün marşrut deyil. Tunel işə düşməzdən əvvəl cədvəli öz dəyərlərinizlə doldurun.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS-də iş yükü alt şəbəkəsinin marşrut cədvəli BGP və ya tunel sağlam olduqdan sonra da sizin yenilədiyiniz yerdir; marşrutlaşdırma icmalı bunu bağlantının bir hissəsi sayır. Azure-da istifadəçi təyin etdiyi marşrut cədvəli virtual şəbəkəyə deyil, alt şəbəkəyə bağlanır, ona görə effektiv marşrutu VNet bıçağında deyil, iş yükü NIC-də yoxlayın.
İdarə olunan Azure şlüzü uzaq prefiksi şlüz yayımı ilə öyrənə bilər və UDR bu qərarı üstələyə bilər. UDR-i səbəbiniz olanda əlavə edin, reflekslə deyil. Əgər əlavə etsəniz, onu cihaz ünvanı uydurmaq əvəzinə şlüzün VPN yolu üçün dərc etdiyi növbəti hopa yönəldin. Sonra NIC-dəki effektiv marşrutları yenidən oxuyun, çünki qərar əslində NIC-də verilir.
Addım 4: əhatə dairəsini uyğunlaşdırın
BGP üçün hər tərəfin elan etdiyini digər tərəfin həqiqətən öyrəndiyi ilə, konkret prefiks-prefiks müqayisə edin. Statik marşrutlaşdırma üçün konfiqurasiya edilmiş uzaq aralıqları 3-cü addımda yazdığınız iş yükü marşrutları ilə müqayisə edin.
Kriptoqrafiya barədə razılaşan IKE əlaqəsi heç bir tərəfin 10.10.0.0/16 və ya 10.20.0.0/16 öyrəndiyinə sübut deyil. İki tunel işləyərkən bir tərəf planlaşdırdığınız /16 əvəzinə tək /24 elan edə bilər. Prefiksi tunel statusunda deyil, marşrut cədvəlində yoxlayın. Uyğunsuzluq sonra bir işləyən və heç vaxt cavab verməyən alt şəbəkə kimi görünür.
Addım 5: xidməti real mənbədən sınayın
Nəzərdə tutulan axına AWS təhlükəsizlik qruplarında və şəbəkə ACL-lərində, Azure NSG-lərində və yoldaki hər hansı cihaz filtrində icazə verin. Sonra 10.10.1.20-dən təsdiqlənmiş xidmət ünvanına və portuna bir bağlantı açın və cavabın həmin mənbəyə qayıtdığını təsdiqləyin.
Həm bulud təhlükəsizlik qrupları, həm də NSG-lər stateful-dur, ona görə rədd edilən qayıdış paketi əks istiqamətdə yazmağı unutduğunuz qayda deyil, marşrut simptomudur.
İstənilən şlüzdən ping heç nəyi həll etmir. Şlüz ünvanına ICMP nəzarət müstəvisi yolunu sınayır, iş yükünün ehtiyac duyduğu yönləndirilmiş TCP xidmətini deyil.
Geri qaytarma və qeydlər
Marşrut sahiblərini tunel identifikatorlarının yanında qeyd edin və dəyişiklikdən əvvəlki marşrut cədvəllərini saxlayın. Dəyişiklik çıxarılmalı olsa, tuneli sökməzdən əvvəl iş yükü marşrutlarını silin ki, heç bir alt şəbəkə artıq mövcud olmayan növbəti hopa baxmasın.
Sonrakı alt şəbəkə köçürməsi və ya spoke qoşulması onda yeniləmək üçün bir müəyyən yerə malik olur, heç vaxt sahibi olmadığı marşrut üçün günahı daşıyan işlək tunel əvəzinə.