Публікація внутрішнього сервісу через VPN «сайт-сайт» на ASA

Публікація сервісу, який живе за VPN «сайт-сайт», — це одне завдання з п’ятьма точками відмови, і вони відмовляють у фіксованому порядку. Тунель піднімається, трансляція збігається, філія відповідає, і відповідь повертається тим самим шляхом. Коли щось із цього неправильне, браузер показує те саме: з’єднання, яке зависає або скидається. Пройдіть список згори вниз і зупиніться на першій перевірці, яка не проходить.

Перевірка 1: тунель захищає адресу джерела

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

Підтвердьте це лічильниками тунелю й таблицею маршрутів, перш ніж чіпати трансляцію. Якщо джерело недоступне з концентратора через тунель, ніщо далі в цьому списку це не виправить.

Зупиніться тут, якщо захищений діапазон і адреса джерела не збігаються.

Перевірка 2: вирішіть, яке джерело побачить філія

Філія бачить або початкову адресу клієнта, або трансляційну, і цей вибір визначає зворотний шлях. Збереження адреси клієнта читається чистіше в журналах джерела, але тоді філія має надсилати відповіді для публічних клієнтів назад через тунель; звичайний типовий інтернет-маршрут надсилає їх в інший бік, і з’єднання вмирає в одному напрямку. Трансляція джерела в адресу, яку філія вже маршрутизує через тунель, прибирає цю вимогу.

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

Перевірка 3: пишіть трансляцію під реальні інтерфейси

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

Шлях, який ви будуєте, має чотири ділянки, і всі чотири мають збігтися:

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

Перевірка 4: обмежте правило доступу опублікованим портом

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

Перевірте порядок правил одночасно. Широкий дозвіл над вашим конкретним правилом робить конкретне правило невидимим.

Перевірка 5: простежте один запит і його відповідь

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

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

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

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