SSH ke vzdálené ASA přes site VPN: krok za krokem

Nasměrujete SSH klienta na vnitřní adresu vzdálené ASA a relace zemře při připojení. Firewall odpovídá z vlastního site, tunel se objeví, a přesto na portu 22 nic neposlouchá. Ve většině těchto případů se paket nikdy nedostane k přijetí správy, protože testovaná cesta nikdy nebyla navržena jako cesta správy. Projděte níže uvedený tok v pořadí a porucha přestane cestovat.

Vyberte adresu, kterou skutečně spravujete

Tři návrhy vypadají podobně a chovají se odlišně: dosažení veřejné adresy ASA obrácené k VPN, dosažení vnitřního rozhraní přes IPsec a dosažení vyhrazeného rozhraní správy. Než se dotknete jakéhokoli oprávnění, zapište zdrojovou adresu správce, přesnou cílovou adresu a TCP 22. Všechno další závisí na této dvojici.

Tunel, který nese dvě serverové VLAN, nemusí vůbec nést adresu rozhraní firewallu ani podsíť správy správce. Zkontrolujte seznam zajímavého provozu pro politiku site-to-site a potvrďte, že se vlastní adresa ASA objevuje jako cíl, nejen podsítě, které přes něj procházejí.

Protože cílem je samotný firewall, přijetí správy je oddělené od pravidel pro předávaný provoz. ACL, které umožňuje klientům dosáhnout serverů za ASA, samo o sobě nepovoluje SSH správu zařízení, a oprava pravidla pro předávání tuto poruchu neposune.

management-access je vázán na rozhraní

Příkaz management-access říká ASA, aby přijímala spojení správy na pojmenovaném rozhraní, když přicházejí přes VPN. Nevytváří trasu, nepřidává oprávnění SSH a neplatí pro všechna rozhraní najednou. Pokud cílové rozhraní není to pojmenované, je spojení zahozeno ještě před autentizací.

Zde platí dvě výjimky. Rozhraní určená pouze pro správu jsou mimo tento mechanismus a průvodce správou ASA 9.20 uvádí, že výchozí zásobník CiscoSSH nepodporuje SSH mezi rozhraními přes VPN, zatímco zásobník ASA SSH ano. Než začnete trávit čas trasami, potvrďte aktivní zásobník v nasazeném vydání.

Čtyři brány před výzvou k přihlášení

Mezi klientem a výzvou k zadání uživatelského jména stojí čtyři nezávislé brány: shoda trasy a tunelu pro dvojici správy, ACL rozhraní, které povoluje TCP 22 na adresu ASA, oprávnění ssh pokrývající zdroj správce a autentizace AAA pro tohoto uživatele. Každá z nich může paket zahodit, aniž by klientovi řekla, která brána se zavřela.

Než cokoli změníte, podívejte se pomocí packet-tracer, která brána selhává: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Trasování pojmenuje ACL, fázi NAT a rozhodnutí to-the-box, což obvykle stačí k oddělení problému směrování od problému přijetí.

Pište úzké oprávnění, ne široké

Omezte oprávnění na schválenou administrativní podsíť a rozhraní, které přijímá provoz tunelu: ssh 10.10.5.0 255.255.255.0 inside. Spárujte je s metodou autentizace, jako je aaa authentication ssh console LOCAL, a pojmenovaným místním účtem, místo abyste otevřeli každý zdroj na vnějším rozhraní.

Udržujte ACL rozhraní a oprávnění ssh v souladu. Oprávnění pro podsíť, kterou ACL blokuje, stále selhává, a ACL, které povoluje podsíť bez odpovídající položky ssh, selhává u další brány. Obě tvrzení popisují stejnou cestu z různých vrstev, proto je zkontrolujte společně v běžící konfiguraci.

Ověřte z pojmenovaného hostitele a pak znovu zúžte

Otevřete novou relaci z pojmenovaného hostitele správy, ne ze svého stolu, a na ASA potvrďte, kterou zdrojovou adresu a rozhraní spojení použilo. Dokud je relace otevřená, zkontrolujte aktivní relace a sekci SSH běžící konfigurace, poté ji zavřete a odstraňte jakékoli dočasné oprávnění přidané pro testování. Pokud se relace objeví, ale spadne hned po přihlášení, zbývajícím problémem je autorizace, nikoli dostupnost. Zapište rozhraní a zdroj do záznamu o změnách, aby další člověk neopakoval diagnostiku.

Po celou dobu změny mějte k dispozici konzolu nebo jinou nezávisle schválenou cestu obnovy. Jakmile soukromá cesta funguje, potvrďte, že veřejné zdroje a nesouvisející uživatelé VPN nezískali stejný přístup, protože cesta správy, která funguje pro všechny, je jiný problém než ten, se kterým jste začali.