Arver et VPN-undernett ASA-grensesnittets sikkerhetsnivå?

Et dekryptert VPN-undernett arver aldri sikkerhetsnivået til et grensesnitt. Kontroller sysopt connection permit-vpn, gruppefilteret og administrasjonstilgang hver for seg.

Noen spør om filialens VPN-undernett har «sikkerhetsnivå 0 eller 100» på ASA-en, og spørsmålet inneholder allerede feilen. Sikkerhetsnivå er en egenskap ved et lokalt grensesnitt og tildeles 0 til 100 i grensesnittkonfigurasjonen. Et eksternt undernett som kommer gjennom en tunnel får ikke noe, uansett hvordan crypto map er skrevet. Derfor har spørsmålet ikke noe numerisk svar.

Det praktiske oppfølgingsspørsmålet er bedre: hvilken policy slipper filialen til serveren, og hvilken holder den borte fra brannmuren selv. Det er to svar, og prosedyren nedenfor skiller dem.

Sikkerhetsnivåer hører til grensesnitt

Kjør show running-config interface, og du vil se security-level under hvert fysiske grensesnitt eller VLAN-grensesnitt, ikke under tunnelgruppen eller crypto map. Standardtillatelsen fra høyere til lavere vurderes mellom disse grensesnittene, og derfor endrer tallet inspeksjons- og implisitt-ACL-atferden på banen det hører til.

For en dekryptert VPN-strøm er inngangen fortsatt det ytre grensesnittet der tunnelen avsluttes, og utgangen er det indre grensesnittet mot serveren. Skriv ned begge før du rører noe. Det ene trinnet fjerner det meste av forvirringen, fordi det gjør et abstrakt tillitsspørsmål om til et grensesnittpar.

ACL-omgåelsen har en navngitt grense

sysopt connection permit-vpn er innstillingen folk husker halvveis når de sier at VPN-trafikk ignorerer ACL-er. Den hopper riktignok over grensesnitt-ACL-en for trafikk som kvalifiserer som VPN-trafikk, og parameterveiledningen for 9.x begrenser den per grensesnitt og retning i stedet for å erklære et globalt unntak.

Kontroller hva som er konfigurert før du resonnerer fra hukommelsen:

  • show running-config all sysopt for å se den effektive verdien, ikke bare linjene som ikke er standard.
  • show running-config access-group for å se hvilken ACL som er brukt på hvilket grensesnitt og retning.
  • show vpn-sessiondb detail l2l for å bekrefte hvilken tunnelgruppe og filter sesjonen faktisk bruker.

Å slå av denne innstillingen for å stramme inn VPN-tilgang er en endring med stor rekkevidde. Den underlegger igjen hver kvalifiserte VPN-strøm den ytre ACL-en, noe som vanligvis ødelegger fungerende tunneler på måter som ikke har noe med filialen du ble spurt om å gjøre.

Les filteret som er knyttet til sesjonen

Den egentlige styringen per tunnel er VPN-filteret: en ACL som en gruppepolicy eller et brukernavn refererer til, brukt etter dekryptering og før kryptering. Et filter på brukernivå overstyrer verdien på gruppenivå, så to personer i samme tunnelgruppe kan ha ulik effektiv tilgang.

Bekreft forrangen i stedet for å anta den. show running-config group-policy <name> viser gruppeverdien, og show running-config username <name> viser om det finnes en verdi per bruker. Hvis begge finnes, vinner brukerverdien. Sammenlign deretter ACL-ens oppføringer med strømmen du bryr deg om, i retningen filteret vurderer.

Et filter som tillater applikasjonsserveren, sier ingenting om administrasjon. Det er separate regler på en separat bane.

Verifiser én tillatelse og én avvisning

Packet-tracer er den raskeste måten å se avgjørelsen på uten å vente på at en bruker rapporterer den. Gi den strømmen fra den dekrypterte siden, og la den navngi ACL-, NAT- og inspeksjonstrinnene den passerer.

  1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
  2. Les resultatlinjen: den navngir ACL-en som tillot eller droppet pakken.
  3. Gjenta med administrasjonsdestinasjonen på det indre grensesnittet og bekreft en avvisning.
  4. Gjenta én gang til etter hver endring, slik at både tilstanden før og etter blir registrert.

Deretter verifiser med virkelig trafikk: én vellykket applikasjonsforespørsel fra filialen og ett mislykket SSH-forsøk mot ASA-en. Packet-tracer modellerer banen; en levende strøm beviser at modellen stemte.

Rull tilbake endringen som fikk det til å virke

Hvis rettelsen var å deaktivere ACL-omgåelsen eller utvide et filter, behold den forrige konfigurasjonen. Et show run-opptak av de berørte objektene, lagret før endringen, er nok til å gjenopprette dem; ASA-konfigurasjon er linjeorientert, så tilbakerulling betyr å skrive inn de gamle linjene på nytt, ikke å gjenopprette en fil.

Noter grensesnittparet, det effektive filteret, ACL-navnet fra packet-tracer og de nøyaktige kommandoene du endret. Den registreringen gjør neste gjennomgang til en fem-minutters sjekk i stedet for nok en debatt om tillitsnivåer.

Relaterte artikler