Чому віддалений користувач ASA досягає підмережі, але не застосунку
Маршрути доводять, що тунель працює, а не що користувач може відкрити застосунок. Прочитайте фільтр, який отримала сесія, а потім перевірте дозволене й заборонене з’єднання.
Ваш користувач підключається, отримує адресу, пінгує сервер у підмережі застосунку і все одно не може відкрити службу на ньому. Така комбінація для 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 лише додають ризик.