Hvilken ASA-regel ser trafikken etter at VPN har dekryptert den

Den første antakelsen du bør slippe, er at krypto-ACL-en er en tilgangspolicy. Det er den ikke. På en Cisco ASA svarer den listen på ett smalt spørsmål: hvilke pakker fortjener beskyttelse, og svaret sier ingenting om hvorvidt den dekrypterte pakken kan nå serveren bak brannmuren. Tilgang avgjøres senere, av en grensesnittpolicy, av et gruppepolicyfilter eller av begge, avhengig av hvordan tunnelen ble bygget.

Krypto-ACL-en svarer på et annet spørsmål

En krypto-ACL er en matchliste. Den forteller tunnelen hva som skal krypteres mellom to parter; en pakke som ikke samsvarer med den, er rett og slett ikke beskyttet. Å utvide den endrer beskyttelsens omfang og ingenting annet.

Derfor kan det å legge til et subnett der få en tunnel opp mens selve applikasjonen fortsatt feiler. Tunnelen er oppe fordi det nå finnes en match. Applikasjonen feiler fortsatt fordi ingenting på den listen tillater noe. To forskjellige spørsmål, besvart av to forskjellige lister.

Hva bypass-innstillingen egentlig hopper over

sysopt connection permit-vpn lar beskyttet trafikk hoppe over grensesnitt-ACL-kontrollen som ellers ville gjelde på inngående side. Det er en bekvemmelighet for VPN-utrullinger, og den er global. Den rører ikke gruppepolicyen og rører ikke et autorisasjonsfilter per bruker.

Les den faktiske verdien i stedet for antakelsen: show running-config all sysopt skriver ut innstillingen selv når den aldri er konfigurert eksplisitt, og det er der mye forvirring starter.

Siden innstillingen er global, er det en dårlig handel å teste den som et raskt eksperiment på ett feilende subnett. Enhver annen tunnel på den brannmuren deler resultatet. Spar den til en bevisst endring med en tilbakerullingsplan.

Les filteret i den dekrypterte retningen

Et LAN-to-LAN vpn-filter skrives fra tunnelens synspunkt, ikke grensesnittets. Det eksterne nettet står i kildeplasseringen og det lokale nettet i målplasseringen, fordi det er slik pakken ser ut etter dekryptering. Det samme filteret evalueres deretter på nytt i motsatt retning før kryptering, med adressenes roller byttet om.

Portbetingelser fortjener mer omhu enn en kopiert grensesnitt-ACL, nettopp av den grunn. En regel som tillater én målport kan ha en utilsiktet virkning i motsatt retning, der en ny tilkobling bruker den porten som kilde. Skriv ned hvilken side som kan initiere, den faktiske tjenesten og motparten som må forbli lukket, før du bygger listen.

Bekreft hvilket filter som faktisk er tilknyttet: show running-config group-policy og show vpn-sessiondb detail l2l forteller sammen hva sesjonen har arvet. Å redigere en ACL som ingen policy refererer til, endrer ingenting.

Ikke gjenbruk ett ACL-objekt til to oppgaver

Et grensesnitt-access-group og et vpn-filter ser ut som samme type objekt og evalueres på forskjellige punkter med ulik adresseorientering. Å tildele én liste til begge inviterer til en endring som reparerer tunnelen og stille løsner det fysiske grensesnittet.

Hold dem atskilt, navngi dem etter oppgaven, og la forskjellen i retning være synlig i navnene.

Verifiser med nye tilkoblinger, i begge retninger

Etter en planlagt endring, åpne én ny tilkobling som skal tillates og én ny tilkobling som skal avvises, og noter deretter adressene, retningen og policysamsvaret sammen med resultatet. En etablert sesjon beviser ingenting om filtrering av nye tilkoblinger, fordi den allerede ble sluppet inn under de gamle reglene.

Regn også med inspeksjon. Leverandørens dokumentasjon bemerker at et VPN-filter kontrollerer den innledende tilkoblingen og ikke hver sekundære tilkobling som en inspeksjonsmotor åpner, så en kontrollkanal og dens tilhørende mediestrøm kan få ulik behandling. Hvis applikasjonen kjenner protokollen, test den faktiske strømmen i stedet for en enkelt portsonde.

En tunnel som blir brukbar etter en bred bypass, forteller deg at begrensningen ble fjernet, ikke at den ble oppfylt. Resultatet som er verdt å beholde, er et navngitt håndhevelsespunkt du kan peke på i neste gjennomgang.