Hvorfor en fjernbruker på ASA når undernettet, men ikke appen
Ruter beviser at tunnelen virker, ikke at brukeren har lov til å åpne appen. Les filteret økten faktisk fikk, og test deretter en tillatt og en avvist tilkobling.
Brukeren din kobler til, får en adresse, pinger en server i applikasjonens undernett og kan fortsatt ikke åpne tjenesten på den. Den kombinasjonen er normal på en ASA, fordi en vellykket tunnel og en brukbar tillatelse avgjøres av forskjellige innstillinger. Listen for delt tunnel valgte hvilke destinasjoner som kom inn i tunnelen; et VPN-filter og destinasjonens egne tilgangsregler avgjør hva den dekrypterte forespørselen kan nå. Gå gjennom de tre beslutningene i rekkefølge i stedet for å utvide ruttelisten til noe endrer seg.
Tre beslutninger som lett forveksles
Adgang svarer på om brukeren i det hele tatt kan bygge opp tunnelen: legitimasjon, sertifikat og en eventuell andre faktor. Rutevalg svarer på hvilke destinasjoner klienten sender inn i den tunnelen. Autorisasjon svarer på om den dekrypterte forespørselen kan nå tjenesten. Bare den tredje gir feilen brukeren rapporterer.
En rask måte å skille dem er å spørre hva en endring ville ødelegge. Fjerner du en rute fra den delte listen, stopper trafikken til undernettet uten å gi noe; legger du til en ACE i VPN-filteret, gis en destinasjon uten å endre hva 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 |
Les filteret økten faktisk fikk
Start fra den levende økten og ikke fra konfigurasjonen du tror gjelder. show vpn-sessiondb detail anyconnect skriver ut den tildelte gruppepolicyen og navnet på filteret som er knyttet til økten. Er feltet tomt, håndhever ingen filter noe, og blokkeringen kommer fra et annet sted.
Les deretter policyen som eier verdien, inkludert standardverdiene, fordi et filter kan være nedarvet i stedet for skrevet der du ser:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Sammenlign filternavnet på økten med ACL-en du nettopp redigerte. En ACL med lignende navn som brukeren aldri fikk, kan ikke endre ressurspolicyen til den økten, og det er den vanligste grunnen til at en endring som ser riktig ut, ikke har noen virkning.
Prioriteten forklarer resten. For filterinnstillingen rangerer en DAP-post over brukernavnattributter, og brukernavnattributter rangerer over gruppepolicyen. Når en økt viser et filter du ikke forventet, se etter en DAP-policy som passer brukeren, før du rører gruppen.
Den delte listen og filteret er separate felt
På ASA 9.x inneholder gruppepolicyen split-tunnel-network-list og vpn-filter som forskjellige innstillinger, og veiledningen for gruppepolicy 9.22 dokumenterer dem separat nettopp derfor. Nettverkslisten er et rutinghint til klienten; filteret er en tilgangskontrolliste som brukes på dekryptert trafikk.
Den forskjellen betyr noe når en bruker trenger én HTTPS-tjeneste i et undernett. Sett undernettet i den delte listen slik at pakkene kommer inn i tunnelen, og tillat deretter bare den tjenesten i filteret. Å utvide ruttelisten autoriserer ingenting, og å krympe den er ikke en håndhevingsmekanisme.
Kontroller om en grensesnitt-ACL i det hele tatt er i banen
Dekryptert fjernadgangstrafikk går ikke alltid gjennom ACL-en på det ytre grensesnittet slik folk antar. Der sysopt connection permit-vpn er aktivert, bruker ASA sin dokumenterte VPN-omgåelse for den trafikken, mens gjeldende VPN-filtre fortsatt gjelder etterpå. Kontroller innstillingen med show run all sysopt i stedet for å resonnere fra topologidiagrammet.
Uansett forblir destinasjonsvertenes egen brannmur og applikasjonens autorisasjon i banen. En ASA-regel som tillater TCP 443, får ikke applikasjonen til å godta brukeren.
Godta endringen med en avvist tilkobling også
En tillatt test alene beviser svært lite, fordi en fungerende tunnel lager den samme første pakken uansett om det finnes et filter. Åpne den tiltenkte tjenesten fra klienten, prøv deretter en destinasjon som skal forbli lukket, og bekreft at den feiler av riktig grunn.
Noter fire fakta når du lukker saken: den tillatte identiteten, policyen og filteret økten faktisk fikk, destinasjonene i den delte listen og ressursen brukeren hadde lov til å nå. De fire forklarer hvor trafikken styres, uten å gjøre en rutteliste om til en brannmur.
Hvis tjenesten fortsatt avviser etter at filteret tillater den, gå til verten: lyttadresse, vertens brannmur og applikasjonens egen brukertilordning. Tunnelen gjorde jobben sin på det punktet, og flere ASA-endringer legger bare til risiko.