Ärver ett VPN-subnät ASA-gränssnittets säkerhetsnivå?

Ett dekrypterat VPN-subnät ärver aldrig ett gränssnitts säkerhetsnivå. Kontrollera sysopt connection permit-vpn, gruppfiltret och administrationsåtkomst var för sig.

Någon frågar om filialens VPN-subnät har ”säkerhetsnivå 0 eller 100” på ASA:n, och frågan innehåller redan felet. Säkerhetsnivå är en egenskap hos ett lokalt gränssnitt och tilldelas 0 till 100 i gränssnittskonfigurationen. Ett fjärrsubnät som kommer via en tunnel får ingen, oavsett hur crypto map är skriven. Därför har frågan inget numeriskt svar.

Den praktiska följdfrågan är bättre: vilken policy släpper in filialen till servern, och vilken håller den borta från brandväggen själv. Det är två svar, och proceduren nedan skiljer dem åt.

Säkerhetsnivåer tillhör gränssnitt

Kör show running-config interface och du ser security-level under varje fysiskt gränssnitt eller VLAN-gränssnitt, inte under tunnelgruppen eller crypto map. Standardtillåtelsen från högre till lägre utvärderas mellan dessa gränssnitt, och därför ändrar siffran inspektions- och implicit-ACL-beteendet på den väg den tillhör.

För ett dekrypterat VPN-flöde är ingången fortfarande det yttre gränssnittet där tunneln slutar, och utgången är det inre gränssnittet mot servern. Skriv ned båda innan du rör något. Det enda steget tar bort det mesta av förvirringen, eftersom det förvandlar en abstrakt förtroendefråga till ett gränssnittspar.

ACL-omgåelsen har en namngiven gräns

sysopt connection permit-vpn är inställningen folk minns halvt när de säger att VPN-trafik ignorerar ACL:er. Den hoppar visserligen över gränssnittets ACL för trafik som kvalificerar som VPN-trafik, och parameterhandboken för 9.x begränsar den per gränssnitt och riktning i stället för att deklarera ett globalt undantag.

Kontrollera vad som är konfigurerat innan du resonerar ur minnet:

  • show running-config all sysopt för att se det effektiva värdet, inte bara raderna som inte är standard.
  • show running-config access-group för att se vilken ACL som tillämpas på vilket gränssnitt och riktning.
  • show vpn-sessiondb detail l2l för att bekräfta vilken tunnelgrupp och vilket filter sessionen faktiskt använder.

Att stänga av den inställningen för att skärpa VPN-åtkomsten är en ändring med stor räckvidd. Den underställer igen varje kvalificerat VPN-flöde den yttre ACL:en, vilket vanligtvis bryter fungerande tunnlar på sätt som inte har med filialen du fick frågan om att göra.

Läs filtret som är kopplat till sessionen

Den egentliga styrningen per tunnel är VPN-filtret: en ACL som en gruppolicy eller ett användarnamn refererar till, tillämpad efter dekryptering och före kryptering. Ett filter på användarnivå åsidosätter värdet på gruppnivå, så två personer i samma tunnelgrupp kan ha olika effektiv åtkomst.

Bekräfta prioriteten i stället för att anta den. show running-config group-policy <name> visar gruppvärdet, och show running-config username <name> visar om ett värde per användare finns. Om båda finns vinner användarvärdet. Jämför sedan den ACL:ens poster med flödet du bryr dig om, i den riktning filtret utvärderar.

Ett filter som tillåter applikationsservern säger ingenting om administration. Det är separata regler på en separat väg.

Verifiera ett tillstånd och en nekad

Packet-tracer är det snabbaste sättet att se beslutet utan att vänta på att en användare rapporterar det. Ge det flödet från den dekrypterade sidan och låt det namnge de ACL-, NAT- och inspektionssteg det passerar.

  1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
  2. Läs resultatraden: den namnger den ACL som tillät eller släppte paketet.
  3. Upprepa med administrationsdestinationen på det inre gränssnittet och bekräfta en nekad.
  4. Upprepa en gång till efter varje ändring, så att både tillståndet före och efter registreras.

Verifiera sedan med verklig trafik: en lyckad applikationsbegäran från filialen och ett misslyckat SSH-försök mot ASA:n. Packet-tracer modellerar vägen; ett levande flöde bevisar att modellen stämde.

Rulla tillbaka ändringen som fick det att fungera

Om åtgärden var att inaktivera ACL-omgåelsen eller bredda ett filter, behåll den tidigare konfigurationen. En show run-bild av de berörda objekten, sparad före ändringen, räcker för att återställa dem; ASA-konfigurationen är linjeorienterad, så återställning innebär att skriva in de gamla raderna igen, inte att återställa en fil.

Anteckna gränssnittsparet, det effektiva filtret, ACL-namnet från packet-tracer och de exakta kommandon du ändrade. Den anteckningen gör nästa granskning till en femminuterskontroll i stället för ännu en debatt om förtroendenivåer.

Relaterade artiklar