SSH till en extern ASA via platsens VPN: steg för steg

Du pekar en SSH-klient mot den externa ASA:ns interna adress och sessionen dör vid anslutningen. Brandväggen svarar från sin egen plats, tunneln syns, och ändå lyssnar ingenting på port 22. I de flesta av dessa fall når paketet aldrig administrationssläppet, eftersom vägen som testas aldrig konstruerades som en administrationsväg. Följ flödet nedan i ordning och felet slutar flytta sig.

Välj den adress du faktiskt administrerar

Tre konstruktioner ser lika ut och beter sig olika: att nå ASA:ns offentliga VPN-adress, att nå ett internt gränssnitt via IPsec och att nå ett dedikerat administrationsgränssnitt. Skriv ned administratörens källadress, den exakta destinationsadressen och TCP 22 innan du rör ett tillstånd. Allt senare beror på det paret.

En tunnel som bär två server-VLAN kanske inte alls bär brandväggens gränssnittsadress eller administratörens administrationssubnät. Kontrollera listan över intressant trafik för plats-till-plats-policyn och bekräfta att ASA:ns egen adress visas som destination, inte bara subnäten som passerar genom den.

Eftersom destinationen är brandväggen själv är administrationssläppet skilt från reglerna för vidarebefordrad trafik. En ACL som släpper klienter till servrar bakom ASA:n aktiverar inte SSH-administration av enheten på egen hand, och att rätta vidarebefordringsregeln flyttar inte detta fel.

management-access är gränssnittsspecifik

Kommandot management-access säger åt ASA:n att acceptera administrationsanslutningar till ett namngivet gränssnitt när de kommer via VPN. Det skapar ingen rutt, det lägger inte till ett SSH-tillstånd och det gäller inte för alla gränssnitt samtidigt. Om destinationsgränssnittet inte är det namngivna kastas anslutningen före autentiseringen.

Två undantag biter här. Gränssnitt endast för administration ligger utanför denna mekanism, och administrationsguiden för ASA 9.20 noterar att standard-CiscoSSH-stacken inte stöder SSH mellan gränssnitt över VPN, medan ASA SSH-stacken gör det. Bekräfta den aktiva stacken på den utrullade versionen innan du lägger tid på rutter.

Fyra portar före inloggningsprompten

Mellan klienten och användarnamsprompten står fyra oberoende portar: en rutt- och tunnelmatchning för administrationsparet, en gränssnitts-ACL som tillåter TCP 22 till ASA-adressen, ett ssh-tillstånd som täcker administratörens källa och AAA-autentisering för den användaren. Var och en kan släppa paketet utan att tala om för klienten vilken port som stängdes.

Använd packet-tracer för att se vilken port som fallerar innan du ändrar något: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Spårningen namnger ACL:n, NAT-steget och to-the-box-beslutet, vilket vanligtvis räcker för att skilja ett ruttproblem från ett släppproblem.

Skriv det snäva tillståndet, inte det breda

Begränsa tillståndet till det godkända administrativa subnätet och det gränssnitt som tar emot tunnelns trafik: ssh 10.10.5.0 255.255.255.0 inside. Koppla det till en autentiseringsmetod som aaa authentication ssh console LOCAL och ett namngivet lokalt konto, i stället för att öppna varje källa på det yttre gränssnittet.

Håll gränssnitts-ACL:n och ssh-tillståndet konsekventa. Ett tillstånd för ett subnät som ACL:n blockerar fallerar fortfarande, och en ACL som tillåter subnätet utan en matchande ssh-post fallerar vid nästa port. Båda påståendena beskriver samma väg från olika lager, så granska dem tillsammans i den körande konfigurationen.

Verifiera från den namngivna värden och snäva sedan in igen

Öppna en ny session från den namngivna administrationsvärden i stället för från ditt skrivbord, och bekräfta på ASA:n vilken källadress och vilket gränssnitt anslutningen använde. Kontrollera de aktiva sessionerna och SSH-avsnittet i den körande konfigurationen medan sessionen är öppen, stäng den sedan och ta bort eventuella tillfälliga tillstånd du lade till för testningen. Om sessionen visas men faller direkt efter inloggningen är det återstående problemet auktorisering och inte nåbarhet. Anteckna gränssnittet och källan i ändringsloggen så att nästa person inte upprepar diagnosen.

Håll konsolen eller en annan oberoende godkänd återställningsväg tillgänglig under hela ändringen. När den privata vägen fungerar, bekräfta att offentliga källor och orelaterade VPN-användare inte fick samma åtkomst, eftersom en administrationsväg som fungerar för alla är ett annat problem än det du började med.