Hoekom 'n ASA-afstandgebruiker die subnet bereik maar nie die toepassing nie
Roetes bewys die tonnel werk, nie dat die gebruiker die toepassing mag oopmaak nie. Lees die filter wat die sessie ontvang het en toets dan 'n toegelate en 'n geweierde verbinding.
Jou gebruiker verbind, kry 'n adres, ping 'n bediener in die toepassing-subnet en kan steeds nie die diens daarop oopmaak nie. Daardie kombinasie is normaal op 'n ASA, want 'n suksesvolle tonnel en 'n bruikbare toestemming word deur verskillende instellings bepaal. Die split-tonnelys het gekies watter bestemmings die tonnel binnegaan; 'n VPN-filter en die bestemming se eie toegangsreëls bepaal wat die ontsleutelde versoek mag bereik. Werk deur die drie besluite in volgorde eerder as om die roetelys te verbreed totdat iets verander.
Drie besluite wat maklik verwar word
Toelating antwoord of die gebruiker die tonnel hoegenaamd mag vestig: geloofsbriewe, sertifikaat en enige tweede faktor. Roetekeuse antwoord watter bestemmings die kliënt daardie tonnel in stuur. Magtiging antwoord of die ontsleutelde versoek die diens mag bereik. Net die derde een veroorsaak die fout wat die gebruiker rapporteer.
'n Vinnige manier om hulle te onderskei is om te vra wat 'n verandering sou breek. Om 'n roete uit die split-lys te verwyder, stop verkeer na daardie subnet sonder om enigiets toe te staan; om 'n ACE by die VPN-filter te voeg, staan 'n bestemming toe sonder om te verander wat die kliënt tonnel.
| 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 |
Lees die filter wat die sessie werklik ontvang het
Begin by die lewende sessie eerder as by die konfigurasie wat jy dink van toepassing is. show vpn-sessiondb detail anyconnect druk die toegewysde groepsbeleid en die filternaam wat aan daardie sessie geheg is. As die veld leeg is, dwing geen filter enigiets af nie en kom die blok van elders.
Lees dan die beleid wat die waarde besit, insluitend verstekwaardes, want 'n filter kan geërf word eerder as geskryf waar jy kyk:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Vergelyk die filternaam op die sessie met die ACL wat jy pas geredigeer het. 'n Soortgelyk genoemde ACL wat die gebruiker nooit ontvang het nie, kan nie daardie sessie se hulpbronbeleid verander nie, en dit is die algemeenste rede waarom 'n korrek-lykende verandering geen uitwerking het nie.
Voorrang verduidelik die res. Vir die filterinstelling het 'n DAP-rekord voorrang bo gebruikersnaam-kenmerke, en gebruikersnaam-kenmerke het voorrang bo die groepsbeleid. Wanneer 'n sessie 'n filter wys wat jy nie verwag het nie, soek 'n DAP-beleid wat by daardie gebruiker pas voordat jy die groep aanraak.
Die split-lys en die filter is aparte velde
Op ASA 9.x hou die groepsbeleid split-tunnel-network-list en vpn-filter as verskillende instellings, en die 9.22-groepsbeleidgids dokumenteer hulle afsonderlik om daardie rede. Die netwerklys is 'n roetine-aanduiding vir die kliënt; die filter is 'n toegangsbeheelys wat op ontsleutelde verkeer toegepas word.
Daardie onderskeid maak saak wanneer 'n gebruiker een HTTPS-diens op 'n subnet nodig het. Sit die subnet in die split-lys sodat die pakkette die tonnel binnegaan, en laat dan net daardie diens in die filter toe. Om die roetelys uit te brei magtig niks, en om dit te verklein is nie 'n afdwingmeganisme nie.
Kyk of 'n koppelvlak-ACL hoegenaamd in die pad is
Ontsleutelde afstandtoegang-verkeer beweeg nie altyd deur die buitenste koppelvlak-ACL soos mense aanneem nie. Waar sysopt connection permit-vpn geaktiveer is, pas die ASA sy gedokumenteerde VPN-omseiling vir daardie verkeer toe, terwyl toepaslike VPN-filters daarna steeds geld. Kyk na die instelling met show run all sysopt eerder as om uit die topologie-diagram te redeneer.
Hoe dit ook al sy, die bestemmingsgasheer se eie firewall en die toepassing se magtiging bly in die pad. 'n ASA-reël wat TCP 443 toelaat, maak nie dat die toepassing die gebruiker aanvaar nie.
Aanvaar die verandering ook met 'n geweierde verbinding
'n Toegelate toets alleen bewys baie min, want 'n werkende tonnel produseer dieselfde eerste pakket of daar 'n filter is of nie. Maak die beoogde diens oop vanaf die kliënt, probeer dan 'n bestemming wat geslote moet bly en bevestig dat dit om die regte rede misluk.
Teken vier feite aan wanneer jy die kaartjie sluit: die toegelate identiteit, die beleid en filter wat die sessie werklik ontvang het, die bestemmings in die split-lys, en die hulpbron wat die gebruiker mag bereik het. Daardie vier verduidelik waar die verkeer beheer word sonder om 'n roetelys in 'n firewall te verander.
As die diens steeds weier nadat die filter dit toelaat, skuif na die gasheer: luisteradres, gasheer-firewall en die toepassing se eie gebruikerstoewysing. Die tonnel het op daardie punt sy werk gedoen, en verdere ASA-veranderinge voeg net risiko by.