Cisco Support Community
отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
cancel
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
Community Member

Надо опубликовать ресурс в удалённом офисе на локальном роутере!

Привет.

Два офиса (Москва и Регион1) соединены динамическим VPN. Надо в Москве опубликовать ресурс в Регионе 1. Классическим натом сделать не получается, потому что сейчас вся публикация настроена на Cisco ASA, которая по public ip подключена к роутеру в Москве.

Как-нибудь это можно решить?

2 УТВЕРЖДЕН. РЕШЕН.

Утвержденные решения

Публикация - в интернет?

Публикация - в интернет?

 

Допустим, адрес публикации будет 1.1.1.1. Пакет приходит на этот адрес из интернета по московскому каналу. Происходит NAT, у него меняются SRC на 1.1.1.1 и DST на 10.10.100.12, он выбрасывается обратно на роутер. Тот маршрутизирует как обычно до 10.10.100.12. Далее ответный пакет от 10.10.100.12 до 1.1.1.1 - он снова через DMVPN долетает до outside интерфейса асы, SRC меняется на 1.1.1.1, DST на адрес клиента, и он передается дальше в интернет.

 

Без twice NAT сложно (если публиковать на ASA). Вам надо транслировать как адрес получателя (ибо получатель - внутренний адрес), так и адрес отправителя (чтобы ответный пакет прошел через ASA). Если без трансляции адреса отправителя, то - PBR на региональном роутере, чтобы пакет от 10.10.100.12 до чего угодно пустить через DMVPN (а не в интернет), а на центральном роутере аналогичное правило кидает пакет на ASA. Мне это нравится намного меньше.

 

А если поднимете NAT на региональном роутере - удастся обойтись без трансляции адреса отправителя. Обратный пакет без вариантов пройдет через это устройство.

А статический маршрут

А статический маршрут прописать до внешней сети Москвы через интернет?

 

То, что вы пытаетесь сделать - не NAT, а PBR. Надо на интерфейсе сделать "ip policy route-map test". Но сначала рассмотрите статический маршрут. Или уговорите OSPF в Москве перестать анонсировать внешнюю сеть. Или уговорите региональный роутер не принимать этот маршрут в таблицу маршрутизации. Или в бранче анонсируйте в OSPF его внутреннюю сеть, чтобы Москва слала на него пакеты через туннель.

 

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

32 ОТВЕТ.

Можно чуть подробнее?1)

Можно чуть подробнее?

1) Опишите (а лучше нарисуйте) топологию. И какого рода динамический VPN?

2) Что конкретно смущает в ASA? Она может публиковать даже из outside в outside.

Community Member

Извините, карты нет. Два

Извините, карты нет. Два офиса - между ними VPN. Динамический это вот такой:

 

interface Tunnel1
 ip address 172.16.1.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp map multicast dynamic
 ip nhrp network-id 1000
 ip tcp adjust-mss 1360
 ip ospf network broadcast
 ip ospf cost 3
 ip ospf priority 255
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key 2000
 tunnel protection ipsec profile tun1-ipsec-profile

 

Проблема в том, что обратно-то пакеты не дойдут, там надо хитроумный роутмап делать?

Пакет приходит на роутер, далее на асу в главном офис, аса получает на аутсайт и натит на аутсайт (как Вы предлагаете - я не знал, что так можно), далее пакет попадает обратно на роутер, но у него уже dest ip: внутренний, а source ip: стоит внешний ип отправителя запроса. Когда это всё попадёт в регион, то там роутер ответ на этот покет занатит (у них же там нат обычный, им в Интернет ходить надо). Значит надо вешать роутмап какой-нить так, чтобы он тот нат не повредил и сказать, что любые пакеты изнутри наружу от этого ресурса пусть не через нат а роутом в московский офис, так ?

 

Я все равно не очень понял

Я все равно не очень понял вашу топологию и причем тут DMVPN, но, вполне вероятно, вас спасет twice nat - http://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/nat_rules.html .

далее пакет попадает обратно на роутер, но у него уже dest ip: внутренний, а source ip: стоит внешний ип отправителя запроса.

На этом этапе source адрес будет принадлежать не настоящему отправителю, а пулу на ASA. Т.е. она заменит сразу оба адреса.

Community Member

Приложил карту, скреативил)

Приложил карту, скреативил).

DMVPN при том, что к Москве ещё куча споуков подключены, это NHRP. Внутри OSPF бегает.

Вся публикация настроена на ASA. Внутренние ресурсы нормально публикуются а вот ресурсы из Региона нет.

То есть только твайс нат?

Публикация - в интернет?

Публикация - в интернет?

 

Допустим, адрес публикации будет 1.1.1.1. Пакет приходит на этот адрес из интернета по московскому каналу. Происходит NAT, у него меняются SRC на 1.1.1.1 и DST на 10.10.100.12, он выбрасывается обратно на роутер. Тот маршрутизирует как обычно до 10.10.100.12. Далее ответный пакет от 10.10.100.12 до 1.1.1.1 - он снова через DMVPN долетает до outside интерфейса асы, SRC меняется на 1.1.1.1, DST на адрес клиента, и он передается дальше в интернет.

 

Без twice NAT сложно (если публиковать на ASA). Вам надо транслировать как адрес получателя (ибо получатель - внутренний адрес), так и адрес отправителя (чтобы ответный пакет прошел через ASA). Если без трансляции адреса отправителя, то - PBR на региональном роутере, чтобы пакет от 10.10.100.12 до чего угодно пустить через DMVPN (а не в интернет), а на центральном роутере аналогичное правило кидает пакет на ASA. Мне это нравится намного меньше.

 

А если поднимете NAT на региональном роутере - удастся обойтись без трансляции адреса отправителя. Обратный пакет без вариантов пройдет через это устройство.

Community Member

Дмитрий, спасибо за помощь -

Дмитрий, спасибо за помощь - всё понятно.

Вопрос про обычный нат. Если я опубликую ресурс без этой всей котовасии прямо на региональном роутере, мне достаточно будет там прописать nat inside, nat outside интерфейсы и сделать правило прямоу публикации?

И ещё вопрос коротенький, можно nat inside вешать не на физику, а на VLAN интерфейс?

Нужен будет static nat. С

Нужен будет static nat.

 

С точки зрения L3, int vlan или сабинтерфейс почти ничем не отличается от физического интерфейса.

Community Member

Static NAT я понял, просто

Static NAT я понял, просто для него же нужно явно указать инсайд и аутсайд интерфейсы, они там в регионе немного отличаться могут от классической конфигурации, там как раз VLAN нат интерфейс.

С этим проблем не будет.

С этим проблем не будет.

Community Member

Сделал на региональном

Сделал на региональном роутере нат. Вроде работает, потому что изнутри не проверить. Можете подсказать по этому же вопросу - хотелось бы чтобы и внутри работало. Сейчас схема такая.

 

Я из московской сети пингую внешний ип в регионе, через который опубликован ресурс. Пинга доходит и проходит ту циску (вижу через #show ip nat translations) но обратно на внешний айпи он бросает не через Интернет а через тунель, в котором естественно опубликована внешняя сеть Москвы.

 

Я пытаюсь привзять route-map (next-hop) вот так:

ip nat inside source route-map test interface GigabitEthernet0/0 overload

================================

route-map test, permit, sequence 10
  Match clauses:
    ip address (access-lists): 108
  Set clauses:
    ip next-hop АЙПИ АДРЕС ШЛЮЗА ПРОВАЙДЕРА В РЕГИОНЕ
  Policy routing matches: 0 packets, 0 bytes

===================

Extended IP access list 108
    10 permit ip host 10.10.100.12 ВНЕШНЯЯ СЕТЬ в МОСКВЕ 0.0.0.255

 

Но он упорно шлёт через тунель:

O E2    ВНЕШНЯЯ СЕТЬ МОСКВЫ/27 [110/20] via 172.16.1.1, 00:33:19, Tunnel1

 

Маски там 27 и 24 не важно, ибо 24 закрывает и 27 тоже.

 

 

А статический маршрут

А статический маршрут прописать до внешней сети Москвы через интернет?

 

То, что вы пытаетесь сделать - не NAT, а PBR. Надо на интерфейсе сделать "ip policy route-map test". Но сначала рассмотрите статический маршрут. Или уговорите OSPF в Москве перестать анонсировать внешнюю сеть. Или уговорите региональный роутер не принимать этот маршрут в таблицу маршрутизации. Или в бранче анонсируйте в OSPF его внутреннюю сеть, чтобы Москва слала на него пакеты через туннель.

 

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

Community Member

Да, хотел так сделать. Тогда

Да, хотел так сделать.

 

Тогда давайте я аккуратно попробую убрать в OSPF анонсмент внешней Московской сети для конкретно региона, где опубликован ресурс. Так можно? Я когда я читал OSPF так и не понял как запретить анонсмент только для определенного члена OSPF а не для всей области.

Покажите, откуда маршрут на

Покажите, откуда маршрут на внешнюю сеть попадает в OSPF. Судя по E2, это redistribute?

 

Запретить OSPF передавать префикс соседу по area нельзя. Можно запретить OSPF устанавливать маршрут в таблицу маршрутизации с помощью distribute-list in (продолжая передавать его соседям).

 

В любом случае надо тщательно проанализировать выбранное решение с точки зрения того, какие сервисы оно может сломать.

Community Member

Маршрут попадает с

Маршрут попадает с Московского роутера - он анонсирует ёё, она у него директли коннектед. Я прочитал про эту команду, понял как это работает...сделаю))

 

Попал как нуб по глупости...когда конфигрурировал сделал вот так: 

#no ip prefix-list BLOCK_3144 permit 0.0.0.0/0 le 32

 

И потерял связь с циской по понятным причинам))))))

206
Просмотры
0
Полезный материал
32
Ответы
СоздатьДля создания публикации, пожалуйста в систему