SSH către un ASA la distanță prin VPN-ul sitului: pas cu pas

Îndreptați un client SSH către adresa internă a ASA-ului la distanță și sesiunea moare la conectare. Firewall-ul răspunde din propriul sit, tunelul apare și totuși nimic nu ascultă pe portul 22. În majoritatea acestor cazuri pachetul nu ajunge niciodată la admiterea administrării, pentru că drumul testat nu a fost niciodată proiectat ca drum de administrare. Urmați fluxul de mai jos în ordine și defecțiunea încetează să se mai mute.

Alegeți adresa pe care o administrați de fapt

Trei proiecte arată similar și se comportă diferit: atingerea adresei publice a ASA-ului orientate spre VPN, atingerea unei interfețe interne prin IPsec și atingerea unei interfețe de administrare dedicate. Notați adresa sursă a administratorului, adresa exactă de destinație și TCP 22 înainte de a atinge vreo permisiune. Tot ce urmează depinde de acea pereche.

Un tunel care transportă două VLAN-uri de servere poate să nu transporte deloc adresa interfeței firewall-ului sau subrețeaua de administrare a administratorului. Verificați lista de trafic interesant a politicii sit-la-sit și confirmați că adresa proprie a ASA-ului apare ca destinație, nu doar subrețelele care trec prin el.

Deoarece destinația este firewall-ul însuși, admiterea administrării este separată de regulile pentru traficul redirecționat. O ACL care lasă clienții să ajungă la servere din spatele ASA-ului nu activează de la sine administrarea SSH a echipamentului, iar repararea regulii de redirecționare nu va muta această defecțiune.

management-access este specific interfeței

Comanda management-access îi spune ASA-ului să accepte conexiuni de administrare către o interfață numită atunci când sosesc prin VPN. Nu creează o rută, nu adaugă o permisiune SSH și nu se aplică tuturor interfețelor deodată. Dacă interfața de destinație nu este cea numită, conexiunea este aruncată înainte de autentificare.

Aici mușcă două excepții. Interfețele numai pentru administrare sunt în afara acestui mecanism, iar ghidul de administrare ASA 9.20 notează că stiva CiscoSSH implicită nu acceptă SSH între interfețe prin VPN, în timp ce stiva ASA SSH o face. Confirmați stiva activă pe versiunea implementată înainte de a petrece timp pe rute.

Patru porți înainte de promptul de autentificare

Între client și promptul de nume de utilizator stau patru porți independente: o potrivire de rută și tunel pentru perechea de administrare, o ACL de interfață care permite TCP 22 către adresa ASA-ului, o permisiune ssh care acoperă sursa administratorului și o autentificare AAA pentru acel utilizator. Oricare dintre ele poate arunca pachetul fără a-i spune clientului care poartă s-a închis.

Folosiți packet-tracer pentru a vedea care poartă eșuează înainte de a schimba ceva: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Urmărirea numește ACL-ul, etapa NAT și decizia to-the-box, ceea ce de obicei este suficient pentru a separa o problemă de rutare de una de admitere.

Scrieți permisiunea îngustă, nu pe cea largă

Limitați permisiunea la subrețeaua administrativă aprobată și la interfața care primește traficul tunelului: ssh 10.10.5.0 255.255.255.0 inside. Asociați-o cu o metodă de autentificare precum aaa authentication ssh console LOCAL și un cont local numit, în loc să deschideți fiecare sursă pe interfața externă.

Păstrați consecvente ACL-ul de interfață și permisiunea ssh. O permisiune pentru o subrețea pe care ACL-ul o blochează eșuează în continuare, iar o ACL care permite subrețeaua fără o intrare ssh corespunzătoare eșuează la poarta următoare. Ambele afirmații descriu același drum din straturi diferite, așa că examinați-le împreună în configurația care rulează.

Verificați de pe gazda numită, apoi restrângeți din nou

Deschideți o sesiune nouă de pe gazda de administrare numită, nu de la biroul dumneavoastră, și confirmați pe ASA ce adresă sursă și ce interfață a folosit conexiunea. Verificați sesiunile active și secțiunea SSH a configurației care rulează cât timp sesiunea este deschisă, apoi închideți-o și eliminați orice permisiune temporară adăugată pentru teste. Dacă sesiunea apare dar cade imediat după autentificare, problema rămasă este autorizarea, nu accesibilitatea. Înregistrați interfața și sursa în jurnalul de modificări, ca următoarea persoană să nu repete diagnosticul.

Țineți consola sau o altă cale de recuperare aprobată independent disponibilă pe toată durata modificării. După ce calea privată funcționează, confirmați că sursele publice și utilizatorii VPN necorelați nu au obținut același acces, pentru că o cale de administrare care funcționează pentru toți este o problemă diferită de cea cu care ați început.