SSH til en fjern ASA gennem site-VPN: trin for trin

Du peger en SSH-klient mod den fjern ASA's interne adresse, og sessionen dør ved forbindelsen. Firewallen svarer fra sit eget site, tunnelen vises, og alligevel lytter intet på port 22. I de fleste af disse tilfælde når pakken aldrig frem til administrationsadgang, fordi den sti, der testes, aldrig blev designet som en administrationssti. Gå gennem flowet nedenfor i rækkefølge, og fejlen holder op med at flytte sig.

Vælg den adresse, du faktisk administrerer

Tre designs ligner hinanden og opfører sig forskelligt: at nå ASAs offentlige VPN-adresse, at nå et internt interface gennem IPsec og at nå et dedikeret administrationsinterface. Skriv administratorens kildeadresse, den præcise destinationsadresse og TCP 22 ned, før du rører en tilladelse. Alt senere afhænger af det par.

En tunnel, der bærer to server-VLAN'er, bærer måske slet ikke firewallens interfaceadresse eller administratorens administrationssubnet. Tjek listen over interessant trafik for site-til-site-politikken, og bekræft at ASAs egen adresse optræder som destination, ikke kun subnettet, der passerer igennem.

Fordi destinationen er firewallen selv, er administrationsadgang adskilt fra regler for videresendt trafik. En ACL, der lader klienter nå servere bag ASA'en, aktiverer ikke selvstændigt SSH-administration af enheden, og en rettelse af videresendelsesreglen flytter ikke denne fejl.

management-access er interface-specifik

Kommandoen management-access fortæller ASA'en at acceptere administrationsforbindelser til et navngivet interface, når de ankommer over VPN. Den opretter ikke en rute, den tilføjer ikke en SSH-tilladelse, og den gælder ikke for alle interfaces på én gang. Hvis destinationsinterfacet ikke er det navngivne, kasseres forbindelsen før godkendelse.

To undtagelser bider her. Interfaces kun til administration ligger uden for denne mekanisme, og ASA 9.20-administrationsvejledningen bemærker, at standard-CiscoSSH-stakken ikke understøtter SSH mellem interfaces over VPN, mens ASA SSH-stakken gør. Bekræft den aktive stak på den udrullede version, før du bruger tid på ruter.

Fire porte før loginprompten

Mellem klienten og brugernavnsprompten står fire uafhængige porte: et rute- og tunnelmatch for administrationsparret, en interface-ACL der tillader TCP 22 til ASA-adressen, en ssh-tilladelse der dækker administratorens kilde, og AAA-godkendelse for den bruger. Hver af dem kan droppe pakken uden at fortælle klienten, hvilken port der lukkede.

Brug packet-tracer til at se, hvilken port der fejler, før du ændrer noget: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Sporingen navngiver ACL'en, NAT-trinnet og to-the-box-beslutningen, hvilket normalt er nok til at skelne et ruteproblem fra et adgangsproblem.

Skriv den snævre tilladelse, ikke den brede

Begræns tilladelsen til det godkendte administrative subnet og det interface, der modtager tunnelens trafik: ssh 10.10.5.0 255.255.255.0 inside. Par den med en godkendelsesmetode som aaa authentication ssh console LOCAL og en navngivet lokal konto i stedet for at åbne hver kilde på det ydre interface.

Hold interface-ACL'en og ssh-tilladelsen konsistente. En tilladelse til et subnet, som ACL'en blokerer, fejler stadig, og en ACL, der tillader subnettet uden en matchende ssh-post, fejler ved den næste port. Begge udsagn beskriver den samme sti fra forskellige lag, så gennemgå dem sammen i den kørende konfiguration.

Verificer fra den navngivne vært, og indsnævr derefter igen

Åbn en ny session fra den navngivne administrationsvært i stedet for fra dit skrivebord, og bekræft på ASA'en, hvilken kildeadresse og hvilket interface forbindelsen brugte. Tjek de aktive sessioner og SSH-afsnittet i den kørende konfiguration, mens sessionen er oppe, luk den derefter, og fjern enhver midlertidig tilladelse, du tilføjede til test. Hvis sessionen vises, men falder lige efter login, er det resterende problem autorisation og ikke tilgængelighed. Registrer interfacet og kilden i ændringsloggen, så den næste person ikke gentager diagnosen.

Hold konsollen eller en anden uafhængigt godkendt gendannelsesvej tilgængelig gennem hele ændringen. Når den private sti virker, skal du bekræfte, at offentlige kilder og urelaterede VPN-brugere ikke fik samme adgang, fordi en administrationssti, der virker for alle, er et andet problem end det, du startede med.