Waarom een ASA-gebruiker op afstand het subnet bereikt maar niet de app
Routes bewijzen dat de tunnel werkt, niet dat de gebruiker de app mag openen. Lees het filter dat de sessie kreeg en test daarna een toegestane en een geweigerde verbinding.
Uw gebruiker maakt verbinding, krijgt een adres, pingt een server in het subnet van de applicatie en kan de dienst daarop toch niet openen. Die combinatie is normaal op een ASA, omdat een geslaagde tunnel en een bruikbare toestemming door verschillende instellingen worden bepaald. De split-tunnellijst koos welke bestemmingen de tunnel in gingen; een VPN-filter en de eigen toegangsregels van de bestemming bepalen wat het ontsleutelde verzoek mag bereiken. Doorloop de drie beslissingen in volgorde in plaats van de routelijst te verbreden tot er iets verandert.
Drie beslissingen die makkelijk te verwarren zijn
Toelating beantwoordt of de gebruiker de tunnel helemaal mag opzetten: inloggegevens, certificaat en een eventuele tweede factor. Routeselectie beantwoordt welke bestemmingen de client die tunnel in stuurt. Autorisatie beantwoordt of het ontsleutelde verzoek de dienst mag bereiken. Alleen de derde levert de fout op die de gebruiker meldt.
Een snelle manier om ze te onderscheiden is te vragen wat een wijziging zou breken. Een route uit de split-lijst halen stopt verkeer naar dat subnet zonder iets toe te kennen; een ACE aan het VPN-filter toevoegen kent een bestemming toe zonder te veranderen wat de client 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 |
Lees het filter dat de sessie echt kreeg
Begin bij de actieve sessie en niet bij de configuratie waarvan u denkt dat die geldt. show vpn-sessiondb detail anyconnect drukt het toegewezen groepsbeleid af en de naam van het filter dat aan die sessie is gekoppeld. Is het veld leeg, dan dwingt geen enkel filter iets af en komt de blokkade ergens anders vandaan.
Lees daarna het beleid dat de waarde bezit, inclusief standaardwaarden, want een filter kan worden geërfd in plaats van geschreven waar u kijkt:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Vergelijk de filternaam op de sessie met de ACL die u zojuist hebt bewerkt. Een ACL met een vergelijkbare naam die de gebruiker nooit heeft gekregen, kan het resourcebeleid van die sessie niet wijzigen, en dat is de meest voorkomende reden dat een correct lijkende wijziging geen effect heeft.
Voorrang verklaart de rest. Voor de filterinstelling gaat een DAP-record voor op attributen van de gebruikersnaam, en attributen van de gebruikersnaam gaan voor op het groepsbeleid. Als een sessie een filter toont dat u niet verwachtte, zoek dan een DAP-beleid dat bij die gebruiker past voordat u de groep aanraakt.
De split-lijst en het filter zijn aparte velden
Op ASA 9.x bevat het groepsbeleid split-tunnel-network-list en vpn-filter als verschillende instellingen, en de groepsbeleidsgids 9.22 documenteert ze juist daarom apart. De netwerklijst is een routeringshint voor de client; het filter is een toegangscontrolelijst die op ontsleuteld verkeer wordt toegepast.
Dat onderscheid is belangrijk wanneer een gebruiker één HTTPS-dienst in een subnet nodig heeft. Zet het subnet in de split-lijst zodat de pakketten de tunnel in gaan, sta daarna alleen die dienst toe in het filter. De routelijst uitbreiden autoriseert niets, en hem verkleinen is geen handhavingsmechanisme.
Controleer of een interface-ACL ook maar in het pad zit
Ontsleuteld verkeer voor toegang op afstand gaat niet altijd door de ACL van de buiteninterface zoals mensen aannemen. Waar sysopt connection permit-vpn is ingeschakeld, past de ASA zijn gedocumenteerde VPN-omzeiling toe voor dat verkeer, terwijl geldende VPN-filters daarna nog steeds van toepassing zijn. Controleer de instelling met show run all sysopt in plaats van te redeneren vanuit het topologiediagram.
Hoe dan ook blijven de eigen firewall van de doelserver en de autorisatie van de applicatie in het pad. Een ASA-regel die TCP 443 toestaat, zorgt er niet voor dat de applicatie de gebruiker accepteert.
Accepteer de wijziging ook met een geweigerde verbinding
Een toegestane test alleen bewijst heel weinig, omdat een werkende tunnel hetzelfde eerste pakket produceert of er nu een filter is of niet. Open de bedoelde dienst vanaf de client, probeer daarna een bestemming die dicht moet blijven en bevestig dat die om de juiste reden mislukt.
Noteer vier feiten als u het ticket sluit: de toegelaten identiteit, het beleid en filter dat de sessie echt kreeg, de bestemmingen in de split-lijst en de resource die de gebruiker mocht bereiken. Die vier verklaren waar het verkeer wordt beheerd zonder een routelijst in een firewall te veranderen.
Als de dienst nog steeds weigert nadat het filter hem toestaat, ga dan naar de host: luisteradres, hostfirewall en de eigen gebruikerstoewijzing van de applicatie. De tunnel deed op dat punt zijn werk, en verdere ASA-wijzigingen voegen alleen risico toe.