SSH al fora ASA tra la eja VPN: paŝo post paŝo

Vi direktas SSH-klienton al la interna adreso de la fora ASA kaj la seanco mortas ĉe konekto. La fajroŝirmilo respondas el sia propra ejo, la tunelo aperas, kaj tamen nenio aŭskultas sur pordo 22. En plej multaj el ĉi tiuj kazoj la paketo neniam atingas administran akcepton, ĉar la vojo testata neniam estis desegnita kiel administra vojo. Sekvu la fluon sube laŭ ordo kaj la fiasko ĉesos moviĝi.

Elektu la adreson, kiun vi efektive administras

Tri desegnoj aspektas similaj kaj kondutas malsame: atingi la publikan VPN-adreson de la ASA, atingi internan interfacon tra IPsec, kaj atingi dediĉitan administran interfacon. Notu la fontadreson de la administranto, la precizan celadreson kaj TCP 22 antaŭ ol tuŝi permeson. Ĉio poste dependas de tiu paro.

Tunelo, kiu portas du servilajn VLAN-ojn, eble tute ne portas la interfacan adreson de la fajroŝirmilo aŭ la administran subreton de la administranto. Kontrolu la liston de interesa trafiko por la eja-al-eja politiko kaj konfirmu, ke la propra adreso de la ASA aperas kiel celo, ne nur la subretoj, kiuj trapasas ĝin.

Ĉar la celo estas la fajroŝirmilo mem, administra akcepto estas aparta de reguloj por plusendita trafiko. ACL, kiu lasas klientojn atingi servilojn malantaŭ la ASA, ne memstare ebligas SSH-administradon de la aparato, kaj riparo de la plusenda regulo ne movos ĉi tiun fiaskon.

management-access estas interfaca

La komando management-access diras al la ASA akcepti administrajn konektojn al nomita interfaco, kiam ili alvenas tra VPN. Ĝi ne kreas itineron, ĝi ne aldonas SSH-permeson, kaj ĝi ne validas por ĉiu interfaco samtempe. Se la cela interfaco ne estas la nomita, la konekto estas forĵetita antaŭ aŭtentigo.

Du esceptoj mordas ĉi tie. Nur-administraj interfacoj estas ekster ĉi tiu mekanismo, kaj la administra gvidilo de ASA 9.20 rimarkigas, ke la defaŭlta CiscoSSH stako ne subtenas SSH inter interfacoj tra VPN, dum la ASA SSH stako subtenas. Konfirmu la aktivan stakon sur la deplojita versio antaŭ ol pasigi tempon sur itineroj.

Kvar pordegoj antaŭ la ensaluta prompto

Inter la kliento kaj la salutnoma prompto staras kvar sendependaj pordegoj: itinera kaj tunela kongruo por la administra paro, interfaca ACL, kiu permesas TCP 22 al la ASA-adreso, ssh-permeso kovranta la fonton de la administranto, kaj AAA-aŭtentigo por tiu uzanto. Ĉiu el ili povas forĵeti la paketon sen diri al la kliento, kiu pordego fermiĝis.

Uzu packet-tracer por vidi, kiu pordego fiaskas antaŭ ol ŝanĝi ion ajn: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. La spuro nomas la ACL, la NAT-etapon kaj la decidon to-the-box, kio kutime sufiĉas por disigi itineran problemon de akcepta problemo.

Skribu la mallarĝan permeson, ne la larĝan

Limigu la permeson al la aprobita administra subreto kaj al la interfaco, kiu ricevas la tunelan trafikon: ssh 10.10.5.0 255.255.255.0 inside. Parigu ĝin kun aŭtentiga metodo kiel aaa authentication ssh console LOCAL kaj nomita loka konto, anstataŭ malfermi ĉiun fonton sur la ekstera interfaco.

Tenadu la interfacan ACL kaj la ssh-permeson konsekvencaj. Permeso por subreto, kiun la ACL blokas, ankoraŭ fiaskas, kaj ACL, kiu permesas la subreton sen kongrua ssh-enskribo, fiaskas ĉe la sekva pordego. Ambaŭ asertoj priskribas la saman vojon el malsamaj tavoloj, do revizuu ilin kune en la kuranta konfiguracio.

Kontrolu el la nomita gastiganto, poste mallarĝigu denove

Malfermu freŝan seanon el la nomita administra gastiganto anstataŭ el via skribotablo, kaj konfirmu sur la ASA, kiun fontadreson kaj interfacon la konekto uzis. Kontrolu la aktivajn seancojn kaj la SSH-sekcion de la kuranta konfiguracio dum la seanco estas malfermita, poste fermu ĝin kaj forigu ĉiun provizoran permeson, kiun vi aldonis por testado. Se la seanco aperas sed falas tuj post ensaluto, la restanta problemo estas rajtigo, ne atingebleco. Registru la interfacon kaj la fonton en la ŝanĝoprotokolo, por ke la sekva persono ne ripetu la diagnozon.

Tenu konsolon aŭ alian sendepende aprobitan restarigan vojon disponebla dum la tuta ŝanĝo. Post kiam la privata vojo funkcias, konfirmu, ke publikaj fontoj kaj ne rilataj VPN-uzantoj ne akiris la saman aliron, ĉar administra vojo, kiu funkcias por ĉiuj, estas malsama problemo ol tiu, kun kiu vi komencis.