Wêrom't in ASA-fierbrûker it subnet berikt, mar net de applikaasje
Rûtes bewize dat de tunnel wurket, net dat de brûker de applikaasje iepenje mei. Lês it filter dat de sesje krigen hat, test dan in tastiene en in wegere ferbining.
Jo brûker ferbynt, krijt in adres, pingt in tsjinner yn it subnet fan de applikaasje en kin de tsjinst dêrop dochs net iepenje. Dy kombinaasje is normaal op in ASA, om't in slagge tunnel en in brûkber tastimming troch ferskillende ynstellingen besletten wurde. De list foar split-tunnel keas hokker bestimmingen de tunnel yn gongen; in VPN-filter en de eigen tagongsregels fan de bestimming beslisse wat it ûntsifere fersyk berikke mei. Wurkgje de trije beslissingen yn folchoarder ôf ynstee fan de rûteslist te ferbreedzjen oant der wat feroaret.
Trije beslissingen dy't maklik te betiizjen binne
Tagong antwurdet oft de brûker de tunnel hielendal opbouwe mei: oanmeldgegevens, sertifikaat en in mooglike twadde faktor. Rûtekar antwurdet hokker bestimmingen de klant dy tunnel yn stjoert. Autorisearring antwurdet oft it ûntsifere fersyk de tsjinst berikke mei. Allinnich de tredde produsearret de flater dy't de brûker meldt.
In flugge manier om se te ûnderskieden is te freegjen wat in feroaring brekke soe. In rûte fan de split-list helje stopet ferkear nei dat subnet sûnder wat te jaan; in ACE oan it VPN-filter taheakje jout in bestimming sûnder te feroarjen wat de klant tunnelt.
| 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 it filter dat de sesje eins krigen hat
Begjin by de libbene sesje, net by de konfiguraasje dy't jo tinke dat jildt. show vpn-sessiondb detail anyconnect printsje de tawiisde groepsbelied en de filternamme dy't oan dy sesje ferbûn is. As it fjild leech is, twingt gjin filter wat en komt de blokkade fan earne oars.
Lês dan it belied dat de wearde besit, ynklusyf de standertwearden, om't in filter erfd wurde kin ynstee fan skreaun wêr't jo sjogge:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Fergelykje de filternamme op 'e sesje mei de ACL dy't jo krekt bewurke hawwe. In gelyknamige ACL dy't de brûker nea kriget hat, kin it boarnbelied fan dy sesje net feroarje, en dat is de meast foarkommende reden dat in goed-lykjende feroaring gjin effekt hat.
Prioriteit ferklearret de rest. Foar de filterynstelling giet in DAP-record foar op attributen fan brûkersnamme, en attributen fan brûkersnamme gean foar op it groepsbelied. As in sesje in filter toant dat jo net ferwachte, sykje dan in DAP-belied dat by dy brûker past foardat jo de groep oanreitsje.
De split-list en it filter binne aparte fjilden
Op ASA 9.x hâldt it groepsbelied split-tunnel-network-list en vpn-filter as ferskillende ynstellingen, en de hantlieding foar groepsbelied 9.22 dokumintearret se dêrom apart. De netwurklist is in rûte-oanwizing foar de klant; it filter is in tagongskontrôlelist dy't op ûntsifere ferkear tapast wurdt.
Dat ûnderskie is wichtich as in brûker ien HTTPS-tsjinst yn in subnet nedich hat. Set it subnet yn 'e split-list sadat de pakketten de tunnel yn geane, tastien dan allinnich dy tsjinst yn it filter. De rûteslist ferbreedzje autorisearret neat, en it ferlytsjen is gjin hanthaveningsmeganisme.
Kontrolearje oft in ynterface-ACL hielendal yn it paad is
Ûntsifere ferkear foar fier tagong giet net altyd troch de ACL fan 'e bûtenynterface sa't minsken oannimme. Wêr't sysopt connection permit-vpn oansetten is, past de ASA syn dokumintearre VPN-omgong ta foar dat ferkear, wylst jildende VPN-filters dêrnei noch fan tapassing binne. Kontrolearje de ynstelling mei show run all sysopt ynstee fan te riddenearjen út it topologyske diagram.
Hoe dan ek, de eigen firewall fan 'e bestimminghost en de autorisearring fan 'e applikaasje bliuwe yn it paad. In ASA-regel dy't TCP 443 tastiet, makket net dat de applikaasje de brûker akseptearret.
Akseptearje de feroaring ek mei in wegere ferbining
In tastiene test allinnich bewiist hiel lyts, om't in wurkjende tunnel itselde earste pakket produsearret oft der in filter is of net. Iepenje de bedoelde tsjinst fan 'e klant, besykje dan in bestimming dy't ticht bliuwe moat en befêstigje dat it om 'e goede reden mislearret.
Skriuw fjouwer feiten op as jo it ticket slute: de tastiene identiteit, it belied en filter dat de sesje eins krigen hat, de bestimmingen yn 'e split-list, en de boarne dy't de brûker berikke mocht. Dy fjouwer ferklearje wêr't it ferkear kontrolearre wurdt sûnder in rûteslist yn in firewall te feroarjen.
As de tsjinst noch altyd wegeret neidat it filter it tastiet, gean dan nei de host: harketadres, host-firewall en de eigen brûkersmap fan 'e applikaasje. De tunnel die op dat stuit syn wurk, en fierdere ASA-feroarings foegje allinnich risiko ta.