SSH sa Isang Malayong ASA sa Pamamagitan ng Site VPN: Hakbang-hakbang

Itinuturo mo ang isang SSH client sa panloob na address ng malayong ASA at namamatay ang sesyon sa pagkonekta. Sumasagot ang firewall mula sa sarili nitong site, lumilitaw ang tunnel, at gayunma'y walang nakikinig sa port 22. Sa karamihan ng mga kasong ito hindi umaabot ang packet sa pagtanggap ng pamamahala, dahil ang daang sinusubukan ay hindi kailanman dinisenyo bilang daan ng pamamahala. Sundin ang daloy sa ibaba nang sunud-sunod at titigil ang pagkabigo sa paglipat-lipat.

Piliin ang address na talagang pinamamahalaan mo

Tatlong disenyo ang magkamukha at magkaiba ang kilos: maabot ang pampublikong address ng ASA na nakaharap sa VPN, maabot ang panloob na interface sa pamamagitan ng IPsec, at maabot ang nakalaang interface ng pamamahala. Isulat ang source address ng administrator, ang eksaktong destination address at TCP 22 bago hawakan ang anumang pahintulot. Ang lahat ng kasunod ay nakasalalay sa pares na iyon.

Ang tunnel na may dalang dalawang VLAN ng server ay maaaring walang dalang address ng interface ng firewall o subnet ng pamamahala ng administrator. Tingnan ang listahan ng kawili-wiling trapiko para sa patakarang site-to-site at tiyakin na lumilitaw ang sariling address ng ASA bilang destinasyon, hindi lamang ang mga subnet na dumadaan dito.

Dahil ang destinasyon ay ang firewall mismo, hiwalay ang pagtanggap ng pamamahala sa mga patakaran para sa ipinasa na trapiko. Ang ACL na nagpapahintulot sa mga kliyente na maabot ang mga server sa likod ng ASA ay hindi nagbibigay-daan nang mag-isa sa pamamahala ng SSH ng aparato, at hindi ililipat ng pag-aayos ng patakaran ng pagpapasa ang pagkabigong ito.

Ang management-access ay partikular sa interface

Sinasabi ng command na management-access sa ASA na tanggapin ang mga koneksyon ng pamamahala sa isang pinangalanang interface kapag dumarating ang mga ito sa VPN. Hindi ito gumagawa ng ruta, hindi ito nagdaragdag ng pahintulot ng SSH, at hindi ito nalalapat sa bawat interface nang sabay. Kung ang interface ng destinasyon ay hindi ang pinangalanan, itinatapon ang koneksyon bago ang pagpapatotoo.

Dalawang pagbubukod ang kumakagat dito. Ang mga interface na para sa pamamahala lamang ay nasa labas ng mekanismong ito, at ang gabay sa pamamahala ng ASA 9.20 ay nagsasaad na hindi sinusuportahan ng default na CiscoSSH stack ang SSH sa pagitan ng mga interface sa VPN habang sinusuportahan ito ng ASA SSH stack. Tiyakin ang aktibong stack sa naka-deploy na release bago gumugol ng oras sa mga ruta.

Apat na gate bago ang prompt ng pag-login

Sa pagitan ng kliyente at ng prompt ng username ay may apat na malayang gate: tugma ng ruta at tunnel para sa pares ng pamamahala, ACL ng interface na nagpapahintulot ng TCP 22 patungo sa address ng ASA, pahintulot ng ssh na sumasaklaw sa source ng administrator, at pagpapatotoo ng AAA para sa user na iyon. Alinman sa mga ito ay maaaring maghulog ng packet nang hindi sinasabi sa kliyente kung aling gate ang nagsara.

Gamitin ang packet-tracer upang makita kung aling gate ang nabigo bago baguhin ang anuman: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Pinapangalanan ng trace ang ACL, ang yugto ng NAT at ang pasya ng to-the-box, na kadalasan ay sapat upang ihiwalay ang problema sa routing mula sa problema sa pagtanggap.

Isulat ang makitid na pahintulot, hindi ang malawak

Limitahan ang pahintulot sa aprubadong administratibong subnet at sa interface na tumatanggap ng trapiko ng tunnel: ssh 10.10.5.0 255.255.255.0 inside. Ipares ito sa paraan ng pagpapatotoo tulad ng aaa authentication ssh console LOCAL at isang pinangalanang lokal na account, sa halip na buksan ang bawat source sa panlabas na interface.

Panatilihing magkakatugma ang ACL ng interface at ang pahintulot ng ssh. Nabibigo pa rin ang pahintulot para sa subnet na hinaharangan ng ACL, at nabibigo sa susunod na gate ang ACL na nagpapahintulot sa subnet nang walang tugmang entry ng ssh. Inilalarawan ng dalawang pahayag ang parehong daan mula sa magkaibang antas, kaya suriin ang mga ito nang magkasama sa tumatakbong configuration.

I-verify mula sa pinangalanang host, pagkatapos ay paikliin muli

Magbukas ng bagong sesyon mula sa pinangalanang host ng pamamahala sa halip na mula sa iyong mesa, at tiyakin sa ASA kung aling source address at interface ang ginamit ng koneksyon. Suriin ang mga aktibong sesyon at ang seksyong SSH ng tumatakbong configuration habang bukas ang sesyon, pagkatapos ay isara ito at alisin ang anumang pansamantalang pahintulot na idinagdag mo para sa pagsubok. Kung lumitaw ang sesyon ngunit bumagsak agad pagkatapos ng pag-login, ang natitirang problema ay awtorisasyon at hindi maabot. Itala ang interface at source sa talaan ng pagbabago upang hindi ulitin ng susunod na tao ang diagnosis.

Panatilihing magagamit ang console o iba pang aprubadong daan ng pagbawi sa buong pagbabago. Kapag gumana ang pribadong daan, tiyakin na ang mga pampublikong source at walang kaugnayang user ng VPN ay hindi nakakuha ng parehong access, dahil ang daan ng pamamahala na gumagana para sa lahat ay ibang problema kaysa sa sinimulan mo.