Vilken ASA-regel ser trafiken efter att VPN har dekrypterat den

Det första antagandet att släppa är att krypto-ACL:n är en åtkomstpolicy. Det är den inte. På en Cisco ASA svarar den listan på en smal fråga: vilka paket förtjänar skydd, och svaret säger ingenting om huruvida det dekrypterade paketet får nå servern bakom brandväggen. Åtkomst avgörs senare, av en gränssnittspolicy, av ett gruppolicyfilter eller av båda, beroende på hur tunneln byggdes.

Krypto-ACL:n svarar på en annan fråga

En krypto-ACL är en matchningslista. Den talar om för tunneln vad som ska krypteras mellan två parter; ett paket som inte matchar den är helt enkelt inte skyddat. Att vidga den ändrar skyddets omfattning och ingenting annat.

Därför kan ett tillagt subnät där få en tunnel att komma upp medan själva applikationen fortfarande misslyckas. Tunneln är uppe eftersom det nu finns en matchning. Applikationen misslyckas fortfarande eftersom ingenting på den listan tillåter något. Två olika frågor, besvarade av två olika listor.

Vad bypass-inställningen egentligen hoppar över

sysopt connection permit-vpn låter skyddad trafik hoppa över gränssnitts-ACL-kontrollen som annars skulle gälla på inkommande sida. Det är en bekvämlighet för VPN-driftsättningar, och den är global. Den rör inte gruppolicyn och rör inte ett auktoriseringsfilter per användare.

Läs det faktiska värdet i stället för antagandet: show running-config all sysopt skriver ut inställningen även när den aldrig har konfigurerats explicit, och det är där mycket förvirring börjar.

Eftersom inställningen är global är det ett dåligt byte att testa den som ett snabbt experiment på ett enda felande subnät. Varje annan tunnel på den brandväggen delar resultatet. Spara den till en medveten ändring med en återställningsplan.

Läs filtret i den dekrypterade riktningen

En LAN-to-LAN-vpn-filter skrivs ur tunnelns perspektiv, inte gränssnittets. Fjärrnätet står i källpositionen och det lokala nätet i destinationspositionen, eftersom det är så paketet ser ut efter dekryptering. Samma filter utvärderas sedan igen i motsatt riktning före kryptering, med adressernas roller ombytta.

Portvillkor förtjänar mer omsorg än en kopierad gränssnitts-ACL, just därför. En regel som tillåter en destinationsport kan få en oavsedd effekt i motsatt riktning, där en ny anslutning använder den porten som källa. Skriv ned vilken sida som får initiera, den faktiska tjänsten och motparten som måste förbli stängd innan du bygger listan.

Bekräfta vilket filter som faktiskt är kopplat: show running-config group-policy och show vpn-sessiondb detail l2l berättar tillsammans vad sessionen har ärvt. Att redigera en ACL som ingen policy refererar till ändrar ingenting.

Återanvänd inte ett ACL-objekt för två uppgifter

Ett gränssnitts-access-group och ett vpn-filter ser ut som samma sorts objekt och utvärderas på olika punkter med olika adressorientering. Att tilldela en lista till båda bjuder in en ändring som reparerar tunneln och tyst lossar det fysiska gränssnittet.

Håll dem åtskilda, namnge dem efter deras uppgift, och låt skillnaden i riktning synas i namnen.

Verifiera med nya anslutningar, i båda riktningarna

Efter en planerad ändring, öppna en ny anslutning som ska tillåtas och en ny anslutning som ska nekas, och notera sedan adresserna, riktningen och policymatchningen tillsammans med resultatet. En etablerad session bevisar ingenting om filtrering av nya anslutningar, eftersom den redan släpptes in under de gamla reglerna.

Räkna också med inspektion. Leverantörens dokumentation noterar att ett VPN-filter kontrollerar den inledande anslutningen och inte varje sekundär anslutning som en inspektionsmotor öppnar, så en kontrollkanal och dess tillhörande medieflöde kan få olika behandling. Om applikationen känner till protokollet, testa det faktiska flödet i stället för en enda portsonde.

En tunnel som blir användbar efter en bred bypass säger att begränsningen togs bort, inte att den uppfylldes. Resultatet som är värt att behålla är en namngiven genomdrivningspunkt som du kan peka på vid nästa genomgång.