Moștenește o subrețea VPN nivelul de securitate al interfeței ASA?

Cineva întreabă dacă subrețeaua VPN a sucursalei are „nivel de securitate 0 sau 100” pe ASA, iar întrebarea conține deja eroarea. Nivelul de securitate este o proprietate a unei interfețe locale și se atribuie de la 0 la 100 în configurația interfeței. O subrețea la distanță care sosește printr-un tunel nu dobândește niciunul, indiferent cum este scris crypto map. De aceea întrebarea nu are un răspuns numeric.

Întrebarea practică următoare este mai bună: ce politică admite sucursala către server și care o ține departe de firewall-ul însuși. Sunt două răspunsuri, iar procedura de mai jos le separă.

Nivelurile de securitate aparțin interfețelor

Rulați show running-config interface și veți vedea security-level sub fiecare interfață fizică sau interfață VLAN, nu sub grupul de tuneluri sau crypto map. Permisiunea implicită de la superior la inferior este evaluată între aceste interfețe, de aceea numărul schimbă comportamentul inspecției și al ACL-ului implicit pe calea căreia îi aparține.

Pentru un flux VPN decriptat, intrarea rămâne interfața outside unde se termină tunelul, iar ieșirea este interfața inside spre server. Notați ambele înainte de a atinge ceva. Acest singur pas elimină cea mai mare parte a confuziei, pentru că transformă o întrebare abstractă de încredere într-o pereche de interfețe.

Ocolirea ACL are o graniță cu nume

sysopt connection permit-vpn este setarea pe care oamenii o țin minte pe jumătate când spun că traficul VPN ignoră ACL-urile. Chiar sare peste ACL-ul interfeței pentru traficul care se califică drept trafic VPN, iar ghidul de parametri 9.x îl limitează pe interfață și direcție în loc să declare o excepție globală.

Verificați ce este configurat înainte de a raționa din memorie:

• show running-config all sysopt pentru a vedea valoarea efectivă, nu doar liniile care nu sunt implicite.
• show running-config access-group pentru a vedea ce ACL este aplicat pe ce interfață și direcție.
• show vpn-sessiondb detail l2l pentru a confirma ce grup de tuneluri și ce filtru folosește de fapt sesiunea.

Dezactivarea acestei setări pentru a strânge accesul VPN este o modificare cu impact mare. Supune din nou fiecare flux VPN calificat ACL-ului exterior, ceea ce de obicei strică tunelurile care funcționează în moduri fără legătură cu sucursala despre care ați fost întrebat.

Citiți filtrul atașat sesiunii

Controlul real pe tunel este filtrul VPN: un ACL la care face referire politica de grup sau numele de utilizator, aplicat după decriptare și înainte de criptare. Un filtru la nivel de utilizator înlocuiește valoarea la nivel de grup, așa că două persoane din același grup de tuneluri pot avea acces efectiv diferit.

Confirmați precedența în loc să o presupuneți. show running-config group-policy <name> arată valoarea grupului, iar show running-config username <name> arată dacă există o valoare pe utilizator. Dacă există ambele, câștigă valoarea utilizatorului. Apoi comparați intrările acelui ACL cu fluxul care vă interesează, în direcția în care evaluează filtrul.

Un filtru care permite serverul de aplicații nu spune nimic despre administrare. Sunt reguli separate pe o cale separată.

Verificați o permisiune și o respingere

Packet-tracer este cea mai rapidă cale de a vedea decizia fără a aștepta ca un utilizator să o raporteze. Dați-i fluxul din partea decriptată și lăsați-l să numească etapele de ACL, NAT și inspecție prin care trece.

1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
2. Citiți linia rezultatului: numește ACL-ul care a permis sau a eliminat pachetul.
3. Repetați cu destinația administrativă pe interfața inside și confirmați o respingere.
4. Repetați încă o dată după orice modificare, astfel încât atât starea dinainte, cât și cea de după să fie înregistrate.

Apoi verificați cu trafic real: o cerere de aplicație reușită din sucursală și o încercare SSH eșuată către ASA. Packet-tracer modelează calea; un flux activ dovedește că modelul s-a potrivit.

Reveniți asupra modificării care l-a făcut să funcționeze

Dacă remedierea a fost dezactivarea ocolirii ACL sau lărgirea unui filtru, păstrați configurația anterioară. O captură show run a obiectelor afectate, salvată înainte de modificare, este suficientă pentru a le restaura; configurația ASA este orientată pe linii, așa că revenirea înseamnă reintroducerea liniilor vechi, nu restaurarea unui fișier.

Înregistrați perechea de interfețe, filtrul efectiv, numele ACL-ului din packet-tracer și comenzile exacte pe care le-ați modificat. Acea înregistrare transformă următoarea revizuire într-o verificare de cinci minute în loc de o altă dezbatere despre nivelurile de încredere.