Varför en fjärranvändare på ASA når undernätet men inte appen
Rutter bevisar att tunneln fungerar, inte att användaren får öppna appen. Läs filtret som sessionen fick och testa sedan en tillåten och en nekad anslutning.
Din användare ansluter, får en adress, pingar en server i applikationens undernät och kan ändå inte öppna tjänsten på den. Den kombinationen är normal på en ASA, eftersom en lyckad tunnel och en användbar behörighet avgörs av olika inställningar. Listan för delad tunnel valde vilka destinationer som kom in i tunneln; ett VPN-filter och destinationens egna åtkomstregler avgör vad den dekrypterade begäran får nå. Gå igenom de tre besluten i ordning i stället för att bredda ruttlistan tills något ändras.
Tre beslut som lätt förväxlas
Tillträde svarar på om användaren alls får bygga upp tunneln: inloggningsuppgifter, certifikat och eventuell andra faktor. Ruttval svarar på vilka destinationer klienten skickar in i tunneln. Auktorisering svarar på om den dekrypterade begäran får nå tjänsten. Bara det tredje ger felet som användaren rapporterar.
Ett snabbt sätt att skilja dem åt är att fråga vad en ändring skulle förstöra. Tar du bort en rutt från den delade listan stoppas trafiken till det undernätet utan att ge något; lägger du till en ACE i VPN-filtret ges en destination utan att ändra vad klienten tunnlar.
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
Läs filtret som sessionen faktiskt fick
Börja vid den levande sessionen och inte vid konfigurationen du tror gäller. show vpn-sessiondb detail anyconnect skriver ut den tilldelade grupppolicyn och namnet på filtret som är knutet till sessionen. Är fältet tomt finns inget filter som genomdriver något och blockeringen kommer någon annanstans ifrån.
Läs sedan policyn som äger värdet, inklusive standardvärdena, eftersom ett filter kan ärvas i stället för att vara skrivet där du tittar:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Jämför filternamnet på sessionen med den ACL du just redigerade. En ACL med liknande namn som användaren aldrig fick kan inte ändra den sessionens resurspolicy, och det är den vanligaste orsaken till att en ändring som ser korrekt ut inte har någon effekt.
Prioriteten förklarar resten. För filterinställningen rangordnas en DAP-post över användarnamnsattribut, och användarnamnsattribut över grupppolicyn. När en session visar ett filter du inte väntade dig, leta efter en DAP-policy som passar användaren innan du rör gruppen.
Den delade listan och filtret är separata fält
På ASA 9.x innehåller grupppolicyn split-tunnel-network-list och vpn-filter som olika inställningar, och vägledningen för grupppolicy 9.22 dokumenterar dem separat just därför. Nätverkslistan är en routinghint till klienten; filtret är en åtkomstkontrollista som tillämpas på dekrypterad trafik.
Den skillnaden spelar roll när en användare behöver en enda HTTPS-tjänst i ett undernät. Sätt undernätet i den delade listan så att paketen kommer in i tunneln, och tillåt sedan bara den tjänsten i filtret. Att bredda ruttlistan auktoriserar ingenting, och att krympa den är ingen genomdrivningsmekanism.
Kontrollera om ett gränssnitts-ACL ens ligger i vägen
Dekrypterad fjärråtkomsttrafik går inte alltid genom det yttre gränssnittets ACL som folk antar. Där sysopt connection permit-vpn är aktiverat tillämpar ASA sin dokumenterade VPN-omkörning för den trafiken, medan tillämpliga VPN-filter fortfarande gäller efteråt. Kontrollera inställningen med show run all sysopt i stället för att resonera utifrån topologidiagrammet.
Hur som helst ligger destinationsvärden och applikationens auktorisering kvar i vägen. En ASA-regel som tillåter TCP 443 får inte applikationen att acceptera användaren.
Acceptera ändringen med en nekad anslutning också
Ett tillåtet test ensamt bevisar mycket lite, eftersom en fungerande tunnel producerar samma första paket oavsett om ett filter finns. Öppna den avsedda tjänsten från klienten, försök sedan med en destination som ska förbli stängd och bekräfta att den misslyckas av rätt skäl.
Anteckna fyra fakta när du stänger ärendet: den tillåtna identiteten, policyn och filtret som sessionen faktiskt fick, destinationerna i den delade listan och resursen användaren hade rätt att nå. De fyra förklarar var trafiken styrs utan att göra en ruttlista till en brandvägg.
Om tjänsten fortfarande nekar efter att filtret tillåter den, gå till värden: lyssnaradress, värdens brandvägg och applikationens egen användarmappning. Tunneln gjorde sitt jobb då, och fler ASA-ändringar lägger bara till risk.