Обектен VPN работи, но журналите на ASA не идват: проверете адреса на източника

Вътрешните хостове достигат отдалечения събирач и техните syslog редове се появяват. Собствените съобщения на ASA за същите тези сесии никога не пристигат. Няма нищо сбъркано нито в събирача, нито в тунела, и точно това обърква. Защитната стена изпраща журналите си от източник, който тунелът никога не е бил строен да защитава.

Какво пристига и какво не

Започнете с разделянето на два потока, които изглеждат еднакви на таблото. Препредаваният трафик минава през ASA: LAN хост изпраща към събирача, ASA го съпоставя с политиката на тунела, криптира го и събирачът вижда адреса на хоста. Генерираният трафик започва на самия ASA: устройството изгражда syslog пакет, избира изходен интерфейс и източник и едва след това пита дали някоя политика на тунела съвпада. Първият поток доказва, че тунелът работи, и не казва нищо за втория.

Буферирано събитие на устройството също не е доказателство за отдалечена доставка, защото журналът може да съществува локално и никога да не е бил изпратен. Проверете броячите за приемане на събирача, преди да обвините тунела, защото празен брояч е различно установяване от брояч, който расте.

Генерираното съобщение не е препредаван трафик

Когато ASA създава пакет, той не проксира LAN хост. Източникът идва от изходния интерфейс или от явна настройка на източника, и пакетът влиза в същото търсене на маршрут и проверки на политиката, както всичко друго, което устройството изпраща. Това означава, че селекторът на VPN трябва да включва адреса, който ASA действително използва, а това често е неговият външен интерфейс, а не вътрешна подмрежа.

Ако политиката защитава 10.20.0.0/24 и ASA използва външния си адрес като източник, пакетът на журнала или излиза в открит текст към събирач, до който не може да достигне, или бива изхвърлен. И двата изхода изглеждат еднакво от страната на събирача. Същото разсъждение важи и за управленския трафик, затова management-access е отделно проектно решение.

Кой източник ASA поставя в мрежата

Открийте източника емпирично, а не чрез предположение. Захващане на изходния интерфейс по време на тестово съобщение показва действителния източник и дестинация и струва по-малко време от четенето на три раздела от конфигурацията. Сравнете този адрес с локалния селектор на тунела.

Някои версии позволяват фиксиране на източника на журнала към интерфейс, а справочникът с команди за вашата версия е авторитетът дали тази опция съществува и какво променя. Команда source-interface от друга платформа на Cisco не е автоматично валидна на ASA.

Ако все пак смените източника, направете го умишлено и го отбележете, защото ACL на събирача и всяка корелация, изградена върху syslog, зависят от него.

Съпоставете селектора с потока на журнала

След като източникът е известен, проверете три неща по ред: крипто ACL или селектор на база политика, който решава кой трафик е интересен, маршрутът, който решава накъде отива пакетът, и всяко NAT правило, което може да презапише източника преди криптиране. Пакет, който съвпада с маршрута, но не със селектора, не се тунелира, а пакет, презаписан от NAT, може да не съвпада с нито едното.

Страната на събирача има свои изисквания: ACL, разрешаващ източника на ASA, обратен маршрут и слушаща услуга на порта, който сте конфигурирали. Транспортът има значение и тук, защото журналирането по TCP и TLS се държи различно от UDP по частично блокиран път. Променяйте по един елемент наведнъж, иначе следващото захващане няма да ви каже коя промяна е имала значение.

Проверете при събирача, после запишете източника

Потвърдете, че съобщението пристига, после запишете адреса на източника, който ASA е използвал, селектора, който го е пренесъл, и нивото на сериозност, с което сте тествали.

Този запис превръща следващата промяна на ACL на събирача или редакция на селектора в двуминутна проверка вместо повторно откриване. Той също документира кой от двата потока някога е бил валидиран, а именно тази част повечето ръководства за експлоатация пропускат. Ако съобщението все още не пристига, временно понижете прага на сериозност и тествайте срещу една дестинация.

Наръчникът ЧЗВ за журналиране на ASA на Cisco документира случай с външен източник, който изисква съответното определение за защитен трафик, а неговият пример с вътрешен източник включва както хост за журналиране отвътре, така и management-access отвътре. Разглеждайте документираната комбинация и контекста на софтуера заедно, вместо да предполагате, че един копиран ред пасва на всяка конфигурация.

Тунел, който носи LAN трафик, не е тунел, който носи собствения глас на защитната стена.