Haruskah Anda mengaktifkan log tunnel AWS VPN pada tunnel yang aktif?

Menyalakan log aktivitas tunnel untuk VPN Site-to-Site adalah perubahan kecil yang dapat menjatuhkan tunnel yang sedang diukurnya. AWS memperingatkan bahwa mengaktifkan logging pada tunnel yang sudah ada dapat memutusnya selama beberapa menit, jadi pertanyaan yang menarik bukanlah bagaimana membalik tanda, melainkan pada tunnel mana membaliknya dan kapan. Tiga kondisi menentukan urutannya: apakah tunnel lain benar-benar membawa rute, apakah Anda memerlukan peristiwa layanan atau peristiwa BGP, dan apakah perubahan melewati konsol atau API opsi tunnel. Salah menanganinya dan Anda berakhir dengan pemutusan atau dengan grup log yang penuh kosong.

Tiga kondisi menentukan urutannya

Mulailah dari identitas hal yang Anda ubah. Anda memerlukan ID koneksi VPN, Region, dan alamat IP eksternal tunnel tertentu, karena setiap pengaturan log dalam fitur ini berlaku per tunnel, bukan per koneksi. Perubahan yang diterapkan pada alamat eksternal yang salah adalah perubahan pada tunnel yang tidak sedang di-debug siapa pun.

Tujuannya adalah grup log CloudWatch di Region yang sama, dengan retensi dan kebijakan akses yang benar-benar Anda inginkan. AWS menyarankan awalan /aws/vendedlogs/ untuk grup ini karena menghindari batas ukuran kebijakan sumber daya yang bisa ditemui nama biasa. Nama seperti /aws/vendedlogs/vpn/branch-a-activity hanya ilustratif; yang penting adalah grup itu ada, peran pengiriman dapat menulis ke dalamnya, dan keduanya dikelola oleh pemilik konfigurasi VPN. Nama tidak memberikan izin, dan grup yang dibuat tanpa kebijakan pengiriman menghasilkan keheningan, bukan kesalahan.

Kondisi satu: tunnel redundan yang benar-benar membawa lalu lintas

Inilah kondisi yang dilewati tim. Dua tunnel yang dikonfigurasi bukan bukti bahwa aplikasi memiliki jalur alternatif yang dapat dipakai.

Sebelum menyentuh satu tunnel, pastikan tunnel lain membawa rute yang penting: periksa tabel perutean di sisi gateway pelanggan dan pastikan aplikasi benar-benar dapat beralih. Jendela gangguan AWS adalah menit, bukan detik, dan tunnel yang hanya ada di atas kertas mengubah perubahan diagnostik menjadi gangguan. Jika jalur redundan belum terbukti, jadwalkan perubahan dengan kehati-hatian yang sama seperti perubahan perutean lainnya alih-alih memperlakukan logging sebagai pasif. Instrumentasikan tunnel yang perilakunya coba Anda jelaskan, bukan yang lebih mudah dijangkau.

Kondisi dua: log aktivitas atau log BGP

Kondisi ini menentukan apa yang benar-benar dapat Anda baca. Catatan aktivitas mencakup peristiwa layanan seperti transisi status IKE dan IPsec serta pesan DPD, yang Anda inginkan saat tunnel tidak menyala atau terus memperbarui kunci. Catatan BGP adalah aliran terpisah dengan kontrolnya sendiri, dan menjawab pertanyaan berbeda: apakah rute dipertukarkan dan ditarik kembali sesuai harapan.

Mengaktifkan tanda aktivitas bukan permintaan untuk setiap aliran yang dapat dipancarkan layanan. Jika kecurigaan ada pada perutean, aktifkan keduanya; jika kecurigaan ada pada negosiasi fase 1 atau fase 2, aliran aktivitaslah yang akan menunjukkannya.

Tak satu pun dari kedua aliran itu adalah tangkapan paket, dan perbedaan itu menyelesaikan lebih banyak tiket daripada seharusnya. Catatan aktivitas dan BGP memberi tahu apa yang dilakukan layanan terhadap tunnel dan sesi, bukan apa yang dikirim aplikasi Anda melaluinya. Menjangkau log tunnel untuk men-debug timeout aplikasi adalah kesalahan kategori, dan biasanya memakan satu jendela gangguan sebelum ada yang menyadarinya. Pilih pertanyaannya dulu, lalu aliran yang bisa menjawabnya.

Kondisi tiga: perubahan lewat konsol atau API opsi tunnel

Jika manusia melakukan perubahan sekali jalan, jalur konsol tidak masalah: VPC console, Site-to-Site VPN connections, pilih koneksi, Actions, Modify VPN tunnel options, pilih IP eksternal, aktifkan Tunnel activity log, pilih grup dan format keluaran, simpan di dalam jendela. Jika VPN dikelola sebagai kode, klik yang sama adalah drift yang akan Anda rekonsiliasi nanti.

Untuk otomatisasi, bagian log aktivitas pada opsi tunnel memiliki bentuk tetap: LogOptions berisi CloudWatchLogOptions dengan LogEnabled, LogGroupArn, dan LogOutputFormat. Blok itu adalah fragmen, bukan permintaan; modify-vpn-tunnel-options tetap memerlukan ID koneksi dan IP eksternal tunnel, dan sisa pengaturan tunnel harus dipertahankan oleh pemilik templat. Logging BGP memakai kuncinya sendiri BgpLogEnabled, BgpLogGroupArn, dan BgpLogOutputFormat dalam struktur yang sama. Baca kembali perubahannya dengan describe-vpn-connections alih-alih percaya bahwa panggilan itu diterapkan.

Apa yang bisa dan tidak bisa diceritakan catatan

Setelah tunnel pertama selesai dan jalur yang dimaksud tersedia, ulangi urutan terkendali yang sama untuk tunnel kedua jika Anda juga memerlukan lognya. Satu tunnel pada satu waktu adalah inti seluruhnya.

Catatan datang dalam aliran yang diidentifikasi oleh koneksi dan alamat eksternal tunnel, jadi korelasikan dengan identitas itu alih-alih mengharapkan riwayat muncul secara retroaktif. Tidak ada apa pun sebelum perubahan, dan berapa pun lama menunggu tidak mengisi celah itu. Jika Anda memerlukan garis dasar, catat keadaan tunnel dan tabel perutean saat ini sebelum perubahan agar ada sesuatu untuk dibandingkan.

Simpan grup log, retensinya, izin pengirimannya, dan blok opsi tunnel dalam inventaris yang sama dengan VPN itu sendiri, karena semuanya satu konfigurasi yang tersebar di empat tempat. Prosedur AWS untuk mengaktifkan log mendokumentasikan alur kerja per tunnel dan peringatan gangguannya, dan sebaiknya dibaca sebelum perubahan, bukan sesudahnya. Lalu verifikasi berurutan: tunnel kembali, catatan muncul di aliran yang diharapkan, dan catatan menjawab pertanyaan yang membuat Anda membuka tiket. Jika yang ketiga gagal, masalahnya adalah pilihan aliran, bukan logging.