Разделеното тунелиране не освобождава публичен хост от правилата за NAT на ASA

Разделеното тунелиране обикновено се описва като начин корпоративният трафик да остане в тунела, а останалата част от интернет — извън защитната стена. И двете половини на това описание са погрешни по един и същ начин. Разделеното тунелиране е решение за маршрут, взето от клиента, а решението за маршрут не казва нищо за това какво се случва с пакета, след като достигне headend.

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

Митът: разделеното тунелиране маха защитната стена от пътя

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

Клиентът не е станал рутер. Той е следвал политиката, която му дадохте.

Какво всъщност прави маршрут split-include

В настройка за отдалечен достъп на Cisco ASA груповата политика носи split-tunnel-policy tunnelspecified и split-tunnel-network-list, който именува стандартен ACL. Всеки ред permit в този ACL е дестинация, която клиентът трябва да изпрати в тунела, а всичко останало продължава да използва локалния маршрут по подразбиране.

Добавянето на един хост е един ред и това е единствената част от промяната, която клиентът вижда: access-list RA-SPLIT standard permit host 203.0.113.20.

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

Пакетът пристига и си отива през същия интерфейс

Сега проследете потока след дешифрирането. Пакетът е влязъл през външния интерфейс по VPN тунела, дестинацията му е публичен адрес и таблицата за маршрутизация го изпраща обратно през същия външен интерфейс към интернет. Трафик, който влиза и излиза през един интерфейс, се отхвърля, освен ако на ASA не е разрешено да го пропуска, а точно това прави same-security-traffic permit intra-interface. Без него връзката се проваля по начин, който изглежда като проблем с маршрутизацията, но не е.

Тази настройка е глобална. Тя разрешава hairpinning за всеки поток, който се нуждае от него, не само за този партньорски хост, затова ѝ е мястото в прегледана промяна, а не в бърз тест.

Защо PAT, ограничен до дестинация, не е по избор

Адресът на източника в дешифрирания пакет все още е VPN адресът на клиента, обикновено от пул като 10.77.0.0/24. Този адрес няма маршрут в публичния интернет, така че партньорът или никога не отговаря, или отговаря в нищото.

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

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

Частта destination static е важна. Ако я премахнете, правилото се превръща в широк превод, който може да съвпадне с много повече трафик от предвиденото, а широко правило identity по-рано в реда може да надделее напълно над това. Проверете show nat detail и реда на секциите, преди да приемете, че вашето правило е съвпадащото.

Interface PAT също означава, че партньорът вижда адреса на интерфейса на ASA, който може да бъде преведен отново по-нагоре. Ако договорът посочва адрес, потвърдете го от край до край, а не на един хоп.

Докажете го с правилната тестова дестинация

Използвайте самия партньорски хост, а не обща страница what-is-my-ip. Тази страница почти сигурно е извън split списъка, така че показва локалния ви интернет адрес и не казва нищо за този път. Отворете нова връзка към партньорската услуга и ги попитайте какъв източник са видели, или изпълнете packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed и четете етапите на NAT и маршрутизацията ред по ред. Traceroute от клиента е по-слаба проверка, защото показва пътя, който вече се е случил, а не политиката, която го е избрала.

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

Работещата версия на този дизайн е кратка: един хост в split ACL, разрешение за hairpin, едно правило PAT, ограничено до дестинация. Всичко останало в историята е митът.