Kvifor ein fjernbrukar på ASA når undernettet, men ikkje appen
Ruter provar at tunnelen verkar, ikkje at brukaren har lov til å opne appen. Les filteret økta faktisk fekk, og test deretter ei tillaten og ei avvist tilkopling.
Brukaren din koplar til, får ein adresse, pingar ein tenar i undernettet til applikasjonen og kan framleis ikkje opne tenesta på han. Den kombinasjonen er normal på ein ASA, fordi ein vellukka tunnel og ei brukbar løyve vert avgjort av ulike innstillingar. Lista for delt tunnel valde kva mål som kom inn i tunnelen; eit VPN-filter og dei eigne tilgangsreglane til målet avgjer kva den dekrypterte førespurnaden kan nå. Gå gjennom dei tre avgjerdene i rekkjefølgje i staden for å utvide ruttelista til noko endrar seg.
Tre avgjerder som lett vert forveksla
Tilgang svarar på om brukaren i det heile kan byggje opp tunnelen: legitimasjon, sertifikat og ein eventuell andre faktor. Ruteval svarar på kva mål klienten sender inn i den tunnelen. Autorisasjon svarar på om den dekrypterte førespurnaden kan nå tenesta. Berre den tredje gjev feilen brukaren rapporterer.
Ein rask måte å skilje dei er å spørje kva ei endring ville øydeleggje. Fjernar du ei rute frå den delte lista, stoggar trafikken til undernettet utan å gje noko; legg du til ein ACE i VPN-filteret, vert eit mål gjeve utan å endre kva 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 økta faktisk fekk
Start frå den levande økta og ikkje frå konfigurasjonen du trur gjeld. show vpn-sessiondb detail anyconnect skriv ut den tildelte gruppepolicyen og namnet på filteret som er knytt til økta. Er feltet tomt, handhevar ingen filter noko, og blokkeringa kjem frå ein annan stad.
Les deretter policyen som eig verdien, inkludert standardverdiane, fordi eit filter kan vere arva i staden for skrive der du ser:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Samanlikn filternamnet på økta med ACL-en du nettopp redigerte. Ein ACL med liknande namn som brukaren aldri fekk, kan ikkje endre ressurspolicyen til den økta, og det er den vanlegaste grunnen til at ei endring som ser rett ut, ikkje har nokon verknad.
Prioriteten forklarar resten. For filterinnstillinga rangerer ein DAP-post over brukarnamnattributt, og brukarnamnattributt rangerer over gruppepolicyen. Når ei økt viser eit filter du ikkje venta, sjå etter ein DAP-policy som passar brukaren, før du rører gruppa.
Den delte lista og filteret er separate felt
På ASA 9.x inneheld gruppepolicyen split-tunnel-network-list og vpn-filter som ulike innstillingar, og rettleiinga for gruppepolicy 9.22 dokumenterer dei separat nettopp derfor. Nettverkslista er eit rutetips til klienten; filteret er ei tilgangskontrolliste som vert brukt på dekryptert trafikk.
Den skilnaden tyder noko når ein brukar treng éi HTTPS-teneste i eit undernett. Set undernettet i den delte lista slik at pakkane kjem inn i tunnelen, og tillat deretter berre den tenesta i filteret. Å utvide ruttelista autoriserer ingenting, og å krympe ho er ikkje ein handhevingsmekanisme.
Kontroller om ein grensesnitt-ACL i det heile er i banen
Dekryptert fjernakses-trafikk går ikkje alltid gjennom ACL-en på det ytre grensesnittet slik folk antek. Der sysopt connection permit-vpn er aktivert, brukar ASA den dokumenterte VPN-omgåinga si for den trafikken, medan gjeldande VPN-filter framleis gjeld etterpå. Kontroller innstillinga med show run all sysopt i staden for å resonnere frå topologidiagrammet.
Uansett held brannmuren til målverten og autorisasjonen til applikasjonen fram i banen. Ein ASA-regel som tillèt TCP 443, får ikkje applikasjonen til å godta brukaren.
Godta endringa med ei avvist tilkopling òg
Ein tillaten test åleine provar svært lite, fordi ein fungerande tunnel lagar den same første pakken uansett om det finst eit filter. Opne den tiltenkte tenesta frå klienten, prøv deretter eit mål som skal halde fram med å vere lukka, og stadfest at det feilar av rett grunn.
Noter fire fakta når du lukkar saka: den tillatne identiteten, policyen og filteret økta faktisk fekk, måla i den delte lista og ressursen brukaren hadde lov til å nå. Dei fire forklarar kvar trafikken vert styrt, utan å gjere ei rutteliste om til ein brannmur.
Viss tenesta framleis avviser etter at filteret tillèt ho, gå til verten: lyttadresse, brannmuren til verten og den eigne brukartildelinga til applikasjonen. Tunnelen gjorde jobben sin på det punktet, og fleire ASA-endringar legg berre til risiko.