VPN situs-ke-situs AWS ke Azure: tulis dulu rute balik
Tunnel lintas-cloud yang tersambung tidak membuktikan apa pun sampai setiap subnet beban kerja merutekan ke prefiks jauh. Jalankan rencana berurutan, lalu uji layanannya.
Tunnel akan naik. Biasanya begitu, karena IKE hanya butuh proposal yang cocok dan alamat peer yang terjangkau. Yang gagal setelah itu adalah jalur balik: beban kerja AWS mengirim paket ke tunnel, tetapi tidak ada yang di sisi Azure tahu cara menjawab 10.10.0.0/16, atau rute Azure ada di tabel yang tidak dipakai subnet beban kerja. Tulis rencana rute sebelum menyentuh konsol mana pun, dan tunnel menjadi bagian paling tidak menarik dari pekerjaan.
Langkah 1: bekukan rencana alamat
Bekerjalah dengan nilai konkret. Beban kerja AWS berada di 10.10.1.20 dalam 10.10.0.0/16 dan membutuhkan TCP 443 ke layanan Azure di 10.20.1.30 dalam 10.20.0.0/16. Kedua rentang tidak boleh tumpang tindih, dan uji penerimaan adalah pasangan layanan, bukan tunnel.
Tulis keempat fakta itu sebelum hal lain, karena setiap langkah berikutnya diperiksa terhadapnya.
Langkah 2: namai gateway yang memiliki setiap ujung
AWS Site-to-Site VPN dapat berakhir di virtual private gateway atau transit gateway, dan keduanya pemilik perutean yang berbeda. Azure menawarkan VPN Gateway terkelola dan, terpisah, perangkat berbasis VM yang dijalankan pelanggan sendiri. Catat pasangan mana yang Anda punya, karena hop berikutnya berbeda di setiap kombinasi.
Untuk gateway terkelola, jangan menyalin rute yang menunjuk ke alamat perangkat privat yang ditebak. Untuk perangkat, jangan menganggap propagasi rute di cloud mengonfigurasi sistem operasi tamu, karena tidak.
Salah di sini menghasilkan rencana yang tampak lengkap dan mengirim paket ke alamat yang tidak pernah menjawab.
Langkah 3: tulis rute yang benar-benar dipakai setiap beban kerja
Setiap batas di bawah adalah pencarian terpisah, dan rute di salah satunya bukan rute untuk paket. Isi tabel dengan nilai Anda sendiri sebelum tunnel aktif.
| 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, tabel rute subnet beban kerja adalah milik Anda untuk diperbarui bahkan setelah BGP atau tunnel sehat; ikhtisar perutean menganggapnya bagian dari koneksi. Di Azure, tabel rute yang ditentukan pengguna dikaitkan dengan subnet, bukan dengan jaringan virtual, jadi periksa rute efektif pada NIC beban kerja, bukan di bilah VNet.
Gateway Azure terkelola dapat mempelajari prefiks jauh melalui propagasi gateway, dan UDR dapat menimpa keputusan itu. Tambahkan UDR ketika Anda punya alasan, bukan secara refleks. Jika menambahkan, arahkan ke hop berikutnya yang diterbitkan gateway untuk jalur VPN alih-alih mengarang alamat perangkat. Lalu baca ulang rute efektif pada NIC, karena keputusan sebenarnya diambil di sana.
Langkah 4: selaraskan cakupan
Untuk BGP, bandingkan apa yang diiklankan setiap sisi dengan apa yang benar-benar dipelajari sisi lain, prefiks demi prefiks. Untuk perutean statis, bandingkan rentang jauh yang dikonfigurasi dengan rute beban kerja yang Anda tulis di langkah 3.
Hubungan IKE yang sepakat soal kriptografi bukan bukti bahwa salah satu sisi mempelajari 10.10.0.0/16 atau 10.20.0.0/16. Dua tunnel bisa aktif sementara satu sisi mengiklankan satu /24 saja alih-alih /16 yang Anda rencanakan. Periksa prefiks di tabel perutean, bukan di status tunnel. Ketidakcocokan muncul kemudian sebagai satu subnet yang bekerja dan satu yang tidak pernah menjawab.
Langkah 5: uji layanan, dari sumber sebenarnya
Izinkan aliran yang dimaksud di grup keamanan dan ACL jaringan AWS, di NSG Azure, dan di filter perangkat mana pun di jalur. Lalu buka satu koneksi dari 10.10.1.20 ke alamat dan port layanan yang disetujui dan pastikan balasannya kembali ke sumber yang sama.
Grup keamanan cloud dan NSG keduanya stateful, jadi paket balik yang ditolak adalah gejala perutean, bukan aturan yang lupa Anda tulis terbalik.
Ping dari gateway mana pun tidak menyelesaikan apa pun. ICMP ke alamat gateway melatih jalur bidang kontrol, bukan layanan TCP yang diteruskan yang dibutuhkan beban kerja.
Rollback dan catatan
Catat pemilik rute di samping pengenal tunnel, dan simpan tabel rute sebelum perubahan. Jika perubahan harus dicabut, hapus rute beban kerja sebelum membongkar tunnel, agar tidak ada subnet yang menunjuk ke hop berikutnya yang sudah tidak ada.
Pemindahan subnet atau penyambungan spoke berikutnya kemudian punya satu tempat pasti untuk diperbarui, alih-alih tunnel yang bekerja dan menanggung kesalahan rute yang tidak pernah dimilikinya.