VPN între sedii funcționează, dar jurnalele ASA nu ajung: verificați adresa sursă

Gazdele interne ajung la colectorul îndepărtat și liniile lor syslog apar. Mesajele proprii ale ASA despre aceleași sesiuni nu ajung niciodată. Nici colectorul, nici tunelul nu au o problemă, și exact asta încurcă. Firewallul își trimite jurnalele dintr-o sursă pe care tunelul nu a fost construit niciodată să o protejeze.

Ce ajunge și ce nu

Începeți prin a separa două fluxuri care pe un panou par identice. Traficul redirecționat trece prin ASA: o gazdă LAN trimite la colector, ASA îl compară cu politica tunelului, îl criptează, iar colectorul vede adresa gazdei. Traficul generat începe pe ASA însuși: echipamentul construiește un pachet syslog, alege o interfață de ieșire și o sursă și abia apoi întreabă dacă se potrivește vreo politică de tunel. Primul flux dovedește că tunelul funcționează și nu spune nimic despre al doilea.

Un eveniment stocat în buffer pe dispozitiv nu este nici el dovadă a livrării la distanță, pentru că jurnalul poate exista local și nu a fost niciodată transmis. Verificați contoarele de recepție ale colectorului înainte de a da vina pe tunel, pentru că un contor gol este o constatare diferită de unul care crește.

Un mesaj generat nu este trafic redirecționat

Când ASA generează el însuși un pachet, nu acționează ca proxy pentru o gazdă LAN. Sursa vine de pe interfața de ieșire sau dintr-o setare explicită de sursă, iar pachetul intră în aceeași căutare de rută și în aceleași verificări de politică precum orice altceva trimite echipamentul. Asta înseamnă că selectorul VPN trebuie să includă adresa pe care ASA o folosește efectiv, iar aceasta este adesea interfața sa exterioară, nu o subrețea internă.

Dacă politica protejează 10.20.0.0/24 și ASA folosește ca sursă adresa sa exterioară, pachetul de jurnal fie pleacă în text clar către un colector pe care nu îl poate atinge, fie este eliminat. Ambele rezultate arată identic din partea colectorului. Același raționament se aplică traficului de administrare, de aceea management-access este o decizie de proiectare separată.

Ce sursă pune ASA pe rețea

Găsiți sursa empiric, nu prin presupunere. O captură pe interfața de ieșire în timpul unui mesaj de test arată sursa și destinația reale, și costă mai puțin timp decât citirea a trei secțiuni de configurare. Comparați acea adresă cu selectorul local al tunelului.

Unele versiuni permit fixarea sursei de jurnalizare pe o interfață, iar referința de comenzi pentru versiunea dumneavoastră este autoritatea cu privire la existența acestei opțiuni și la ce schimbă. O comandă source-interface de pe altă platformă Cisco nu este automat valabilă pe un ASA.

Dacă schimbați sursa, faceți-o deliberat și notați, pentru că ACL-urile colectorului și orice corelație bazată pe syslog depind de ea.

Aliniați selectorul la fluxul de jurnale

Odată sursa cunoscută, verificați trei lucruri în ordine: ACL-ul de criptare sau selectorul bazat pe politică ce decide ce trafic este interesant, ruta ce decide unde merge pachetul și orice regulă NAT care ar putea rescrie sursa înainte de criptare. Un pachet care corespunde rutei dar nu selectorului nu este tunelat, iar un pachet rescris de NAT poate să nu corespundă niciunuia.

Partea colectorului are propriile cerințe: un ACL care permite sursa ASA, o rută de întoarcere și un serviciu în ascultare pe portul configurat. Transportul contează și aici, pentru că jurnalizarea TCP și TLS se comportă diferit de UDP pe o cale parțial blocată. Schimbați un singur element o dată, altfel următoarea captură nu vă va spune care schimbare a contat.

Verificați la colector, apoi notați sursa

Confirmați că mesajul ajunge, apoi notați adresa sursă folosită de ASA, selectorul care a transportat-o și severitatea cu care ați testat.

Acea înregistrare transformă următoarea modificare de ACL la colector sau editarea selectorului într-o verificare de două minute în loc de o redescoperire. Documentează și care dintre cele două fluxuri a fost vreodată validat, iar aceasta este partea pe care majoritatea runbook-urilor o omit. Dacă mesajul tot nu ajunge, coborâți temporar pragul de severitate și testați către o singură destinație.

Întrebările frecvente despre jurnalizarea ASA de la Cisco documentează un caz cu sursă externă ce necesită definiția corespunzătoare a traficului protejat, iar exemplul cu sursă internă include atât o gazdă de jurnalizare în interior, cât și management-access în interior. Tratați combinația documentată și contextul software împreună, în loc să presupuneți că o singură linie copiată se potrivește oricărei configurații.

Un tunel care transportă trafic LAN nu este un tunel care transportă propria voce a firewallului.