Вадим Чопоров: Грубо говоря, ip local policy route-map говорит маршрутизатору как обрабатывать пакеты адресованные или сгенерированные самим маршрутизатором. А так как ваши static nat висят на IP адресах назначенных на интерфейсы маршрутизатора, то и обрабатывать он их будет согласно локальной политике. Хотя я тут могу ошибаться, более продвинутые коллеги могут поправить.
То есть в вашем случае, когда пакет приходит на адрес WAN4 он транслируется во внутренний, а ответ маршрутизатор отправляет с обратной трансляцией, но уже в сторону WAN1 и естественно провайдер его дропает, т.к. соурс адрес стоит от WAN4. И как раз ip local policy route-map говорит маршрутизатору, что куда отправлять.
Во первых не вижу статического НАТа на второго (WAN4) провайдера, про которого вы говорили вначале.
А во вторых, так как в статическом нате транслируется адрес самого интерфейса, то не хватает роут-мапа для локального трафика:
route-map LOCAL permit 10
match ip address 50
set ip next-hop ISP1-GW
!
route-map LOCAL permit 20
match ip address 51
set ip next-hop ISP2-GW
!
access-list 50 permit ISP1_int_address - ваш x.x.x.x+1
access-list 51 permit ISP2_int_address
!
ip local policy route-map LOCAL
С хостом тоже нет смысла заморачиваться, т.к. хочется получать доступ с разных устройств, в том числе с телефона.
В общем я понял, что с натом ничего не выйдет. Буду делать какую-нибудь проксю.
Всем спасибо за ответы.
Внешний сервис не под моим контролем, поэтому ничего там править не могу и что-то там делать по моему запросу так же не будут.
Насчет directly connected, не соглашусь - трансляции создаются, однако по вышеуказанной причине, посмотреть какие то логи на внешнем хосте я не могу.
Добавил картинку в тему. Подключаюсь с домашнего компа на адрес 1.1.1.1:8080 дальше идет nat на внешний сервер 2.2.2.2:8080
Прописано правило ip nat source static tcp 2.2.2.2 8080 1.1.1.1 8080 extendable
Все верно, только в случае static nat, в заголовках пакета будет указан в том числе и изначальный source IP, и видимо сервер отвечает именного на него, в обход cisco.
В моем примере пробовал следующую конфигурации
ip nat source static tcp %externa_service_IP% 8080 %cisco_external_ip% 8080 extendable
при этом на внешнем интерфейсе включен NVI NAT - ip nat enable
Sergey Ryzhkin: Aruba - это и есть старые прокурвы. Если выбирать из них, то смотрите модели 2530 в качестве L2, а 2920 в качестве L3.
А вообще, у них есть довольно удобный конфигуратор для выбора моделей.
Если в сети есть несколько активных устройств, то рано или поздно вы увидите широковещательный запрос от одного из устройств. По адресу назначения узнаете адрес сети, например в сети 192.168.1.0/24 широковещательный адрес будет 192.168.1.255.
Как минимум будут видны адреса источников, по ним тоже можно многое понять, т.к. обычно используют /24 маску.
MIDgar: На циске у вас не DNS сервер стоит, а простой форвардер, то есть все что принял - переслал дальше.
Если у вас DHCP, то не ставьте всем клиентам DNS который стоит на контроллере домена.
jidckii: Погодите, получается, при разорванном линке, на R2 и R3 есть маршруты в 192.168.0.0/24, а на R0 и R1 нет маршрутов? То есть с них маршруты передаются, а на них нет?
Сделайте тогда sh ip ospf rib det на R1 и R2
Веб-сервер есть у большинства IP телефонов, о чем я писал в вопросе, а вот клиента пока никто не написал (видимо никому, кроме меня не нужно). Сам я не смогу, так как не обладаю должными навыками.
То есть в вашем случае, когда пакет приходит на адрес WAN4 он транслируется во внутренний, а ответ маршрутизатор отправляет с обратной трансляцией, но уже в сторону WAN1 и естественно провайдер его дропает, т.к. соурс адрес стоит от WAN4. И как раз ip local policy route-map говорит маршрутизатору, что куда отправлять.