VPN mellem lokationer virker, men ASA-logfilerne kommer ikke: kontrollér kildeadressen
Videresendt LAN-trafik og de logfiler, som firewallen genererer, kan udgå fra forskellige kilder. Kontrollér generering, kilde og selektor, før du genopbygger tunnelen.
Interne værter når den eksterne opsamler, og deres syslog-linjer dukker op. ASA’ens egne meddelelser om de samme sessioner kommer aldrig frem. Der er intet galt med opsamleren eller med tunnelen, og det er det forvirrende. Firewallen sender sine logfiler fra en kilde, som tunnelen aldrig blev bygget til at beskytte.
Hvad der kommer frem, og hvad der ikke gør
Begynd med at skille to strømme ad, som ser identiske ud på et dashboard. Videresendt trafik passerer gennem ASA’en: en LAN-vært sender til opsamleren, ASA’en matcher det mod tunnelpolitikken, krypterer det, og opsamleren ser værtens adresse. Genereret trafik starter på ASA’en selv: boksen bygger en syslog-pakke, vælger en udgangsinterface og kilde og spørger først derefter, om nogen tunnelpolitik matcher. Den første strøm beviser, at tunnelen virker, og den siger intet om den anden.
En bufferet hændelse på enheden er heller ikke bevis på ekstern levering, fordi loggen kan findes lokalt og aldrig være blevet sendt. Kontrollér opsamlerens modtagertællere, før du beskylder tunnelen, fordi en tom tæller er et andet fund end en, der vokser.
En genereret meddelelse er ikke videresendt trafik
Når ASA’en selv opretter en pakke, proxyer den ikke for en LAN-vært. Kilden kommer fra udgangsinterfacet eller fra en eksplicit kildeindstilling, og pakken går gennem samme ruteopslag og politikkontroller som alt andet, boksen sender. Det betyder, at VPN-selektoren skal indeholde den adresse, ASA’en faktisk bruger, og det er ofte dens udvendige interface frem for et internt subnet.
Hvis politikken beskytter 10.20.0.0/24, og ASA’en bruger sin udvendige adresse som kilde, forlader logpakken enten i klartekst mod en opsamler, den ikke kan nå, eller den bliver droppet. Begge udfald ser identiske ud fra opsamlerens side. Samme ræsonnement gælder for administrationstrafik, og derfor er management-access en separat designbeslutning.
Hvilken kilde ASA’en sætter på ledningen
Find kilden empirisk i stedet for ved antagelse. En optagelse på udgangsinterfacet under en testmeddelelse viser den faktiske kilde og destination, og det koster mindre tid end at læse tre konfigurationsafsnit. Sammenlign den adresse med tunnelens lokale selektor.
Nogle versioner lader dig fastgøre logkilden til et interface, og kommandoreferencen for din version er autoriteten på, om den mulighed findes, og hvad den ændrer. En source-interface-kommando fra en anden Cisco-platform er ikke automatisk gyldig på en ASA.
Hvis du ændrer kilden, så gør det bevidst og noter det, fordi opsamlerens ACL’er og enhver korrelation bygget på syslog afhænger af den.
Tilpas selektoren til logstrømmen
Når kilden er kendt, kontrollér tre ting i rækkefølge: den krypto-ACL eller politikbaserede selektor, der afgør, hvilken trafik der er interessant, ruten der afgør, hvor pakken går hen, og enhver NAT-regel, der kan omskrive kilden før kryptering. En pakke, der matcher ruten men ikke selektoren, bliver ikke tunneleret, og en pakke, der omskrives af NAT, matcher måske ingen af dem.
Opsamlersiden har sine egne krav: en ACL, der tillader ASA’ens kilde, en returrute og en lyttende tjeneste på den port, du konfigurerede. Transport betyder noget her også, fordi TCP- og TLS-logging opfører sig anderledes end UDP på en delvist blokeret vej. Ændr ét element ad gangen, ellers vil den næste optagelse ikke fortælle dig, hvilken ændring der betød noget.
Bekræft hos opsamleren, og notér derefter kilden
Bekræft, at meddelelsen når frem, og skriv derefter kildeadressen ned, som ASA’en brugte, selektoren der bar den, og den alvorlighedsgrad, du testede med.
Den registrering gør den næste ACL-ændring eller selektorredigering på opsamleren til et tominutters tjek i stedet for en genopdagelse. Den dokumenterer også, hvilken af de to strømme der nogensinde blev valideret, og det er den del, de fleste runbooks udelader. Hvis meddelelsen stadig ikke kommer frem, sænk alvorlighedstærsklen midlertidigt, og test mod en enkelt destination.
Ciscos FAQ om ASA-logging dokumenterer et tilfælde med ekstern kilde, der kræver den tilsvarende beskyttede trafikdefinition, og dets eksempel med intern kilde omfatter både en logvært på indersiden og management-access på indersiden. Behandl den dokumenterede kombination og softwarekonteksten sammen i stedet for at antage, at én kopieret linje passer til enhver konfiguration.
En tunnel, der bærer LAN-trafik, er ikke en tunnel, der bærer firewallens egen stemme.