Kva ASA-regel ser trafikken etter at VPN har dekryptert han

Den første føresetnaden du bør sleppe, er at krypto-ACL-en er ein tilgangspolitikk. Det er han ikkje. På ein Cisco ASA svarar den lista på eitt smalt spørsmål: kva pakkar som fortener vern, og svaret seier ingenting om den dekrypterte pakken kan nå tenaren bak brannmuren. Tilgang vert avgjort seinare, av ein grensesnittpolitikk, av eit gruppepolitikkfilter eller av begge, alt etter korleis tunnelen vart bygd.

Krypto-ACL-en svarar på eit anna spørsmål

Ein krypto-ACL er ei samsvarsliste. Ho fortel tunnelen kva som skal krypterast mellom to partar; ein pakke som ikkje samsvarar med ho, er rett og slett ikkje verna. Å utvide ho endrar omfanget av vernet og ingenting anna.

Difor kan det å leggje til eit subnett der få ein tunnel opp medan sjølve applikasjonen framleis feilar. Tunnelen er oppe fordi det no finst ein samsvarsverdi. Applikasjonen feilar framleis fordi ingenting på den lista tillèt noko. To ulike spørsmål, svara av to ulike lister.

Kva bypass-innstillinga eigentleg hoppar over

sysopt connection permit-vpn lèt verna trafikk hoppe over grensesnitt-ACL-kontrollen som elles ville gjelde på inngåande side. Det er ei lettvint løysing for VPN-utrullingar, og ho er global. Ho rører ikkje gruppepolitikken og rører ikkje eit autorisasjonsfilter per brukar.

Les den faktiske verdien i staden for føresetnaden: show running-config all sysopt skriv ut innstillinga sjølv når ho aldri har vore konfigurert eksplisitt, og det er der mykje forvirring startar.

Sidan innstillinga er global, er det ein dårleg handel å teste ho som eit raskt eksperiment på eitt feilande subnett. Kvar annan tunnel på den brannmuren deler resultatet. Spar ho til ei medviten endring med ein tilbakerullingsplan.

Les filteret i den dekrypterte retninga

Eit LAN-to-LAN vpn-filter vert skrive frå synsvinkelen til tunnelen, ikkje grensesnittet. Det eksterne nettet står i kjeldeplasseringa og det lokale nettet i målplasseringa, fordi det er slik pakken ser ut etter dekryptering. Det same filteret vert deretter vurdert på nytt i motsett retning før kryptering, med rollene til adressene bytte om.

Portvilkår fortener meir omtanke enn ein kopiert grensesnitt-ACL, nettopp av den grunn. Ei regel som tillèt éin målport kan ha ei utilsikta verknad i motsett retning, der ei ny tilkopling brukar den porten som kjelde. Skriv ned kva side som kan initiere, den faktiske tenesta og motparten som må halde fram med å vere lukka, før du byggjer lista.

Stadfest kva filter som faktisk er knytt til: show running-config group-policy og show vpn-sessiondb detail l2l fortel saman kva sesjonen har arva. Å redigere ein ACL som ingen politikk viser til, endrar ingenting.

Ikkje bruk eitt ACL-objekt til to oppgåver

Eit grensesnitt-access-group og eit vpn-filter ser ut som same type objekt og vert vurderte på ulike punkt med ulik adresseorientering. Å tildele éi liste til begge inviterer til ei endring som reparerer tunnelen og stille løyser opp det fysiske grensesnittet.

Hald dei åtskilde, namngje dei etter oppgåva, og lat skilnaden i retning vere synleg i namna.

Stadfest med nye tilkoplingar, i begge retningar

Etter ei planlagd endring, opne éi ny tilkopling som skal tillatast og éi ny tilkopling som skal avvisast, og noter deretter adressene, retninga og policysamsvaret saman med resultatet. Ein etablert sesjon beviser ingenting om filtrering av nye tilkoplingar, fordi han allereie vart sleppt inn under dei gamle reglane.

Rekn òg med inspeksjon. Dokumentasjonen frå leverandøren nemner at eit VPN-filter kontrollerer den innleiande tilkoplinga og ikkje kvar sekundære tilkopling som ein inspeksjonsmotor opnar, så ein kontrollkanal og den tilhøyrande mediestraumen kan få ulik handsaming. Viss applikasjonen kjenner protokollen, test den faktiske straumen i staden for ein einaste portsonde.

Ein tunnel som vert brukbar etter ein brei bypass, fortel deg at avgrensinga vart fjerna, ikkje at ho vart oppfylt. Resultatet som er verdt å behalde, er eit namngjeve handhevingpunkt du kan peike på i neste gjennomgang.