Тунелният маршрут по подразбиране в Cisco ASA: кога наистина се прилага

Потребител с отдалечен достъп не може да достигне нищо отвъд ASA, докато същият сървър отговаря на ping от вътрешната LAN. Тунелът се вдига, клиентът получава адрес от пула, а пакетът все още излиза през интернет маршрута по подразбиране или изчезва. Този модел обикновено означава, че декриптираният трафик не е намерил свой маршрут и е попаднал в обикновения маршрут по подразбиране. Поправката не е още едно NAT правило; тя е тунелният маршрут по подразбиране.

Започнете със симптома, не с конфигурацията

Гледайте къде отива пакетът, а не където сте очаквали да отиде. Прихващане на външния интерфейс по време на неуспешна сесия показва декриптирания пакет, пътуващ към шлюза на доставчика с непокътнат адрес от пула, или не показва нищо, защото търсенето е неуспешно. И в двата случая тунелът не е проблемът.

Тунелът изглежда здрав в show vpn-sessiondb и точно затова хората продължават да дебъгват IKE.

Това, което го отличава от отпадане по ACL, е посоката. Отпадането по ACL се логва и брои, докато липсващият маршрут дава неуспешно търсене без съответстващ запис. Изпълнете show route за дестинацията на клиента и прочетете какво всъщност е избрала ASA, включително дали е избран маршрут по подразбиране и кой.

Как се различава тунелното търсене

Ръководството на Cisco за статично маршрутизиране в ASA 9.23 описва отделен маршрут по подразбиране за декриптиран VPN трафик, който няма статичен или научен маршрут. Ключовата дума tunneled маркира този маршрут, така че декриптиран пакет може да падне на различен следващ хоп от този, който ASA използва за собствения си транспорт. По-конкретните маршрути все още печелят и затова клиент може да достигне 10.0.0.0/8 през вътрешния шлюз и да загуби всичко останало.

Минималната подредба държи два маршрута по подразбиране с различни следващи хопове. Единият носи собствения трафик на ASA, а другият носи декриптиран трафик, който няма по-добър маршрут. И двата следващи хопа все още трябва да са достижими от интерфейса, към който ги прикачвате.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

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

Ограниченията, които решават дали ще работи

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

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

Проследяването на маршрути е отделен капан: проследяваният обект обикновено пази обикновения маршрут по подразбиране, а не тунелния.

Какво не прави ключовата дума

Тя не избира адреса на източника, който ASA използва за изграждане на IKE. Външната крайна точка на тунела следва собствения избор на интерфейс и източник на платформата и тунелният маршрут по подразбиране няма дял в това решение. Промяната му няма да поправи phase 1, който взима източник от грешен адрес.

Тя също не превръща следващия хоп в прокси. Ако дестинацията очаква обмяна HTTP CONNECT, изпращането на сурови IP пакети към прокси хост ви дава само хост, който не ги маршрутизира. Конфигурирайте вместо това поддържания от клиента прокси механизъм.

И не създава препращане надолу по веригата. Шлюзът, към който сочите, все още се нуждае от маршрут обратно към VPN пула, плюс транслация на източника, където дизайнът го изисква.

Проверете пътя от край до край

След като маршрутът е на място, проверете четири неща по ред: show route за дестинация, от която пулът се нуждае, прихващане на интерфейса към новия следващ хоп, прихващане на самия шлюз и обратен път от този шлюз до адреса на пула. Първите две доказват, че ASA е избрала пътя, а последните две — че някой отговаря по него.

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

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