Защо отдалечен потребител на ASA достига подмрежата, но не приложението
Маршрутите доказват, че тунелът работи, а не че потребителят може да отвори приложението. Прочетете филтъра, който сесията е получила, след което тествайте разрешена и отказана връзка.
Вашият потребител се свързва, получава адрес, прави ping до сървър в подмрежата на приложението и все още не може да отвори услугата на него. Тази комбинация е нормална за ASA, защото успешният тунел и използваемото разрешение се определят от различни настройки. Списъкът за разделен тунел избра кои дестинации влизат в тунела; филтърът на VPN и собствените правила за достъп на дестинацията решават какво може да достигне дешифрираната заявка. Минавайте през трите решения по ред, вместо да разширявате списъка с маршрути, докато нещо се промени.
Три решения, които лесно се объркват
Допускането отговаря дали потребителят изобщо може да установи тунела: идентификационни данни, сертификат и всеки втори фактор. Изборът на маршрут отговаря кои дестинации клиентът изпраща в този тунел. Оторизацията отговаря дали дешифрираната заявка може да достигне услугата. Само третото произвежда грешката, за която потребителят съобщава.
Бърз начин да ги различите е да попитате какво би счупила дадена промяна. Премахването на маршрут от разделения списък спира трафика към тази подмрежа, без да дава нищо; добавянето на ACE към VPN филтъра дава дестинация, без да променя какво клиентът тунелира.
| 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 |
Прочетете филтъра, който сесията действително е получила
Започнете от живата сесия, а не от конфигурацията, която смятате, че важи. show vpn-sessiondb detail anyconnect показва зададената групова политика и името на филтъра, прикачен към тази сесия. Ако полето е празно, никакъв филтър не налага нищо и блокирането идва от другаде.
След това прочетете политиката, която притежава стойността, включително стойностите по подразбиране, защото филтърът може да е наследен, а не записан там, където гледате:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Сравнете името на филтъра в сесията с ACL, който току-що редактирахте. ACL с подобно име, който потребителят никога не е получил, не може да промени ресурсната политика на тази сесия и това е най-честата причина промяна, която изглежда правилна, да няма ефект.
Приоритетът обяснява останалото. За настройката на филтъра DAP записът е с по-висок приоритет от атрибутите на потребителското име, а те са с по-висок приоритет от груповата политика. Когато сесия покаже филтър, който не очаквате, потърсете DAP политика, съответстваща на този потребител, преди да пипате групата.
Разделеният списък и филтърът са отделни полета
В ASA 9.x груповата политика съдържа split-tunnel-network-list и vpn-filter като различни настройки и ръководството за групови политики 9.22 ги документира отделно точно поради тази причина. Мрежовият списък е маршрутна подсказка към клиента; филтърът е списък за контрол на достъпа, прилаган към дешифриран трафик.
Това разграничение има значение, когато на потребителя трябва една HTTPS услуга в подмрежа. Поставете подмрежата в разделения списък, за да влязат пакетите в тунела, след което разрешете само тази услуга във филтъра. Разширяването на списъка с маршрути не дава нищо, а свиването му не е механизъм за налагане.
Проверете дали ACL на интерфейса изобщо е по пътя
Дешифрираният трафик за отдалечен достъп не винаги преминава през ACL на външния интерфейс така, както хората предполагат. Където sysopt connection permit-vpn е включен, ASA прилага документираното си VPN заобикаляне за този трафик, а приложимите VPN филтри продължават да важат след това. Проверете настройката с show run all sysopt вместо да разсъждавате по диаграмата на топологията.
Както и да е, собствената защитна стена на хоста дестинация и оторизацията на приложението остават по пътя. Правило в ASA, което разрешава TCP 443, не кара приложението да приеме потребителя.
Приемете промяната и с отказана връзка
Само разрешен тест доказва много малко, защото работещият тунел произвежда същия първи пакет независимо дали има филтър. Отворете желаната услуга от клиента, след което опитайте дестинация, която трябва да остане затворена, и потвърдете, че се проваля по правилната причина.
Запишете четири факта, когато затваряте заявката: допуснатата идентичност, политиката и филтърът, които сесията действително е получила, дестинациите в разделения списък и ресурсът, до който потребителят е имал право да достигне. Тези четири обясняват къде се контролира трафикът, без да превръщат списък с маршрути в защитна стена.
Ако услугата продължава да отказва, след като филтърът я разрешава, преминете към хоста: адрес за слушане, защитна стена на хоста и собственото съпоставяне на потребители на приложението. Тунелът е свършил работата си в този момент и допълнителни промени в ASA само добавят риск.