ASA VPN hairpin: маршрутизиране на два тунела през един интерфейс

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

Отдалечен потребител се свързва с ASA, иска хост зад клон и ASA изпраща тази заявка през същия интерфейс, през който е пристигнал потребителят. Нищо в това не изисква втори физически порт. Изисква обаче четири независими решения, които хората обикновено сгъват в едно: разрешение за hairpin, тунел, който защитава правилните адреси, NAT политика, която запазва обещания от вас източник, и политика за достъп, която разрешава услугата.

Един пакет, два тунела

Проследете потока и редът на операциите спира да бъде загадка. Пакетът пристига в тунела за отдалечен достъп, декриптира се и става обикновен IP пакет с източник от пула на клиентите. След това ASA го маршрутизира, съпоставя го с crypto ACL за връзка сайт-сайт, криптира го отново и го изпраща през външния интерфейс към клона.

Адресите по-долу са илюстративни, но формата е важна: източникът е пулът, а не вътрешната LAN на ASA.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

От това следват две неща. Клиентът се нуждае от маршрут за префикса на клона през своята връзка за отдалечен достъп, което означава, че split-tunnel или изпращаният списък с маршрути трябва да го включва. А клонът трябва да знае как да връща трафик към 10.77.0.20 или към адреса, който вашият NAT дизайн е заместил.

Разрешението за hairpin е глобално

Командата, към която хората посягат, е same-security-traffic permit intra-interface. Тя позволява на трафика да влиза и излиза през същия интерфейс, което е точно това, което този път изисква. Тя е и глобална настройка: включването й променя поведението на други потоци, които случайно преминават два пъти през същия интерфейс.

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

Обхватът на защита и NAT са отделни

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

След това NAT решава дали адресът от пула оцелява. Identity NAT го запазва и клонът вижда 10.77.0.20 като източник. Транслацията променя договора: клонът вече връща трафик към транслатирания адрес и собствената му политика трябва да го приеме. Редът на правилата решава дали crypto ACL съвпада преди или след транслацията, затова четете ефективния поток, вместо да предполагате кое печели.

Не изтривайте общите PAT правила за интернет, за да проработи един транзитен случай. Целенасочено изключение или умишлено identity правило е по-лесно за обяснение и за отмяна от дупка в изходящата политика.

Криптирането не е оторизация

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

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

Hairpin или втори интерфейс

Hairpin транзитът държи дизайна малък и струва една глобална настройка. Отделен интерфейс или маршрутен тунел със собствен виртуален интерфейс изолира транзитния път и ви дава политика за всеки интерфейс, срещу цената на адресиране и още една crypto map или профил. Нито едно не е по-правилно; те се провалят по различен начин.

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

Проверявайте от реалния клиент

Сонда, пусната от ASA, има различен адрес на източника и няма да упражни пътя от пула към клона. Използвайте packet-tracer за проверка на петорката, след което отворете реална връзка от действителния отдалечен клиент, защото трасиращият инструмент симулира и не замества собствената маршрутизация и политика на клиента.

След планирана промяна се свържете с услуга, която трябва да работи, после с такава, която трябва да бъде отказана, и потвърдете обратния маршрут на клона. примери на Cisco за hairpin NAT при VPN държат разрешението intra-interface, NAT и ACL видимо отделни и това е мисловният модел, който си струва да копирате.

Подобни статии