Erft een VPN-subnet het beveiligingsniveau van de ASA-interface?

Iemand vraagt of het VPN-subnet van de vestiging ‘beveiligingsniveau 0 of 100’ heeft op de ASA, en de vraag bevat al de fout. Beveiligingsniveau is een eigenschap van een lokale interface en wordt in de interfaceconfiguratie van 0 tot 100 toegekend. Een extern subnet dat via een tunnel binnenkomt, krijgt er geen, hoe de crypto map ook is geschreven. Daarom heeft de vraag geen numeriek antwoord.

De praktische vervolgvraag is beter: welk beleid laat de vestiging naar de server door, en welk houdt haar weg van de firewall zelf. Dat zijn twee antwoorden, en de procedure hieronder scheidt ze.

Beveiligingsniveaus horen bij interfaces

Voer show running-config interface uit en u ziet security-level onder elke fysieke interface of VLAN-interface, niet onder de tunnelgroep of de crypto map. De standaardtoestemming van hoog naar laag wordt tussen die interfaces geëvalueerd, daarom verandert het getal het gedrag van inspectie en impliciete ACL op het pad waartoe het behoort.

Voor een ontsleutelde VPN-stroom blijft de ingang de outside-interface waar de tunnel eindigt, en de uitgang is de inside-interface naar de server. Schrijf beide op voordat u iets aanraakt. Die ene stap haalt het grootste deel van de verwarring weg, omdat hij een abstracte vertrouwensvraag in een interfacepaar verandert.

De ACL-omzeiling heeft een benoemde grens

sysopt connection permit-vpn is de instelling die mensen half onthouden wanneer ze zeggen dat VPN-verkeer ACL’s negeert. Hij slaat inderdaad de interface-ACL over voor verkeer dat als VPN-verkeer kwalificeert, en de parameterhandleiding voor 9.x begrenst hem per interface en richting in plaats van een globale uitzondering te verklaren.

Controleer wat er is geconfigureerd voordat u uit het geheugen redeneert:

• show running-config all sysopt om de werkelijke waarde te zien, niet alleen de niet-standaardregels.
• show running-config access-group om te zien welke ACL op welke interface en richting is toegepast.
• show vpn-sessiondb detail l2l om te bevestigen welke tunnelgroep en welk filter de sessie werkelijk gebruikt.

Die instelling uitschakelen om VPN-toegang strakker te zetten is een wijziging met grote impact. Hij onderwerpt elke kwalificerende VPN-stroom opnieuw aan de buiten-ACL, wat werkende tunnels meestal breekt op manieren die niets met de vestiging te maken hebben waarover u werd gevraagd.

Lees het filter dat aan de sessie hangt

De echte besturing per tunnel is het VPN-filter: een ACL waarnaar een groepsbeleid of een gebruikersnaam verwijst, toegepast na ontsleuteling en voor versleuteling. Een filter op gebruikersniveau overschrijft de waarde op groepsniveau, zodat twee mensen in dezelfde tunnelgroep verschillende effectieve toegang kunnen hebben.

Bevestig de voorrang in plaats van die aan te nemen. show running-config group-policy <name> toont de groepswaarde, en show running-config username <name> toont of er een waarde per gebruiker bestaat. Als beide bestaan, wint de gebruikerswaarde. Vergelijk daarna de vermeldingen van die ACL met de stroom die u interesseert, in de richting waarin het filter beoordeelt.

Een filter dat de applicatieserver toestaat, zegt niets over beheer. Dat zijn aparte regels op een apart pad.

Verifieer één toestemming en één weigering

Packet-tracer is de snelste manier om de beslissing te zien zonder te wachten tot een gebruiker die meldt. Geef het de stroom van de ontsleutelde kant en laat het de ACL-, NAT- en inspectiefasen benoemen die het doorloopt.

1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
2. Lees de resultaatregel: die noemt de ACL die het pakket heeft toegestaan of weggegooid.
3. Herhaal met de beheurbestemming op de inside-interface en bevestig een weigering.
4. Herhaal nog één keer na elke wijziging, zodat zowel de toestand voor als na is vastgelegd.

Verifieer daarna met echt verkeer: één geslaagde applicatieaanvraag vanaf de vestiging en één mislukte SSH-poging naar de ASA. Packet-tracer modelleert het pad; een levende stroom bewijst dat het model klopte.

Draai de wijziging terug die het liet werken

Als de oplossing was het uitschakelen van de ACL-omzeiling of het verbreden van een filter, houd dan de vorige configuratie. Een show run-opname van de betrokken objecten, bewaard voor de wijziging, is genoeg om ze te herstellen; de ASA-configuratie is regelgeoriënteerd, dus terugdraaien betekent de oude regels opnieuw invoeren, niet een bestand herstellen.

Leg het interfacepaar, het effectieve filter, de ACL-naam uit packet-tracer en de exacte opdrachten die u hebt gewijzigd vast. Die vastlegging maakt de volgende beoordeling een controle van vijf minuten in plaats van weer een debat over vertrouwensniveaus.