Hvorfor en fjernbruger på ASA når undernettet men ikke appen
Ruter beviser, at tunnelen virker, ikke at brugeren må åbne appen. Læs det filter, sessionen modtog, og test derefter en tilladt og en afvist forbindelse.
Din bruger opretter forbindelse, får en adresse, pinger en server i applikationens undernet og kan stadig ikke åbne tjenesten på den. Den kombination er normal på en ASA, fordi en vellykket tunnel og en brugbar tilladelse afgøres af forskellige indstillinger. Split-tunnel-listen valgte, hvilke destinationer der kom ind i tunnelen; et VPN-filter og destinationens egne adgangsregler afgør, hvad den dekrypterede anmodning må nå. Gå gennem de tre beslutninger i rækkefølge i stedet for at udvide ruttelisten, indtil noget ændrer sig.
Tre beslutninger, der er lette at forveksle
Adgang afgør, om brugeren overhovedet må oprette tunnelen: legitimationsoplysninger, certifikat og en eventuel anden faktor. Rutevalg afgør, hvilke destinationer klienten sender ind i tunnelen. Autorisation afgør, om den dekrypterede anmodning må nå tjenesten. Kun den tredje giver den fejl, brugeren rapporterer.
En hurtig måde at skelne dem er at spørge, hvad en ændring ville ødelægge. Fjernes en rute fra split-listen, stopper trafikken til det undernet uden at give noget; tilføjes en ACE til VPN-filteret, gives en destination uden at ændre, hvad klienten tunnelerer.
| 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 det filter, sessionen faktisk modtog
Begynd ved den aktive session i stedet for den konfiguration, du tror gælder. show vpn-sessiondb detail anyconnect udskriver den tildelte gruppepolitik og navnet på det filter, der er knyttet til sessionen. Er feltet tomt, håndhæver intet filter noget, og blokeringen kommer fra et andet sted.
Læs derefter den politik, der ejer værdien, inklusive standardværdier, fordi et filter kan være nedarvet i stedet for skrevet der, hvor du kigger:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Sammenlign filternavnet på sessionen med den ACL, du netop har redigeret. En ACL med lignende navn, som brugeren aldrig modtog, kan ikke ændre den sessions ressourcepolitik, og det er den mest almindelige grund til, at en ændring, der ser rigtig ud, ikke har nogen effekt.
Prioritet forklarer resten. For filterindstillingen har en DAP-post forrang for brugernavnsattributter, og brugernavnsattributter har forrang for gruppepolitikken. Når en session viser et filter, du ikke forventede, så led efter en DAP-politik, der matcher brugeren, før du rører gruppen.
Split-listen og filteret er separate felter
På ASA 9.x indeholder gruppepolitikken split-tunnel-network-list og vpn-filter som forskellige indstillinger, og gruppepolitikvejledningen for 9.22 dokumenterer dem separat netop derfor. Netværkslisten er et ruteningshint til klienten; filteret er en adgangskontrolliste, der anvendes på dekrypteret trafik.
Den forskel betyder noget, når en bruger har brug for én HTTPS-tjeneste i et undernet. Sæt undernettet i split-listen, så pakkerne kommer ind i tunnelen, og tillad derefter kun den tjeneste i filteret. At udvide ruttelisten autoriserer intet, og at indskrænke den er ikke en håndhævelsesmekanisme.
Kontroller, om en interface-ACL overhovedet er på vejen
Dekrypteret fjernadgangstrafik passerer ikke altid den eksterne interface-ACL, som folk antager. Hvor sysopt connection permit-vpn er aktiveret, anvender ASA sin dokumenterede VPN-omgåelse for den trafik, mens relevante VPN-filtre stadig gælder bagefter. Kontroller indstillingen med show run all sysopt i stedet for at ræsonnere ud fra topologidiagrammet.
Uanset hvad forbliver destinationsværtens egen firewall og applikationens autorisation på vejen. En ASA-regel, der tillader TCP 443, får ikke applikationen til at acceptere brugeren.
Accepter ændringen med en afvist forbindelse også
En tilladt test alene beviser meget lidt, fordi en fungerende tunnel producerer den samme første pakke, uanset om der findes et filter. Åbn den tilsigtede tjeneste fra klienten, prøv derefter en destination, der skal forblive lukket, og bekræft, at den fejler af den rigtige grund.
Notér fire fakta, når du lukker sagen: den tilladte identitet, den politik og det filter sessionen faktisk modtog, destinationerne i split-listen og den ressource, brugeren havde tilladelse til at nå. De fire forklarer, hvor trafikken styres, uden at gøre en rutteliste til en firewall.
Hvis tjenesten stadig afviser, efter at filteret tillader den, skal du gå til værten: lytteadresse, værtens firewall og applikationens egen brugertilknytning. Tunnelen gjorde sit arbejde på det punkt, og yderligere ASA-ændringer tilføjer kun risiko.