Pam bod defnyddiwr o bell ASA yn cyrraedd yr is-rwydwaith ond nid yr ap
Mae llwybrau’n profi bod y twnnel yn gweithio, nid bod gan y defnyddiwr hawl i agor yr ap. Darllenwch yr hidlydd a gafodd y sesiwn, yna profwch gysylltiad a ganiateir a chysylltiad a wrthodir.
Mae eich defnyddiwr yn cysylltu, yn cael cyfeiriad, yn pingio gweinydd yn is-rwydwaith yr ap, ac yn dal i fethu agor y gwasanaeth arno. Mae’r cyfuniad hwnnw’n normal ar ASA, oherwydd penderfynir twnnel llwyddiannus a chaniatâd defnyddiadwy gan wahanol osodiadau. Dewisodd y rhestr twnnel hollt pa gyrchfannau a aeth i mewn i’r twnnel; mae hidlydd VPN a rheolau mynediad y gyrchfan ei hun yn penderfynu beth y gall y cais dadgryptio ei gyrraedd. Ewch drwy’r tair penderfyniad yn eu trefn yn hytrach na lledu’r rhestr llwybrau nes bod rhywbeth yn newid.
Tair penderfyniad hawdd eu drysu
Mae derbyn yn ateb a all y defnyddiwr sefydlu’r twnnel o gwbl: enw a chyfrinair, tystysgrif, ac unrhyw ail ffactor. Mae dewis llwybr yn ateb pa gyrchfannau y mae’r cleient yn eu hanfon i’r twnnel hwnnw. Mae awdurdodi yn ateb a all y cais dadgryptio gyrraedd y gwasanaeth. Dim ond y trydydd sy’n cynhyrchu’r gwall y mae’r defnyddiwr yn ei riportio.
Ffordd gyflym i’w gwahaniaethu yw gofyn beth fyddai newid yn ei dorri. Mae tynnu llwybr o’r rhestr hollt yn atal traffig i’r is-rwydwaith honno heb ganiatáu unrhyw beth; mae ychwanegu ACE at hidlydd VPN yn caniatáu cyrchfan heb newid yr hyn y mae’r cleient yn ei dwnelu.
| 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 |
Darllenwch yr hidlydd a gafodd y sesiwn mewn gwirionedd
Dechreuwch o’r sesiwn fyw yn hytrach na’r ffurfweddiad rydych chi’n meddwl sy’n berthnasol. show vpn-sessiondb detail anyconnect yn argraffu’r polisi grŵp a bennwyd a’r enw hidlydd sydd ynghlwm wrth y sesiwn honno. Os yw’r maes yn wag, nid oes unrhyw hidlydd yn gorfodi unrhyw beth ac mae’r bloc yn dod o rywle arall.
Yna darllenwch y polisi sy’n berchen ar y gwerth, gan gynnwys y rhagosodiadau, oherwydd gall hidlydd gael ei etifeddu yn hytrach na’i ysgrifennu lle rydych chi’n edrych:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Cymharwch enw’r hidlydd ar y sesiwn â’r ACL rydych chi newydd ei olygu. Ni all ACL ag enw tebyg nad yw’r defnyddiwr erioed wedi’i gael newid polisi adnoddau’r sesiwn honno, a dyma’r rheswm mwyaf cyffredin pam nad oes gan newid sy’n edrych yn gywir unrhyw effaith.
Mae blaenoriaeth yn egluro’r gweddill. Ar gyfer y gosodiad hidlydd, mae cofnod DAP yn trechu priodoleddau enw defnyddiwr, ac mae priodoleddau enw defnyddiwr yn trechu’r polisi grŵp. Pan fydd sesiwn yn dangos hidlydd nad oeddech chi’n ei ddisgwyl, chwiliwch am bolisi DAP sy’n cyfateb i’r defnyddiwr hwnnw cyn i chi gyffwrdd â’r grŵp.
Mae’r rhestr hollt a’r hidlydd yn feysydd ar wahân
Ar ASA 9.x mae’r polisi grŵp yn dal split-tunnel-network-list a vpn-filter fel gwahanol osodiadau, ac mae canllaw polisi grŵp 9.22 yn eu dogfennu ar wahân am y rheswm hwnnw. Mae’r rhestr rwydwaith yn awgrym llwybro i’r cleient; mae’r hidlydd yn rhestr rheoli mynediad a gymhwysir i draffig dadgryptio.
Mae’r gwahaniaeth hwnnw’n bwysig pan fydd angen un gwasanaeth HTTPS ar is-rwydwaith ar y defnyddiwr. Rhowch yr is-rwydwaith yn y rhestr hollt fel bod y pecynnau’n mynd i mewn i’r twnnel, yna caniatáu dim ond y gwasanaeth hwnnw yn yr hidlydd. Nid yw lledu’r rhestr llwybrau yn awdurdodi unrhyw beth, ac nid yw ei chyfyngu yn fecanwaith gorfodi.
Gwiriwch a yw ACL rhyngwyneb hyd yn oed ar y llwybr
Nid yw traffig mynediad o bell dadgryptio bob amser yn croesi ACL y rhyngwyneb allanol fel y mae pobl yn tybio. Lle mae sysopt connection permit-vpn wedi’i alluogi, mae ASA yn cymhwyso ei osgoi VPN dogfenedig ar gyfer y traffig hwnnw, tra bo hidlyddion VPN perthnasol yn dal i fod yn berthnasol wedyn. Gwiriwch y gosodiad gyda show run all sysopt yn hytrach na rhesymu o’r diagram topoleg.
Naill ffordd neu’r llall, mae firewall y gwesteiwr cyrchfan ei hun ac awdurdodiad yr ap yn dal ar y llwybr. Nid yw rheol ASA sy’n caniatáu TCP 443 yn gwneud i’r ap dderbyn y defnyddiwr.
Derbyniwch y newid gyda chysylltiad a wrthodir hefyd
Nid yw prawf a ganiateir ar ei ben ei hun yn profi fawr ddim, oherwydd mae twnnel sy’n gweithio yn cynhyrchu’r un pecyn cyntaf p’un a oes hidlydd ai peidio. Agorwch y gwasanaeth arfaethedig o’r cleient, yna ceisiwch gyrchfan a ddylai aros ar gau a chadarnhewch ei fod yn methu am y rheswm cywir.
Cofnodwch bedair ffaith pan fyddwch yn cau’r tocyn: yr hunaniaeth a dderbyniwyd, y polisi a’r hidlydd a gafodd y sesiwn mewn gwirionedd, y cyrchfannau yn y rhestr hollt, a’r adnodd y caniatawyd i’r defnyddiwr ei gyrraedd. Mae’r pedair hynny’n egluro lle mae’r traffig yn cael ei reoli heb droi rhestr llwybrau yn firewall.
Os yw’r gwasanaeth yn dal i wrthod ar ôl i’r hidlydd ei ganiatáu, ewch i’r gwesteiwr: cyfeiriad gwrando, firewall y gwesteiwr, a mapio defnyddwyr yr ap ei hun. Mae’r twnnel wedi gwneud ei waith bryd hynny, ac mae mwy o newidiadau ASA yn ychwanegu risg yn unig.