SSH į nuotolinę ASA per svetainės VPN: žingsnis po žingsnio

Nukreipiate SSH klientą į nuotolinio ASA vidinį adresą ir sesija miršta jungiantis. Užkarda atsako iš savo svetainės, tunelis pasirodo, o vis dėlto 22 prievade niekas neklauso. Daugeliu šių atvejų paketas niekada nepasiekia valdymo priėmimo, nes testuojamas kelias niekada nebuvo suprojektuotas kaip valdymo kelias. Eikite žemiau pateiktu srautu iš eilės ir gedimas nustos judėti.

Pasirinkite adresą, kurį iš tikrųjų administruojate

Trys projektai atrodo panašiai ir elgiasi skirtingai: pasiekti viešąjį ASA adresą, nukreiptą į VPN, pasiekti vidinę sąsają per IPsec ir pasiekti atskirą valdymo sąsają. Užsirašykite administratoriaus šaltinio adresą, tikslų paskirties adresą ir TCP 22 prieš liesdami bet kokį leidimą. Viskas, kas toliau, priklauso nuo šios poros.

Tunelis, kuris perneša du serverių VLAN, gali visai nepernešti užkardos sąsajos adreso ar administratoriaus valdymo potinklio. Patikrinkite svetainės į svetainę politikos įdomaus srauto sąrašą ir patvirtinkite, kad pats ASA adresas rodomas kaip paskirties vieta, o ne tik potinkliai, einantys per jį.

Kadangi paskirties vieta yra pati užkarda, valdymo priėmimas atskirtas nuo perduodamo srauto taisyklių. ACL, leidžiantis klientams pasiekti serverius už ASA, savaime neįjungia įrenginio SSH administravimo, o persiuntimo taisyklės taisymas šio gedimo nepajudins.

management-access susijęs su sąsaja

Komanda management-access nurodo ASA priimti valdymo ryšius į nurodytą sąsają, kai jie ateina per VPN. Ji nesukuria maršruto, neprideda SSH leidimo ir netaikoma visoms sąsajoms vienu metu. Jei paskirties sąsaja nėra nurodytoji, ryšys atmetamas prieš autentifikavimą.

Čia veikia dvi išimtys. Tik valdymui skirtos sąsajos yra už šio mechanizmo ribų, o ASA 9.20 valdymo vadovas pažymi, kad numatytasis CiscoSSH rinkinys nepalaiko SSH tarp sąsajų per VPN, o ASA SSH rinkinys palaiko. Patvirtinkite aktyvų rinkinį įdiegtoje versijoje prieš skirdami laiko maršrutams.

Keturi vartai prieš prisijungimo raginį

Tarp kliento ir vartotojo vardo raginio stovi keturi nepriklausomi vartai: maršruto ir tunelio atitikimas valdymo porai, sąsajos ACL, leidžiantis TCP 22 į ASA adresą, ssh leidimas, apimantis administratoriaus šaltinį, ir AAA autentifikavimas tam vartotojui. Kiekvienas jų gali numesti paketą nepasakęs klientui, kurie vartai užsidarė.

Prieš ką nors keisdami, pažiūrėkite su packet-tracer, kurie vartai žlunga: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Pėdsakas įvardija ACL, NAT etapą ir to-the-box sprendimą, ko paprastai pakanka maršrutizavimo problemai atskirti nuo priėmimo problemos.

Rašykite siaurą leidimą, o ne platų

Apribokite leidimą patvirtintu administraciniu potinkliu ir sąsaja, kuri priima tunelio srautą: ssh 10.10.5.0 255.255.255.0 inside. Suderinkite jį su autentifikavimo metodu, pavyzdžiui, aaa authentication ssh console LOCAL, ir įvardyta vietine paskyra, o ne atidarykite kiekvieną šaltinį išorinėje sąsajoje.

Laikykite sąsajos ACL ir ssh leidimą nuoseklius. Leidimas potinkliui, kurį ACL blokuoja, vis tiek žlunga, o ACL, leidžiantis potinklį be atitinkamo ssh įrašo, žlunga prie kitų vartų. Abu teiginiai aprašo tą patį kelią iš skirtingų sluoksnių, todėl peržiūrėkite juos kartu veikiančioje konfigūracijoje.

Patikrinkite iš įvardyto pagrindinio kompiuterio, tada vėl susiaurinkite

Atidarykite naują sesiją iš įvardyto valdymo pagrindinio kompiuterio, o ne nuo savo stalo, ir ASA patvirtinkite, kurį šaltinio adresą ir sąsają naudojo ryšys. Kol sesija atidaryta, patikrinkite aktyvias sesijas ir veikiančios konfigūracijos SSH skyrių, tada ją uždarykite ir pašalinkite visus laikinus leidimus, kuriuos pridėjote testavimui. Jei sesija atsiranda, bet nukrinta iškart po prisijungimo, likusi problema yra autorizacija, o ne pasiekiamumas. Užrašykite sąsają ir šaltinį pakeitimų žurnale, kad kitas žmogus nekartotų diagnostikos.

Viso pakeitimo metu laikykite pasiekiamą konsolę ar kitą nepriklausomai patvirtintą atkūrimo kelią. Kai privatus kelias pradės veikti, patvirtinkite, kad vieši šaltiniai ir nesusiję VPN vartotojai negavo tokios pačios prieigos, nes valdymo kelias, veikiantis visiems, yra kita problema nei ta, su kuria pradėjote.