Ar trebui să activezi jurnalele de tunel AWS VPN pe un tunel activ?

Activarea jurnalelor de activitate ale tunelului pentru o VPN site-to-site este o schimbare mică ce poate doborî tunelul pe care îl măsoară. AWS avertizează că activarea jurnalizării pe un tunel existent îl poate întrerupe câteva minute, așa că întrebarea interesantă nu este cum să întorci indicatorul, ci pe ce tunel îl întorci și când. Trei condiții stabilesc ordinea: dacă celălalt tunel chiar transportă rutele, dacă ai nevoie de evenimente de serviciu sau de evenimente BGP și dacă schimbarea trece prin consolă sau prin API-ul opțiunilor tunelului. Dacă greșești acestea, ajungi fie cu o întrerupere, fie cu un grup de jurnale plin de nimic.

Trei condiții stabilesc ordinea

Începe cu identitatea lucrului pe care îl schimbi. Ai nevoie de ID-ul conexiunii VPN, de regiune și de adresa IP externă a tunelului respectiv, pentru că fiecare setare de jurnal din această funcție este per tunel, nu per conexiune. O schimbare aplicată pe adresa externă greșită este o schimbare pe un tunel pe care nimeni nu îl depana.

Destinația este un grup de jurnale CloudWatch în aceeași regiune, cu politica de păstrare și de acces pe care o vrei cu adevărat. AWS recomandă prefixul /aws/vendedlogs/ pentru aceste grupuri pentru că evită limitele de dimensiune ale politicii de resurse de care numele simple se pot lovi. Un nume precum /aws/vendedlogs/vpn/branch-a-activity este doar ilustrativ; contează că grupul există, că rolul de livrare poate scrie în el și că ambele sunt administrate de cel care deține configurația VPN. Numele nu acordă permisiuni, iar un grup creat fără politica de livrare produce tăcere, nu eroare.

Prima condiție: un tunel redundant care chiar transportă trafic

Aceasta este condiția pe care echipele o sar. Două tuneluri configurate nu sunt dovada că aplicația are o cale alternativă utilizabilă.

Înainte de a atinge un tunel, confirmă că celălalt transportă rutele care contează: verifică tabela de rutare de partea gateway-ului clientului și confirmă că aplicația poate chiar comuta. Fereastra de întrerupere a AWS este de minute, nu de secunde, iar un tunel care există doar pe hârtie transformă o schimbare de diagnostic într-o cădere. Dacă calea redundantă nu este dovedită, planifică schimbarea cu aceeași grijă ca orice altă schimbare de rutare, în loc să tratezi jurnalizarea ca pasivă. Instrumentează tunelul a cărui comportament încerci să îl explici, nu pe cel care e mai ușor de atins.

A doua condiție: jurnal de activitate sau jurnal BGP

Aceasta decide ce vei putea citi de fapt. Înregistrările de activitate acoperă evenimente de serviciu precum tranzițiile de stare IKE și IPsec și mesajele DPD, ceea ce vrei când tunelul nu se ridică sau nu se oprește din reînnoirea cheilor. Înregistrările BGP sunt un flux separat cu propriile controale și răspund la o altă întrebare: dacă rutele au fost schimbate și retrase conform așteptărilor.

Activarea indicatorului de activitate nu este o cerere pentru fiecare flux pe care serviciul îl poate emite. Dacă suspiciunea este rutarea, activează ambele; dacă suspiciunea este negocierea fazei 1 sau fazei 2, fluxul de activitate este cel care o va arăta.

Niciunul dintre fluxuri nu este o captură de pachete, iar această distincție rezolvă mai multe tichete decât ar trebui. Înregistrările de activitate și BGP îți spun ce a făcut serviciul cu tunelul și sesiunea, nu ce a trimis aplicația ta prin ele. Să apelezi la jurnalele tunelului pentru a depana un timeout al aplicației este o eroare de categorie și de obicei costă o fereastră de întrerupere înainte ca cineva să observe. Alege mai întâi întrebarea, apoi fluxul care o poate răspunde.

A treia condiție: schimbare din consolă sau din API-ul opțiunilor tunelului

Dacă o persoană face o schimbare unică, calea prin consolă este în regulă: VPC console, Site-to-Site VPN connections, selectează conexiunea, Actions, Modify VPN tunnel options, alege IP-ul extern, activează Tunnel activity log, alege grupul și formatul de ieșire, salvează în fereastră. Dacă VPN-ul este administrat ca cod, același clic este o derivă pe care o vei reconcilia mai târziu.

Pentru automatizare, partea de jurnal de activitate a opțiunilor tunelului are o formă fixă: LogOptions care conține CloudWatchLogOptions cu LogEnabled, LogGroupArn și LogOutputFormat. Acel bloc este un fragment, nu o cerere; modify-vpn-tunnel-options are în continuare nevoie de ID-ul conexiunii și de IP-ul extern al tunelului, iar celelalte setări ale tunelului trebuie păstrate de cel care deține șablonul. Jurnalizarea BGP folosește propriile chei BgpLogEnabled, BgpLogGroupArn și BgpLogOutputFormat în aceeași structură. Citește schimbarea înapoi cu describe-vpn-connections în loc să te bazezi că apelul a fost aplicat.

Ce pot și ce nu pot să îți spună înregistrările

După ce primul tunel este gata și calea dorită este disponibilă, repetă aceeași secvență controlată pentru al doilea tunel dacă ai nevoie și de jurnalele lui. Un tunel o dată este tot sensul.

Înregistrările sosesc în fluxuri identificate de conexiune și de adresa externă a tunelului, așa că corelează cu acea identitate în loc să te aștepți ca istoricul să apară retroactiv. Nimic dinaintea schimbării nu există și nicio așteptare nu umple golul. Dacă ai nevoie de o linie de bază, capturează starea actuală a tunelului și tabela de rutare înainte de schimbare, ca să existe ceva cu care să compari.

Ține grupul de jurnale, păstrarea lui, permisiunile de livrare și blocul opțiunilor tunelului în același inventar ca VPN-ul însuși, pentru că sunt o singură configurație răspândită în patru locuri. Procedura AWS de activare a jurnalelor documentează fluxul de lucru per tunel și avertismentul său de întrerupere, și merită citită înainte de schimbare, nu după. Apoi verifică în ordine: tunelul a revenit, înregistrările apar în fluxul așteptat și înregistrările răspund la întrebarea pentru care ai deschis tichetul. Dacă al treilea eșuează, problema a fost alegerea fluxului, nu jurnalizarea.