Werf-VPN werk, maar ASA-logboeke nie: ondersoek die bronadres

Gasarbeiders binne bereik die afgeleë versamelaar en hul syslog-reëls verskyn. Die ASA se eie boodskappe oor daardie selfde sessies kom nooit aan nie. Niks is verkeerd met die versamelaar of die tonnel nie, en dit is die verwarrende deel. Die firewall stuur sy logboeke vanaf ’n bron wat die tonnel nooit bedoel was om te beskerm nie.

Wat aankom en wat nie

Begin deur twee strome te skei wat op ’n paneel identies lyk. Deurgestuurde verkeer gaan deur die ASA: ’n LAN-gasheer stuur na die versamelaar, die ASA pas dit teen die tonnelbeleid, versleutel dit, en die versamelaar sien die gasheer se adres. Gegenereerde verkeer begin op die ASA self: die toestel bou ’n syslog-pakket, kies ’n uitgangsinterface en bron, en vra eers daarna of enige tonnelbeleid pas. Die eerste stroom bewys dat die tonnel werk, en dit sê niks oor die tweede nie.

’n Gebufferde gebeurtenis op die toestel is ook nie bewys van afgeleë aflewering nie, want die log kan plaaslik bestaan en nooit versend gewees het nie. Kyk na die versamelaar se ontvangs tellers voordat jy die tonnel blameer, want ’n leë teller is ’n ander bevinding as een wat groei.

’n Gegenereerde boodskap is nie deurgestuurde verkeer nie

Wanneer die ASA ’n pakket genereer, gee dit nie aan ’n LAN-gasheer deur nie. Die bron kom van die uitgangsinterface of van ’n eksplisiete broninstelling, en die pakket gaan deur dieselfde roetesoek en beleidskontroles as enigiets anders wat die toestel stuur. Dit beteken die VPN-selektor moet die adres insluit wat die ASA werklik gebruik, wat dikwels sy buite-interface is eerder as ’n binne-subnet.

As die beleid 10.20.0.0/24 beskerm en die ASA gebruik sy buiteadres as bron, verlaat die logpakket óf in duidelike teks na ’n versamelaar wat dit nie kan bereik nie, óf dit word laat val. Beide uitkomste lyk identies van die versamelaar se kant. Dieselfde redenasie geld vir bestuursverkeer, en daarom is management-access ’n aparte ontwerpbesluit.

Watter bron die ASA op die draad sit

Vind die bron empiries eerder as deur aanvaarding. ’n Opname op die uitgangsinterface tydens ’n toetsboodskap wys die werklike bron en bestemming, en dit kos minder tyd as om drie konfigurasie-afdelings te lees. Vergelyk daardie adres met die tonnel se plaaslike selektor.

Sommige weergawes laat jou toe om die logbron aan ’n interface te pen, en die opdragverwysing vir jou weergawe is die gesag oor of daardie opsie bestaan en wat dit verander. ’n Bron-interface-opdrag van ’n ander Cisco-platform is nie outomaties geldig op ’n ASA nie.

As jy die bron wel verander, verander dit doelbewus en teken dit aan, want versamelaar-ACL's en enige korrelasie wat op syslog gebou is, hang daarvan af.

Pas die selektor by die logstroom

Sodra die bron bekend is, kontroleer drie dinge in volgorde: die kripto-ACL of beleidsgebaseerde selektor wat besluit watter verkeer interessant is, die roete wat besluit waar die pakket heen gaan, en enige NAT-reël wat die bron voor versleuteling kan herskryf. ’n Pakket wat by die roete pas maar nie by die selektor nie, word nie deur die tonnel gestuur nie, en ’n pakket wat deur NAT herskryf is, kan by nie een van die twee pas nie.

Die versamelaar se kant het sy eie vereistes: ’n ACL wat die ASA se bron toelaat, ’n terugroete, en ’n luisterdiens op die poort wat jy opgestel het. Vervoer maak hier ook saak, want TCP- en TLS-logging gedra hulle anders as UDP op ’n gedeeltelik geblokkeerde pad. Verander een element op ’n slag, anders sal die volgende opname nie sê watter verandering saak gemaak het nie.

Verifieer by die versamelaar en teken dan die bron aan

Bevestig dat die boodskap aankom, en skryf dan die bronadres neer wat die ASA gebruik het, die selektor wat dit gedra het en die erns waarmee jy getoets het.

Daardie rekord maak die volgende versamelaar-ACL-verandering of selektoraanpassing ’n kontrole van twee minute in plaas van ’n herontdekking. Dit dokumenteer ook watter van die twee strome ooit gevalideer is, en dit is die deel wat die meeste runbooks weglaat. As die boodskap steeds nie aankom nie, verlaag die erns-drempel tydelik en toets teen ’n enkele bestemming.

Cisco se FAQ oor ASA-logging dokumenteer ’n geval met buitenste oorsprong wat die ooreenstemmende beskermde verkeersdefinisie vereis, en sy voorbeeld met binne-oorsprong sluit beide ’n loggasheer aan die binnekant en management-access aan die binnekant in. Behandel die gedokumenteerde kombinasie en die sagtewarekonteks saam eerder as om te aanvaar dat een gekopieerde reël by elke konfigurasie pas.

’n Tonnel wat LAN-verkeer dra, is nie ’n tonnel wat die firewall se eie stem dra nie.