SSH na 'n afgeleë ASA deur die werf-VPN: stap vir stap

Jy rig 'n SSH-kliënt op die binne-adres van die afgeleë ASA en die sessie sterf by die verbinding. Die firewall antwoord uit sy eie werf, die tonnel wys op, en tog luister niks op poort 22 nie. In die meeste van hierdie gevalle bereik die pakkie nooit bestuurstoelating nie, want die pad wat getoets word, was nooit as 'n bestuurspad ontwerp nie. Volg die vloei hieronder in volgorde en die fout hou op om rond te beweeg.

Kies die adres wat jy werklik bestuur

Drie ontwerpe lyk soortgelyk en gedra hulle anders: om die ASA se openbare VPN-adres te bereik, om 'n interne koppelvlak deur IPsec te bereik, en om 'n toegewyde bestuurskoppelvlak te bereik. Skryf die administrateur se bronadres, die presiese bestemmingsadres en TCP 22 neer voordat jy aan 'n toelating raak. Alles later hang van daardie paar af.

'n Tonnel wat twee bediener-VLAN's dra, dra dalk glad nie die firewall se koppelvlakadres of die administrateur se bestuursubnet nie. Gaan die lys van interessante verkeer vir die werf-tot-werf-beleid na en bevestig dat die ASA se eie adres as 'n bestemming verskyn, nie net die subnette wat daardeur beweeg nie.

Omdat die bestemming die firewall self is, is bestuurstoelating apart van reëls vir deurstuurde verkeer. 'n ACL wat kliënte na bedieners agter die ASA laat kom, aktiveer nie selfstandig SSH-administrasie van die toestel nie, en om die deurstuur-reël reg te maak sal hierdie fout nie verskuif nie.

management-access is koppelvlakspesifiek

Die opdrag management-access sê vir die ASA om bestuursverbindings na 'n genoemde koppelvlak te aanvaar wanneer hulle oor VPN aankom. Dit skep nie 'n roete nie, dit voeg nie 'n SSH-toelating by nie, en dit geld nie gelyktydig vir elke koppelvlak nie. As die bestemmingskoppelvlak nie die genoemde een is nie, word die verbinding voor verifikasie weggegooi.

Twee uitsluitings byt hier. Koppelvlakke wat net vir bestuur is, val buite hierdie meganisme, en die ASA 9.20-bestuursgids noem dat die verstek CiscoSSH-stapel nie SSH oor VPN tussen koppelvlakke ondersteun nie, terwyl die ASA SSH-stapel dit wel doen. Bevestig die aktiewe stapel op die ontplooide weergawe voordat jy tyd aan roetes bestee.

Vier hekke voor die aanmeldingsopdrag

Tussen die kliënt en die gebruikersnaam-opdrag staan vier onafhanklike hekke: 'n roete- en tonnelooreenstemming vir die bestuurspaar, 'n koppelvlak-ACL wat TCP 22 na die ASA-adres toelaat, 'n ssh-toelating wat die administrateur se bron dek, en AAA-verifikasie vir daardie gebruiker. Elkeen kan die pakkie laat val sonder om vir die kliënt te sê watter hek gesluit het.

Gebruik packet-tracer om te sien watter hek faal voordat jy enigiets verander: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Die naspeuring noem die ACL, die NAT-fase en die to-the-box-besluit, wat gewoonlik genoeg is om 'n roeteprobleem van 'n toelatingsprobleem te skei.

Skryf die smal toelating, nie die breë een nie

Beperk die toelating tot die goedgekeurde administratiewe subnet en die koppelvlak wat die tonnelverkeer ontvang: ssh 10.10.5.0 255.255.255.0 inside. Paar dit met 'n verifikasiemetode soos aaa authentication ssh console LOCAL en 'n benoemde plaaslike rekening, eerder as om elke bron op die buitekoppelvlak oop te maak.

Hou die koppelvlak-ACL en die ssh-toelating konsekwent. 'n Toelating vir 'n subnet wat die ACL blokkeer, faal steeds, en 'n ACL wat die subnet toelaat sonder 'n ooreenstemmende ssh-inskrywing, faal by die volgende hek. Albei stellings beskryf dieselfde pad vanuit verskillende lae, so hersien hulle saam in die lopende konfigurasie.

Verifieer van die benoemde gasheer, dan weer vernou

Maak 'n nuwe sessie oop vanaf die benoemde bestuursgasheer eerder as vanaf jou lessenaar, en bevestig op die ASA watter bronadres en koppelvlak die verbinding gebruik het. Gaan die aktiewe sessies en die SSH-afdeling van die lopende konfigurasie na terwyl die sessie oop is, sluit dit dan en verwyder enige tydelike toelating wat jy vir toetsing bygevoeg het. As die sessie verskyn maar dadelik na aanmelding val, is die oorblywende probleem magtiging eerder as bereikbaarheid. Teken die koppelvlak en bron in die veranderingsrekord aan sodat die volgende persoon nie die diagnoses herhaal nie.

Hou konsole of 'n ander onafhanklik goedgekeurde herstelpad vir die hele verandering beskikbaar. Sodra die private pad werk, bevestig dat openbare bronne en onverwante VPN-gebruikers nie dieselfde toegang gekry het nie, want 'n bestuurspad wat vir almal werk is 'n ander probleem as die een waarmee jy begin het.