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

Две разклонения, един интерфейс

Решете кое разклонение строите, преди да въведете NAT правило, защото правилата не са взаимозаменяеми. Разклонение A е клиент към интернет: адресът от пула влиза, транслатиран публичен адрес излиза, обратно през същия интерфейс. Разклонение B е клиент към частен префикс от другата страна на друг IPsec партньор: адресът от пула се запазва, прешифрова се и се доставя на партньор, който трябва да знае как да отговори на пула.

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

same-security-traffic permit intra-interface

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

Разклонение A: клиентът иска интернет

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

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

След това потвърдете, че клиентът наистина е помолил ASA да носи този трафик. Изключване от разделен тунел изпраща публичната дестинация по собствената връзка на телефона, която никога не достига до ASA, и никакво NAT правило не поправя пакет, който никога не е бил изпратен. Сравнете списъка за разделен тунел на груповата политика с дестинацията, която тествате.

Останалото в разклонението е обичайно: използваем маршрут по подразбиране или конкретен маршрут от външния интерфейс, политика за достъп, която разрешава потока, и DNS, обработен според избраната от вас политика на resolver. Добавете route-lookup тук по същата причина като по-долу, тъй като входният и изходният интерфейс са идентични.

Разклонение B: клиентът иска частен сайт

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

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

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

Проверете и реда на правилата. Широко PAT правило над правилото за идентичност ще транслатира частния обмен, преди правилото за идентичност изобщо да бъде оценено, и симптомът е сайтов тунел без съответстващ SA, а не NAT грешка.

Тестът, който ви казва кое разклонение сте построили

Използвайте собствената оценка на пътя на ASA, вместо да четете конфигурацията и да се надявате. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed показва решението за NAT, маршрута и резултата от ACL за един поток; повторете с частна дестинация. Ако фазата NAT пренаписва поток от частен към частен, сте построили разклонение A за пакет, който е имал нужда от разклонение B.

Още две команди затварят празнината. show nat detail отпечатва реда на правилата, който packet-tracer е следвал, и show crypto ipsec sa показва дали съществува селектор за двойката, която очаквате. Липсващ SA е въпрос на конфигурация на селектор или партньор, а не нещо, което NAT правилото може да поправи.

Проверете всяко разклонение с трафика, който обслужва

Приемете разклонение A с обикновена публична заявка от клиента и разклонение B със заявка към частен ресурс, който наистина съществува. След това повторете всяко с отказан ресурс, защото „разрешено“ и „позволено от политиката за достъп“ не са едно и също доказателство, а ping, който произхожда от хъба, не упражнява нито един от клиентските пътища.

Пазете двата тестови записа отделно в заявката: адрес на източника, дестинация, съответстващо NAT правило и резултат. Когато следващият доклад каже „VPN-ът е счупен“, тази двойка ви казва в рамките на минута кое разклонение е регресирало, и отговорът обикновено е маршрут или селектор, а не редът за същия интерфейс, който всички подозират първо.

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