Patutkah anda mendayakan log terowong AWS VPN pada terowong yang aktif?

Menghidupkan log aktiviti terowong untuk VPN Site-to-Site ialah perubahan kecil yang boleh menjatuhkan terowong yang diukurnya. AWS memberi amaran bahawa mendayakan log pada terowong sedia ada boleh mengganggunya selama beberapa minit, jadi soalan yang menarik bukanlah cara menukar bendera tetapi terowong mana yang hendak ditukar dan bila. Tiga syarat menentukan susunan: sama ada terowong lain benar-benar membawa laluan, sama ada anda memerlukan peristiwa perkhidmatan atau peristiwa BGP, dan sama ada perubahan itu melalui konsol atau API pilihan terowong. Tersilap dan anda akan berakhir dengan gangguan atau kumpulan log yang penuh kosong.

Tiga syarat menentukan susunan

Mulakan dengan identiti perkara yang anda ubah. Anda memerlukan ID sambungan VPN, Wilayah dan alamat IP luar terowong tertentu, kerana setiap tetapan log dalam ciri ini adalah per terowong dan bukan per sambungan. Perubahan yang dikenakan pada alamat luar yang salah ialah perubahan pada terowong yang tiada siapa sedang nyahpepijat.

Destinasi ialah kumpulan log CloudWatch di Wilayah yang sama, dengan pengekalan dan dasar akses yang benar-benar anda mahu. AWS mengesyorkan awalan /aws/vendedlogs/ untuk kumpulan ini kerana ia mengelakkan had saiz dasar sumber yang boleh ditemui oleh nama biasa. Nama seperti /aws/vendedlogs/vpn/branch-a-activity hanyalah ilustrasi; yang penting ialah kumpulan itu wujud, peranan penghantaran boleh menulis ke dalamnya, dan kedua-duanya diurus oleh pemilik konfigurasi VPN. Nama tidak memberikan kebenaran, dan kumpulan yang dicipta tanpa dasar penghantaran menghasilkan kesenyapan dan bukan ralat.

Syarat satu: terowong berlebihan yang benar-benar membawa trafik

Inilah syarat yang dilangkau oleh pasukan. Dua terowong yang dikonfigurasikan bukan bukti bahawa aplikasi mempunyai laluan alternatif yang boleh digunakan.

Sebelum menyentuh satu terowong, sahkan bahawa yang lain membawa laluan yang penting: semak jadual penghalaan di sebelah get laluan pelanggan dan sahkan bahawa aplikasi benar-benar boleh beralih. Tetingkap gangguan AWS ialah minit, bukan saat, dan terowong yang wujud hanya di atas kertas mengubah perubahan diagnostik menjadi gangguan. Jika laluan berlebihan tidak terbukti, jadualkan perubahan itu dengan penjagaan yang sama seperti mana-mana perubahan penghalaan lain dan bukan menganggap log sebagai pasif. Instrumentasikan terowong yang tingkah lakunya cuba anda jelaskan, bukan yang lebih mudah dicapai.

Syarat dua: log aktiviti atau log BGP

Ini menentukan apa yang sebenarnya boleh anda baca. Rekod aktiviti meliputi peristiwa perkhidmatan seperti peralihan keadaan IKE dan IPsec serta mesej DPD, yang anda mahu apabila terowong tidak naik atau terus memperbaharui kunci. Rekod BGP ialah aliran berasingan dengan kawalannya sendiri, dan ia menjawab soalan yang berbeza: sama ada laluan ditukar dan ditarik balik seperti yang dijangka.

Mendayakan bendera aktiviti bukan permintaan untuk setiap aliran yang boleh dikeluarkan oleh perkhidmatan. Jika syak wasangka ialah penghalaan, dayakan kedua-duanya; jika syak wasangka ialah rundingan fasa 1 atau fasa 2, aliran aktiviti itulah yang akan menunjukkannya.

Kedua-dua aliran itu bukan tangkapan paket, dan perbezaan itu menyelesaikan lebih banyak tiket daripada sepatutnya. Rekod aktiviti dan BGP memberitahu anda apa yang perkhidmatan lakukan dengan terowong dan sesi, bukan apa yang aplikasi anda hantar melaluinya. Mencapai log terowong untuk menyahpepijat tamat masa aplikasi ialah kesilapan kategori, dan ia biasanya menelan satu tetingkap gangguan sebelum sesiapa menyedarinya. Pilih soalan dahulu, kemudian aliran yang boleh menjawabnya.

Syarat tiga: perubahan konsol atau API pilihan terowong

Jika manusia membuat perubahan sekali sahaja, laluan konsol sesuai: VPC console, Site-to-Site VPN connections, pilih sambungan, Actions, Modify VPN tunnel options, pilih IP luar, dayakan Tunnel activity log, pilih kumpulan dan format output, simpan dalam tetingkap. Jika VPN diurus sebagai kod, klik yang sama ialah hanyutan yang akan anda selaraskan kemudian.

Untuk automasi, bahagian log aktiviti dalam pilihan terowong mempunyai bentuk tetap: LogOptions yang mengandungi CloudWatchLogOptions dengan LogEnabled, LogGroupArn dan LogOutputFormat. Blok itu ialah serpihan, bukan permintaan; modify-vpn-tunnel-options masih memerlukan ID sambungan dan IP luar terowong, dan tetapan terowong yang lain mesti dipelihara oleh pemilik templat. Log BGP menggunakan kuncinya sendiri BgpLogEnabled, BgpLogGroupArn dan BgpLogOutputFormat dalam struktur yang sama. Baca semula perubahan itu dengan describe-vpn-connections dan bukan mempercayai bahawa panggilan itu telah dikenakan.

Apa yang boleh dan tidak boleh diberitahu oleh rekod

Setelah terowong pertama selesai dan laluan yang dimaksudkan tersedia, ulangi urutan terkawal yang sama untuk terowong kedua jika anda juga memerlukan lognya. Satu terowong pada satu masa ialah inti keseluruhannya.

Rekod tiba dalam aliran yang dikenal pasti oleh sambungan dan alamat luar terowong, jadi kaitkan dengan identiti itu dan bukan mengharapkan sejarah muncul secara retroaktif. Tiada apa-apa sebelum perubahan itu wujud, dan tiada tempoh menunggu mengisi jurang itu. Jika anda memerlukan garis dasar, rakam keadaan terowong semasa dan jadual penghalaan sebelum perubahan supaya ada sesuatu untuk dibandingkan.

Simpan kumpulan log, pengekalannya, kebenaran penghantarannya dan blok pilihan terowong dalam inventori yang sama dengan VPN itu sendiri, kerana ia satu konfigurasi yang tersebar di empat tempat. Prosedur AWS untuk mendayakan log mendokumenkan aliran kerja per terowong dan amaran gangguannya, dan ia wajar dibaca sebelum perubahan dan bukan selepasnya. Kemudian sahkan mengikut urutan: terowong kembali, rekod muncul dalam aliran yang dijangka, dan rekod menjawab soalan yang menyebabkan anda membuka tiket. Jika yang ketiga gagal, masalahnya ialah pilihan aliran dan bukan log.