SSH uz attālu ASA caur vietnes VPN: soli pa solim

Jūs vēršat SSH klientu uz attālā ASA iekšējo adresi, un sesija mirst pievienošanās laikā. Ugunsmūris atbild no savas vietnes, tunelis parādās, un tomēr 22. portā nekas neklausās. Lielākajā daļā šo gadījumu pakete nekad nesasniedz pārvaldības pielaišanu, jo pārbaudāmais ceļš nekad nav projektēts kā pārvaldības ceļš. Izstaigājiet zemāk esošo plūsmu secībā, un kļūda pārstās pārvietoties.

Izvēlieties adresi, kuru jūs patiešām pārvaldāt

Trīs dizaini izskatās līdzīgi un uzvedas atšķirīgi: sasniegt ASA publisko VPN vērsto adresi, sasniegt iekšējo saskarni caur IPsec un sasniegt atsevišķu pārvaldības saskarni. Pierakstiet administratora avota adresi, precīzo galamērķa adresi un TCP 22, pirms aiztiekat jebkuru atļauju. Viss turpmākais ir atkarīgs no šī pāra.

Tunelis, kas pārvadā divus serveru VLAN, var nemaz nepārvadāt ugunsmūra saskarnes adresi vai administratora pārvaldības apakštīklu. Pārbaudiet vietnes-uz-vietni politikas interesantās plūsmas sarakstu un apstipriniet, ka pašas ASA adrese parādās kā galamērķis, nevis tikai apakštīkli, kas iet caur to.

Tā kā galamērķis ir pats ugunsmūris, pārvaldības pielaišana ir atsevišķa no pārsūtītās plūsmas noteikumiem. ACL, kas ļauj klientiem sasniegt serverus aiz ASA, pats par sevi neieslēdz ierīces SSH pārvaldību, un pārsūtīšanas noteikuma labošana šo kļūdu nepārvietos.

management-access ir saskarnei specifiska

Komanda management-access liek ASA pieņemt pārvaldības savienojumus uz nosauktu saskarni, kad tie ierodas pa VPN. Tā neveido maršrutu, nepievieno SSH atļauju un neattiecas uz visām saskarnēm uzreiz. Ja galamērķa saskarne nav nosauktā, savienojums tiek izmests pirms autentifikācijas.

Šeit iedarbojas divi izņēmumi. Tikai pārvaldībai paredzētās saskarnes ir ārpus šī mehānisma, un ASA 9.20 pārvaldības rokasgrāmata norāda, ka noklusējuma CiscoSSH steks neatbalsta SSH starp saskarnēm pa VPN, kamēr ASA SSH steks to atbalsta. Apstipriniet aktīvo steku izvietotajā versijā, pirms veltāt laiku maršrutiem.

Četri vārti pirms pieteikšanās uzvednes

Starp klientu un lietotājvārda uzvedni stāv četri neatkarīgi vārti: maršruta un tuneļa atbilstība pārvaldības pārim, saskarnes ACL, kas atļauj TCP 22 uz ASA adresi, ssh atļauja, kas aptver administratora avotu, un AAA autentifikācija šim lietotājam. Katrs no tiem var nomest paketi, nepaziņojot klientam, kuri vārti aizvērās.

Pirms kaut ko maināt, apskatiet ar packet-tracer, kuri vārti cieš neveiksmi: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Pēda nosauc ACL, NAT posmu un to-the-box lēmumu, ar ko parasti pietiek, lai atdalītu maršrutēšanas problēmu no pielaišanas problēmas.

Rakstiet šauro atļauju, nevis plato

Ierobežojiet atļauju ar apstiprināto administratīvo apakštīklu un saskarni, kas saņem tuneļa plūsmu: ssh 10.10.5.0 255.255.255.0 inside. Savienojiet to pārī ar autentifikācijas metodi, piemēram, aaa authentication ssh console LOCAL, un nosauktu vietējo kontu, tā vietā lai ārējā saskarnē atvērtu katru avotu.

Turiet saskarnes ACL un ssh atļauju konsekventus. Atļauja apakštīklam, kuru ACL bloķē, joprojām cieš neveiksmi, un ACL, kas atļauj apakštīklu bez atbilstoša ssh ieraksta, cieš neveiksmi pie nākamajiem vārtiem. Abi apgalvojumi apraksta vienu ceļu no dažādiem slāņiem, tāpēc pārskatiet tos kopā darbojošā konfigurācijā.

Pārbaudiet no nosauktā resursdatora, tad atkal sašauriniet

Atveriet jaunu sesiju no nosauktā pārvaldības resursdatora, nevis no sava galda, un ASA apstipriniet, kuru avota adresi un saskarni izmantoja savienojums. Kamēr sesija ir atvērta, pārbaudiet aktīvās sesijas un darbojošās konfigurācijas SSH sadaļu, pēc tam aizveriet to un noņemiet jebkuru pagaidu atļauju, ko pievienojāt testēšanai. Ja sesija parādās, bet nokrīt uzreiz pēc pieteikšanās, atlikušā problēma ir autorizācija, nevis sasniedzamība. Pierakstiet saskarni un avotu izmaiņu žurnālā, lai nākamais cilvēks neatkārtotu diagnostiku.

Visas izmaiņas laikā turiet pieejamu konsoli vai citu neatkarīgi apstiprinātu atkopšanas ceļu. Kad privātais ceļš strādā, apstipriniet, ka publiskie avoti un nesaistīti VPN lietotāji nav ieguvuši tādu pašu piekļuvi, jo pārvaldības ceļš, kas strādā visiem, ir cita problēma nekā tā, ar kuru sākāt.