Den første antagelse, du skal droppe, er, at crypto-ACL'en er en adgangspolitik. Det er den ikke. På en Cisco ASA svarer den liste på ét snævert spørgsmål: hvilke pakker fortjener beskyttelse, og svaret siger intet om, hvorvidt den dekrypterede pakke må nå serveren bag firewallen. Adgang afgøres senere, af en interfacepolitik, af et gruppepolitikfilter eller af begge, afhængigt af hvordan tunnelen blev bygget.

Crypto-ACL'en svarer på et andet spørgsmål

En crypto-ACL er en matchliste. Den fortæller tunnelen, hvad der skal krypteres mellem to parter; en pakke, der ikke matcher den, er simpelthen ikke beskyttet. At udvide den ændrer beskyttelsens omfang og intet andet.

Derfor kan tilføjelsen af et subnet der få en tunnel op, mens selve applikationen stadig fejler. Tunnelen er oppe, fordi der nu findes et match. Applikationen fejler stadig, fordi intet på den liste tillader noget. To forskellige spørgsmål besvaret af to forskellige lister.

Hvad bypass-indstillingen i virkeligheden springer over

sysopt connection permit-vpn lader beskyttet trafik springe den interface-ACL-kontrol over, som ellers ville gælde på indgående side. Det er en bekvemmelighed for VPN-installationer, og den er global. Den rører ikke gruppepolitikken og rører ikke et autorisationsfilter pr. bruger.

Læs den faktiske værdi i stedet for antagelsen: show running-config all sysopt udskriver indstillingen, selv når den aldrig er blevet konfigureret eksplicit, og det er her, meget forvirring starter.

Fordi indstillingen er global, er det en dårlig handel at teste den som et hurtigt eksperiment på et enkelt fejlende subnet. Enhver anden tunnel på den firewall deler resultatet. Gem den til en bevidst ændring med en tilbagerulningsplan.

Læs filteret i den dekrypterede retning

Et LAN-to-LAN vpn-filter skrives fra tunnelens synspunkt, ikke interfacets. Det eksterne netværk står i kildepladsen og det lokale netværk i destinationspladsen, fordi det er sådan pakken ser ud efter dekryptering. Det samme filter evalueres derefter igen i den modsatte retning før kryptering, med adressernes roller byttet om.

Portbetingelser fortjener mere omhu end en kopieret interface-ACL, netop af den grund. En regel, der tillader én destinationsport, kan have en utilsigtet virkning i den modsatte retning, hvor en ny forbindelse bruger den port som kilde. Skriv ned, hvilken side der må initiere, den faktiske tjeneste og modparten, der skal forblive lukket, før du bygger listen.

Bekræft, hvilket filter der faktisk er tilknyttet: show running-config group-policy og show vpn-sessiondb detail l2l fortæller sammen, hvad sessionen har arvet. At redigere en ACL, som ingen politik refererer til, ændrer intet.

Genbrug ikke ét ACL-objekt til to opgaver

Et interface-access-group og et vpn-filter ligner samme slags objekt og evalueres på forskellige punkter med forskellig adresseorientering. At tildele én liste til begge indbyder til en ændring, der retter tunnelen og stille løsner det fysiske interface.

Hold dem adskilt, navngiv dem efter deres opgave, og lad forskellen i retning være synlig i navnene.

Verificér med nye forbindelser, i begge retninger

Efter en planlagt ændring, åbn én ny forbindelse, der bør tillades, og én ny forbindelse, der bør afvises, og notér derefter adresserne, retningen og politikmatchningen sammen med resultatet. En etableret session beviser intet om filtrering af nye forbindelser, fordi den allerede blev lukket ind under de gamle regler.

Regn også med inspektion. Leverandørens dokumentation bemærker, at et VPN-filter kontrollerer den indledende forbindelse frem for enhver sekundær forbindelse, som en inspektionsmotor åbner, så en kontrolkanal og dens tilhørende medieflow kan få forskellig behandling. Hvis applikationen kender protokollen, test den faktiske flow frem for en enkelt portsonde.

En tunnel, der bliver brugbar efter et bredt bypass, fortæller, at begrænsningen blev fjernet, ikke at den blev opfyldt. Det resultat, der er værd at beholde, er et navngivet håndhævelsespunkt, du kan pege på ved næste gennemgang.

Relaterede artikler