Bakit Nilalampasan ng mga TACACS+ Request ng ASA ang VPN Tunnel ng Iyong Sangay

Buhay ang tunnel ng sangay, nagpapatunay ang mga gumagamit sa malayong TACACS+ server, at nag-time out pa rin ang sariling login ng firewall. Hindi bug sa tunnel ang dahilan: ang LAN-to-LAN tunnel ay nagdadala ng trapikong tumutugma sa mga selector nito, at ang management traffic na ginagawa ng ASA tungkol sa sarili nito ay hiwalay na daloy na may sariling source address. Natutuklasan ito ng karamihan ng team sa panahon ng pagbabago, kapag ang nag-iisang admin account ang siyang nabigo. Ituring ang AAA session na sinisimulan ng ASA na isang daloy na kailangan mong idisenyo, hindi bilang side effect ng koneksyon na gumagana na.

Ang ASA ang client, at ang sarili nitong trapiko ay nangangailangan ng sariling landas

Kapag nakipag-ugnayan ang firewall sa isang TACACS+ server, ang firewall ay client tulad ng iba pa, maliban na walang sadyang nag-configure ng ruta para dito. Nagmumula ang mga packet nito sa isang interface address sa device, ginagawa ito nang lokal sa halip na ipasa, at kailangang i-route, isalin at protektahan ng patakaran tulad ng trapiko ng gumagamit. Ang site-to-site tunnel na nagpoprotekta sa subnet ng gumagamit ay hindi awtomatikong nagpoprotekta sa pinagmulan ng management na iyon, dahil ang pagpili ng trapiko ay nakabatay sa mga address at hindi sa layunin.

Isulat ang address na inaasahan mong makikita ng server. Kung hindi mo ito masabi sa isang linya, wala ka pang disenyo.

Ang interface sa linyang aaa-server ay hindi palamuti

Sa ASA, ang host entry na aaa-server ay tumatanggap ng ugnayan ng interface sa loob ng panaklong, at inilalarawan ito ng sanggunian ng mga command ng AAA host ng Cisco bilang ang interface kung saan naroon ang authentication server. Ang ugnayang iyon ang nag-uugnay sa request sa isang interface at sa patakarang ipinapatupad ng interface na iyon. Ang pagpili nito ayon sa kahit anong interface na nakaharap sa internet, o pag-iwan sa natira mula sa huling migration, ay lumilikha ng source address na hindi kailanman ginawa para rito ang malayong server at ang tunnel.

inside lamang ang tamang sagot kapag hawak ng pinangalanang interface ang address na balak gamitin ng iyong disenyo bilang source. Sa device ng sangay madalas na ganoon; sa device na may ilang pribadong segment maaaring hindi.

Ang pagbabago ng ugnayan ay nangangahulugan ng muling paggawa ng entry

Itinatala ng parehong sanggunian ng command ang isang limitasyon sa pag-edit na nakakahuli sa mga tao sa panahon ng paglilipat: ang pagbabago ng interface sa umiiral na host ay nangangailangan ng pag-alis at muling paggawa ng host entry. Ang configuration na mukhang na-edit ay maaaring hindi pa nagkabisa, at ang susunod na pagtatangkang mag-login ay lalabas pa rin mula sa lumang address. Planuhin ito bilang pagbura at pagdagdag na may kopya ng orihinal na entry sa harap mo, hindi bilang pagbabago sa lugar.

Kung maraming server ang tinukoy, baguhin ang isa at subukan ito bago hawakan ang iba, upang ang isang pagkakamali ay hindi mag-lock ng lahat ng administratibong landas nang sabay.

Suriin ang mga selector, pagsasalin at return path nang sabay

Tatlong bagay ang dapat magtugma para makarating ang request. Ang mga selector ng trapiko ng tunnel, o ang proteksyon ng tunnel-interface kung gumagamit ka, ay dapat isama ang sariling source ng ASA at ang address ng server; ang listahan ng selector na ginawa para sa mga subnet ng gumagamit ay karaniwang hindi ito gagawin. Anumang panuntunan ng NAT sa landas ay dapat isalin ang source na iyon nang pare-pareho, dahil pinapayagan ng server ang pagkakakilanlan ng network device na kasama ang address na nakikita nito. At ang return path ay dapat umiiral, na sa policy-based tunnel ay nangangahulugan na may tugmang selector ang kabilang dulo sa kabaligtarang direksyon.

Sa panig ng server, magkahiwalay na kumpirmahin ang pagkakakilanlan ng device, ang shared secret at ang administratibong patakaran. Pinapanatili ng TACACS+ ang authentication, authorization at accounting bilang magkakahiwalay na operasyon, kaya ang pagtanggi na dumarating pagkatapos ng kumpletong palitan ay sagot ng patakaran, hindi kabiguan ng transport. Ang pagbasa nito bilang problema sa network ay magpapadala sa iyo sa maling lugar.

Ilayo ang secret sa mga packet capture, ticket at transcript habang nagde-debug, at tandaan na ang source address na itinatala ng server ang siyang kailangang ipaliwanag ng iyong disenyo.

Gawin ang pagbabago nang hindi nakakandado sa labas

Gumamit ng console o isang malayang landas ng pamamahala habang binabago ang malayong administratibong authentication, at panatilihin ang aprubadong lokal na alternatibo hanggang makapagdala ang bagong landas ng tunay na login. Pagkatapos ay i-validate nang makitid: isang server, isang device, isang matagumpay na authentication na may source address na naobserbahan sa magkabilang dulo.

Itala ang daloy sa sarili nitong pahina: interface at address ng pinagmulan, malayong server, protektadong landas, at ang taong nagmamay-ari ng patakaran ng authorization. Kung gayon ang susunod na pagbabago sa interface o tunnel ay masusuri nang hindi hinuhulaan kung alin sa dalawang daloy ang naaapektuhan.