Gumagana ang VPN sa pagitan ng mga site, pero hindi dumarating ang mga log ng ASA: suriin ang source address

Naabot ng mga internal host ang remote collector at lumilitaw ang kanilang mga syslog line. Ang sariling mga mensahe ng ASA tungkol sa parehong mga session ay hindi kailanman dumarating. Walang mali sa collector o sa tunnel, at iyon ang nakakalito. Nagpapadala ang firewall ng mga log nito mula sa pinagmulang hindi kailanman itinayo ang tunnel upang protektahan.

Ano ang dumarating at ano ang hindi

Magsimula sa paghihiwalay ng dalawang daloy na magkapareho sa dashboard. Ang naipasang trapiko ay dumadaan sa ASA: nagpapadala ang host ng LAN sa collector, inihahambing ito ng ASA sa patakaran ng tunnel, ine-encrypt ito, at nakikita ng collector ang address ng host. Ang nabuong trapiko ay nagsisimula sa ASA mismo: bumubuo ang device ng syslog packet, pumipili ng exit interface at pinagmulan, at pagkatapos lang nagtatanong kung may tumutugmang patakaran ng tunnel. Ang unang daloy ay nagpapatunay na gumagana ang tunnel, at wala itong sinasabi tungkol sa pangalawa.

Ang naka-buffer na event sa device ay hindi rin patunay ng remote delivery, dahil maaaring umiiral ang log nang lokal at hindi kailanman naipadala. Suriin ang mga receive counter ng collector bago sisihin ang tunnel, dahil ang walang laman na counter ay ibang natuklasan kaysa sa dumarami.

Ang nabuong mensahe ay hindi naipasang trapiko

Kapag ang ASA mismo ang gumagawa ng packet, hindi ito nag-proproxy para sa isang host ng LAN. Ang pinagmulan ay nagmumula sa exit interface o sa isang tahasang setting ng pinagmulan, at ang packet ay pumapasok sa parehong paghahanap ng ruta at parehong pagsusuri ng patakaran gaya ng lahat ng iba pang ipinapadala ng device. Ibig sabihin, kailangang isama ng selector ng VPN ang address na aktwal na ginagamit ng ASA, at madalas ito ang panlabas na interface nito at hindi isang panloob na subnet.

Kung pinoprotektahan ng patakaran ang 10.20.0.0/24 at ginagamit ng ASA ang panlabas na address nito bilang pinagmulan, ang log packet ay lumalabas sa plaintext patungo sa collector na hindi nito maabot, o itinatapon ito. Parehong magkapareho ang hitsura ng dalawang resulta mula sa panig ng collector. Ganoon din ang pangangatwiran sa trapiko ng pamamahala, kaya ang management-access ay hiwalay na desisyon sa disenyo.

Aling pinagmulan ang inilalagay ng ASA sa network

Hanapin ang pinagmulan nang empirikal at hindi sa palagay. Ang pag-capture sa exit interface habang may test message ay nagpapakita ng aktwal na pinagmulan at destinasyon, at ito ay mas mabilis kaysa sa pagbabasa ng tatlong seksyon ng configuration. Ihambing ang address na iyon sa lokal na selector ng tunnel.

Pinapayagan ng ilang release na i-pin ang pinagmulan ng pag-log sa isang interface, at ang command reference para sa iyong bersyon ang awtoridad kung umiiral ang opsyong iyon at ano ang binabago nito. Ang source-interface command mula sa ibang platform ng Cisco ay hindi awtomatikong wasto sa ASA.

Kung babaguhin mo ang pinagmulan, gawin ito nang sadya at itala, dahil nakasalalay dito ang mga ACL ng collector at anumang ugnayang itinayo sa syslog.

Itugma ang selector sa daloy ng log

Kapag alam na ang pinagmulan, suriin ang tatlong bagay sa pagkakasunod-sunod: ang crypto ACL o selector na batay sa patakaran na nagpapasya kung aling trapiko ang kawili-wili, ang rutang nagpapasya kung saan pupunta ang packet, at anumang panuntunan ng NAT na maaaring magsulat muli ng pinagmulan bago ang encryption. Ang packet na tumutugma sa ruta ngunit hindi sa selector ay hindi tinutunnel, at ang packet na muling isinulat ng NAT ay maaaring hindi tumugma sa alinman.

May sariling pangangailangan ang panig ng collector: isang ACL na nagpapahintulot sa pinagmulan ng ASA, isang return route at isang serbisyong nakikinig sa port na iyong na-configure. Mahalaga rin ang transport dito, dahil iba ang kilos ng pag-log sa TCP at TLS kaysa sa UDP sa isang bahagyang naka-block na landas. Baguhin ang isang elemento sa isang pagkakataon, kung hindi ay hindi sasabihin ng susunod na capture kung aling pagbabago ang mahalaga.

I-verify sa collector, pagkatapos itala ang pinagmulan

Kumpirmahin na dumarating ang mensahe, pagkatapos itala ang source address na ginamit ng ASA, ang selector na nagdala nito at ang severity na ginamit mo sa pagsubok.

Ang talang iyon ay ginagawang dalawang minutong pagsusuri ang susunod na pagbabago ng ACL ng collector o pag-edit ng selector sa halip na muling pagtuklas. Idinodokumento rin nito kung alin sa dalawang daloy ang kailanman na-validate, at iyon ang bahaging iniiwan ng karamihan sa runbook. Kung hindi pa rin dumarating ang mensahe, pansamantalang ibaba ang threshold ng severity at subukan laban sa isang destinasyon.

Ang mga FAQ tungkol sa pag-log ng ASA ng Cisco ay nagdodokumento ng kaso na may panlabas na pinagmulan na nangangailangan ng katumbas na depinisyon ng protektadong trapiko, at ang halimbawa nito na may panloob na pinagmulan ay may kasamang log host sa loob at management-access sa loob. Pagsamahin ang dokumentadong kombinasyon at ang konteksto ng software, sa halip na ipagpalagay na ang isang kopyadong linya ay umaangkop sa bawat configuration.

Ang tunnel na nagdadala ng trapiko ng LAN ay hindi tunnel na nagdadala ng sariling boses ng firewall.