Walang ruta ng pamamahala ang module ng ASA FirePOWER patungong FMC

Ipinapakita ng FMC ang module bilang hindi maabot, nananatiling nakabinbin ang pagpaparehistro, at maayos na gumagana ang ping mula sa loob ng ASA. Sa umiiral na deployment ng ASA FirePOWER, normal ang kombinasyong iyon. May sariling address ng pamamahala ang module, may sariling default gateway at may sariling mga desisyon sa routing, at ang pagbabahagi ng pisikal na koneksyon ng pamamahala sa ASA sa ilang platform ay hindi nagsasama ng mga iyon sa isang stack ng network. Dalawang aparato ang sumasagot mula sa dalawang magkaibang pananaw sa iisang kawad.

Ang sumusunod ay para sa mga module na nasa serbisyo na. Tukuyin ang modelo ng chassis, uri ng module at sinusuportahang bersyon ng software bago ilapat ang anumang diagram ng port mula sa gabay.

Iguhit ang module bilang hiwalay na host

Simulan ang diagram sa IP ng pamamahala ng module, mask at default gateway, ang VLAN na aktuwal na nagdadala ng koneksyong iyon, at ang address ng FMC na dapat maabot. Pagkatapos, sa hiwalay na kahon, isulat ang mga address ng interface ng ASA at ang buong talahanayan ng routing nito. Kung ang dalawang kahon ay mauuwi sa pagbabahagi ng subnet na may mga address na pag-aari ng magkaibang panig, natagpuan mo ang kawili-wiling bahagi ng problema.

Ipinapakita ng gabay ng module ng ASA FirePOWER kung paano nagkakaiba ang mga kaayusan ng port sa iba’t ibang platform, kabilang ang pinagsasaluhang mga kawad ng pamamahala kung saan may hiwalay na mga address ang ASA at ang module sa iisang segment. Ang diagram ng hardware na iyon ay input sa disenyo, hindi talababa.

Hanapin kung saan napuputol ang daang pabalik

Kumuha ng layout na may routing sa core. Ipinapadala ng module ang trapikong patungong FMC sa isang core na Layer 3, ipinapasa ng core ang malayong destinasyon ng pamamahala patungo sa panloob na interface ng ASA, at dinadala ito ng VPN ng site sa kabilang panig. Kailangan naman ng malayong site ang rutang pabalik sa subnet ng pamamahala ng module. Maaaring tama ang bawat hakbang sa tanikala habang nawawala ang huling rutang iyon, at iyon ang dahilan kung bakit madalas na mukhang sirang tunnel ang pagkasira.

Basahin ang sariling pananaw ng ASA bago baguhin ang anuman:

show interface ip brief
show route
show running-config interface

Mahalaga ang ikatlong utos dahil ang address ng interface na nakalimutan mo ang eksaktong dahilan kung bakit napupunta sa maling aparato ang daang pabalik.

Tingnan kung ano ang itinuturing na konektado ng ASA

Kung may address ang ASA sa subnet ng pamamahala ng module, pag-aari ng konektadong ruta nito ang prefix na iyon. Hindi inaalis ng static na ruta patungong core ang pagmamay-ari ng konektadong ruta, kaya bumabalik ang pakete sa ASA at doon hihinto. Pagkatapos ay nabibigo ang pagpaparehistro sa puntong walang kaugnayan sa mga kredensyal.

Huwag magpasya na may partikular na pagsusuring laban sa spoofing na nagtapon ng pakete maliban kung nasa harap mo ang sariling mga obserbasyon ng appliance. Sa halip, ihambing ang ingress na interface, ang piniling ruta ng destinasyon at ang sinusuportahang hangganan ng pagpapasa sa pagitan ng pamamahala at datos para sa platform na iyon. Karaniwang inilalantad ng tatlong katotohanang iyon ang hidwaan ng topolohiya bago pa may magsimulang i-reset ang mga key ng pagpaparehistro.

Pumili ng pagwawasto na nagpapanatili sa module na konektado

Ang pag-alis ng address ng ASA mula sa segment na iyon at ang pisikal na pag-disable ng pinagsasaluhang port ay hindi magkatumbas na aksyon. Sa mga platform kung saan dumadaan ang module sa parehong pisikal na koneksyon ng pamamahala, inaalis ng pag-disable ng port ang tanging link ng module — ginawa mong patay na appliance ang isang problema sa routing. Piliin ang pagbabagong muling naglalaan ng pagmamay-ari ng routing ng pamamahala, at ihanda ito kasama ang may-ari ng network.

Ang ikalawang sinusuportahang opsyon ay bigyan ng sariling segment ang administratibong daan ng ASA upang ang subnet ng pamamahala ng module ay may isang may-ari lamang. Nagkakahalaga iyon ng isang address at kaunting dokumentasyon, at permanenteng inaalis ang kalabuan. Alinmang daan ang piliin mo, pagkatapos ay kumpirmahin na naaabot pa rin ng module ang FMC at ang mga pinagmumulan nito ng DNS o NTP.

Magrehistro lamang kapag matatag na ang ruta

Kapag malinis na ang daang pabalik, planuhin ang konektibidad ng pamamahala at mga parameter ng pagpaparehistro mula sa tugmang gabay ng release ng FMC at module. Itago ang mga lihim ng pagpaparehistro sa labas ng pinagsasaluhang mga tala at tiket, at labanan ang tuksong magparehistro muli bilang hakbang sa dayagnosis: ang bagong key sa sirang daan ay gumagawa lamang ng parehong kabiguan na may mas bagong timestamp.

Tanggapin ang daan mula sa sariling stack ng pamamahala ng module sa halip na mula sa ping na nagmumula sa ASA, dahil ang pinagmulan ng pagsubok ang siyang pinaghihinalaan. Itala ang susunod na hop ng module, ang pagpili ng VPN ng ASA at ang ruta ng tugon ng FMC, at panatilihin ang independiyenteng paraan ng pagbawi para sa dalawang tungkulin ng pamamahala. Ang talang iyon ang naghihiwalay ng naayos na transportasyon mula sa matagumpay na pagpaparehistro.

Kapag sa wakas ay lumitaw ang module sa FMC, patakbuhin muli ang parehong tatlong utos at i-save ang output sa tabi ng diagram. Kakailanganin ng susunod na taong gagalaw sa segment ng pamamahalang iyon ang eksaktong paghahambing na iyon.