VPN tapak-ke-tapak AWS ke Azure: tulis laluan balik dahulu
Tunnel merentas awan yang bersambung tidak membuktikan apa-apa sehingga setiap subnet beban kerja menghalakan laluan ke prefiks jauh. Jalankan pelan mengikut urutan, kemudian uji perkhidmatan.
Tunnel akan naik. Biasanya begitu, kerana IKE hanya perlukan cadangan yang sepadan dan alamat rakan yang boleh dicapai. Yang gagal selepas itu ialah laluan balik: beban kerja AWS menghantar paket ke dalam tunnel, tetapi tiada apa di sebelah Azure tahu cara menjawab 10.10.0.0/16, atau laluan Azure berada dalam jadual yang tidak digunakan oleh subnet beban kerja. Tulis pelan laluan sebelum menyentuh mana-mana konsol, dan tunnel menjadi bahagian kerja yang paling tidak menarik.
Langkah 1: bekukan pelan alamat
Bekerja dengan nilai konkrit. Beban kerja AWS berada pada 10.10.1.20 dalam 10.10.0.0/16 dan memerlukan TCP 443 ke perkhidmatan Azure pada 10.20.1.30 dalam 10.20.0.0/16. Kedua-dua julat tidak boleh bertindih, dan ujian penerimaan ialah pasangan perkhidmatan, bukan tunnel.
Tulis keempat-empat fakta itu sebelum apa-apa lagi, kerana setiap langkah seterusnya diperiksa terhadapnya.
Langkah 2: namakan gateway yang memiliki setiap hujung
AWS Site-to-Site VPN boleh berakhir pada virtual private gateway atau transit gateway, dan kedua-duanya pemilik penghalaan yang berbeza. Azure menawarkan VPN Gateway terurus dan, secara berasingan, perkakas berasaskan VM yang dijalankan pelanggan sendiri. Catat pasangan mana yang anda ada, kerana hop seterusnya berbeza dalam setiap gabungan.
Untuk gateway terurus, jangan salin laluan yang menunjuk ke alamat perkakas peribadi yang diagak. Untuk perkakas, jangan andaikan penyebaran laluan di awan mengkonfigurasi sistem pengendalian tetamu, kerana ia tidak melakukannya.
Silap di sini menghasilkan pelan yang kelihatan lengkap dan menghantar paket ke alamat yang tidak pernah menjawab.
Langkah 3: tulis laluan yang benar-benar digunakan setiap beban kerja
Setiap sempadan di bawah ialah carian berasingan, dan laluan dalam salah satunya bukan laluan untuk paket itu. Isikan jadual dengan nilai anda sendiri sebelum tunnel beroperasi.
| 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 |
Di AWS, jadual laluan subnet beban kerja ialah milik anda untuk dikemas kini walaupun selepas BGP atau tunnel sihat; gambaran keseluruhan penghalaan menganggapnya sebahagian daripada sambungan. Di Azure, jadual laluan yang ditentukan pengguna dikaitkan dengan subnet dan bukan dengan rangkaian maya, jadi periksa laluan berkesan pada NIC beban kerja, bukan pada bilah VNet.
Gateway Azure terurus boleh mempelajari prefiks jauh melalui penyebaran gateway, dan UDR boleh mengatasi keputusan itu. Tambah UDR apabila anda mempunyai sebab, bukan secara refleks. Jika menambah, halakan ke hop seterusnya yang diterbitkan gateway untuk laluan VPN dan bukan mencipta alamat perkakas. Kemudian baca semula laluan berkesan pada NIC, kerana keputusan sebenarnya dibuat di sana.
Langkah 4: selaraskan skop
Untuk BGP, bandingkan apa yang diiklankan setiap pihak dengan apa yang benar-benar dipelajari pihak lain, prefiks demi prefiks. Untuk penghalaan statik, bandingkan julat jauh yang dikonfigurasi dengan laluan beban kerja yang anda tulis dalam langkah 3.
Hubungan IKE yang bersetuju tentang kriptografi bukan bukti bahawa mana-mana pihak telah mempelajari 10.10.0.0/16 atau 10.20.0.0/16. Dua tunnel boleh berada di atas sementara satu pihak mengiklankan satu /24 sahaja dan bukan /16 yang anda rancang. Periksa prefiks dalam jadual penghalaan, bukan dalam status tunnel. Ketidakpadanan muncul kemudian sebagai satu subnet yang berfungsi dan satu yang tidak pernah menjawab.
Langkah 5: uji perkhidmatan, dari sumber sebenar
Benarkan aliran yang dimaksudkan dalam kumpulan keselamatan dan ACL rangkaian AWS, dalam NSG Azure dan dalam mana-mana penapis perkakas di laluan. Kemudian buka satu sambungan dari 10.10.1.20 ke alamat dan port perkhidmatan yang diluluskan dan sahkan bahawa balasan kembali ke sumber yang sama.
Kumpulan keselamatan awan dan NSG kedua-duanya stateful, jadi paket balik yang ditolak ialah gejala penghalaan, bukan peraturan yang anda terlupa tulis terbalik.
Ping dari mana-mana gateway tidak menyelesaikan apa-apa. ICMP ke alamat gateway melatih laluan satah kawalan, bukan perkhidmatan TCP yang diteruskan yang diperlukan oleh beban kerja.
Rollback dan rekod
Catat pemilik laluan di sebelah pengecam tunnel, dan simpan jadual laluan sebelum perubahan. Jika perubahan perlu ditarik balik, buang laluan beban kerja sebelum meruntuhkan tunnel, supaya tiada subnet terus menunjuk ke hop seterusnya yang tidak lagi wujud.
Pemindahan subnet atau sambungan spoke kemudiannya mempunyai satu tempat tertentu untuk dikemas kini, bukan tunnel yang berfungsi yang menanggung kesalahan bagi laluan yang tidak pernah dimilikinya.