Яке правило ASA бачить трафік після того, як VPN його розшифрує

Перше припущення, від якого слід відмовитися, — що крипто-ACL є політикою доступу. Це не так. На Cisco ASA цей список відповідає на одне вузьке питання: які пакети заслуговують на захист, і ця відповідь нічого не каже про те, чи може розшифрований пакет досягти сервера за міжмережевим екраном. Доступ вирішується пізніше — політикою інтерфейсу, фільтром групової політики або обома, залежно від того, як побудовано тунель.

Крипто-ACL відповідає на інше питання

Крипто-ACL — це список зіставлення. Він каже тунелю, що шифрувати між двома сторонами; пакет, який із ним не збігається, просто не захищений. Його розширення змінює обсяг захисту і більше нічого.

Саме тому додавання підмережі там може підняти тунель, тоді як сам застосунок досі не працює. Тунель піднято, бо збіг тепер існує. Застосунок не працює, бо ніщо в цьому списку нічого не дозволяє. Два різні питання, два різні списки.

Що насправді пропускає налаштування обходу

sysopt connection permit-vpn дозволяє захищеному трафіку пропустити перевірку ACL інтерфейсу, яка інакше застосовувалася б на вхідній стороні. Це зручність для розгортань VPN, і вона глобальна. Вона не зачіпає групову політику і не зачіпає фільтр авторизації для окремого користувача.

Читайте фактичне значення, а не припущення: show running-config all sysopt виводить налаштування навіть тоді, коли його ніколи не задавали явно, і саме звідси починається багато плутанини.

Оскільки налаштування глобальне, перевіряти його як швидкий експеримент на одній неробочій підмережі — поганий обмін. Кожен інший тунель на цьому міжмережевому екрані поділяє результат. Збережіть його для усвідомленої зміни з планом відкату.

Читайте фільтр у напрямку розшифрування

ACL vpn-filter для LAN-to-LAN пишеться з погляду тунелю, а не інтерфейсу. Віддалена мережа стає на місце джерела, а локальна — на місце призначення, бо саме так пакет виглядає після розшифрування. Потім той самий фільтр ще раз оцінюється у зворотному напрямку перед шифруванням, із оберненими ролями адрес.

Умови для портів потребують більшої уваги, ніж скопійований ACL інтерфейсу, саме з цієї причини. Правило, що дозволяє один порт призначення, може дати небажаний ефект у зворотному напрямку, де нове з'єднання використовує цей порт як джерело. Перш ніж будувати список, запишіть, яка сторона може ініціювати, що є реальною службою і яка зустрічна сторона має залишатися закритою.

Підтвердьте, який фільтр справді прикріплено: show running-config group-policy і show vpn-sessiondb detail l2l разом показують, що успадкувала сесія. Редагування ACL, на який не посилається жодна політика, нічого не змінює.

Не використовуйте один об'єкт ACL для двох завдань

Інтерфейсний access-group і vpn-filter виглядають як об'єкт одного типу й оцінюються в різних точках із різною орієнтацією адрес. Призначення одного списку обом запрошує зміну, яка виправить тунель і тихо послабить фізичний інтерфейс.

Тримайте їх окремо, називайте за їхнім завданням і робіть різницю в напрямку видимою в назвах.

Перевіряйте новими з'єднаннями, в обох напрямках

Після запланованої зміни відкрийте одне нове з'єднання, яке має бути дозволене, і одне нове з'єднання, яке має бути відхилене, а потім запишіть адреси, напрямок і збіг із політикою разом із результатом. Установлена сесія нічого не доводить щодо фільтрації нових з'єднань, бо її вже пропущено за старими правилами.

Враховуйте й інспекцію. Документація виробника зазначає, що фільтр VPN перевіряє початкове з'єднання, а не кожне вторинне з'єднання, яке відкриває механізм інспекції, тому керівний канал і пов'язаний із ним медіапотік можуть отримати інше ставлення. Якщо застосунок знає протокол, тестуйте реальний потік, а не один зонд порту.

Тунель, який стає придатним після широкого обходу, каже, що обмеження знято, а не що його виконано. Результат, який варто зберегти, — це іменована точка застосування, на яку можна вказати під час наступного огляду.