[LostSoul]

Добрый день.

 

Имеется схема:

Internet стык подсеть /30 -- Cisco 7200 --   подсеть с реальными IP /24

Для примера   vlan195 -  подсеть , 195.10.10.0/24  ,  IP  195.10.10.1

 

Хочется - добавить в схему серую подсеть 10.10.10.0/24   и обеспечить ее выход в интернет с трансляций "хост в хост" в существующую реальную подсеть.

 

Настраиваем:

 

interface GigabitEthernet0/2.195
 encapsulation dot1Q 195

 ip address 195.10.10.1 255.255.255.0

 ip address 10.10.10.1 255.255.255.0 secondary

 ip nat inside

 

ip nat pool out195 195.10.10.0 195.10.10.255 prefix-length 24 type match-host

ip nat inside source list 195 pool out195

access-list 195 permit ip 10.10.10.0 0.0.0.255 any

 

Что получаем в такой конфигурации в результате.

1) прямой роутинг IP работает

2) NAT с трансляцией "хост в хост"  так же работает

 

Факап в следующем -   если "серый" узел, например 10.10.10.100 лезет в интернет,  то перестает работать соответствующий ему прямой IP 195.10.10.100

И не работает пока обмен не будет прекращен и запись трансляции не исчезнет из списка show ip nat translation

Путем наблюдений и сканирования снаружи выявлено, что похоже роутер поднимает у себя на борту alias для того реального IP в который производит трансляцию.

 

При аналогичной задаче - трансляции определенного tcp порта с реальной транзитной подсети на серую все работает в случае добавления опции no-alias.

А вот при исходящей трансляции к сожалению no-alias указать невозможно.

 

Гуру, подскажите выход?

Заменить на микротик не предлагать :-)

[god_of_ethernet]

а разве белая подсеть не должа висеть на другом интерфейсе, который в мир смотрит(ip nat outside)??

[DRiVen]

В свой сабинтерфейс серую сеть запихать никак?

[LostSoul]

Запихал в отдельный сабинтерфейс.

попробовал для интерфейса с белой сетью ставить ip nat outside.

на ситуацию с работой nat это не повлияло никак - по отдельности работает ( или трансляция с серого IP  или работа соответствущего белого )  , но в момент когда серый IP транслируется в белый - работа железки на которой поднят этот белый IP нарушается ( так как , похоже, белый IP поднимается на циске )

 

нужно понять как бы сделать аналог no-alias при исходящей трансляции.  

 

[ShyLion]

Не очень понял. Есть реальный хост с IP .100 и кто-то другой еще может занатится с тем-же адресом?

[LostSoul]

58 минут назад, ShyLion сказал:

Не очень понял. Есть реальный хост с IP .100 и кто-то другой еще может занатится с тем-же адресом?

цель именно такая, да.

Что есть подсеть в 255 реальных хостов ( транзитом через циску роутится )

нужно чтоб 255 серых IP натились в те-же самые 255 реальных IP не препятствуя их нормальной работе.

 

Ну то есть так-же, как если бы в Linux  сказать  iptables -t nat -I POSTROUTING -s 10.10.10.100 -j SNAT --to-source 195.10.10.100

( при этом 195.10.10.100 это просто IP трафик которого проходит в оба направления через роутер транзитом, на маршрутизаторе он не поднят )

 

По факту сейчас все работает как задумано,  но циска создав динамическую трансляцию считает нужным скрыто поднять 195.10.10.100 у себя , и нарушает работу всего остального трафика IP 195.10.10.100,  к указанному соединению nat не относящегося.

 

Я имел такой-же проблему, организовывая переадресацию  входящего порта ( чтоб подключения TCP-подключения из интернета на 195.10.10.100/1234  попадали на TCP 10.10.100:1234  ) , но решил ее дописав опцию no-alias.

 

Вот так блокировало работу реального IP за маршрутизатором

ip nat inside source static tcp 10.10.10.100 1234 195.10.10.100 1234 extendable

 

Вот так все стало работать идеально

ip nat inside source static tcp 10.10.10.100 1234 195.10.10.100 1234 extendable no-alias

 

теперь задача как разрешить 10.10.10.100 вылезать в мир от имени 195.10.10.100 так чтоб настоящему 195.10.10.100 это не мешало.

 

В линуксе или микротике - с пол пинка.  Очень обидно что с циско такие приколы.

 

[kostikbel]

1 час назад, LostSoul сказал:

цель именно такая, да.

Что есть подсеть в 255 реальных хостов ( транзитом через циску роутится )

нужно чтоб 255 серых IP натились в те-же самые 255 реальных IP не препятствуя их нормальной работе.

...

 

В линуксе или микротике - с пол пинка.  Очень обидно что с циско такие приколы.

 

И как такое может работать, с вашей точки зрения ?  Занатили вы для серого хоста TCP соединение с порта на какой-то хост/порт, а позже белый хост захотел такое же соединение открыть.  Или серый занял UDP порт, который понадобился белому (пусть даже просто DNS запросы оба начали отправлять). Что должно произойти ?

[LostSoul]

4 часа назад, kostikbel сказал:

И как такое может работать, с вашей точки зрения ?  Занатили вы для серого хоста TCP соединение с порта на какой-то хост/порт, а позже белый хост захотел такое же соединение открыть.  Или серый занял UDP порт, который понадобился белому (пусть даже просто DNS запросы оба начали отправлять). Что должно произойти ?

Для TCP то?   Замечательно работает.

Захотел и открыл,  nat разберется - там для этого и sequence number есть и timestamp (иногда )

но вероятность открытия двумя хостами tcp-подключения на один целевой узел и порт с одинаковым исходным портом крайне низка.  Исторически помню единственный пример - battle net клиент :-)

 

 

Для UDP и остального ( для протоколов для которых нет conntrack-хелпера )  конфликты конечно возможны.  Но если запретить скажем трансляцию портов ниже скажем 10000 "один в один" и переносить на высокие порты - то риск  проблем минимален.

Ну не откроет "белый" хост какое то соединение с первого раза,  откроет с второго задействовав иной порт.

( если так сложатся звезды, что у этот UDP порт уже занял "серый" хост )

 

По сути обе сети администрирует одно лицо , так что пробелем не будет вообще.

[ShyLion]

16 часов назад, LostSoul сказал:

цель именно такая, да.

Месье знает толк в извращениях.

Предлагаю не останавливаться на этом, завести несколько компов с одинаковыми IP и героически преодолевать трудности, путем ломания сетевого стека на линуксе. Потом и до одинаковых МАКов дойти. :)

 

А, да. Cisco - говно, конечно же. Не умеет таких элементарных вещей :)

[LostSoul]

2 часа назад, ShyLion сказал:

 завести несколько компов с одинаковыми IP и героически преодолевать трудности, путем ломания сетевого стека на линуксе. Потом и до одинаковых МАКов дойти. :)

 

 

Вы только что изобрели HSRP  и аналоги, которые в cisco более-менее нормально работают и многими используются :-)

 

Однако вопрос всё таки про NAT.

В принципе, если это упросит задачу можно добавить в ТЗ  что подсеть с реальными IP использует tcp-порты ниже 20000 , а выше 20000 все нужно направлять на серую сеть.

Но это не убирает основной проблемы - желание циски поднять на себе алиас адреса из реальной сети для созданной трансляции.

 

Может кто0то подскажет как тоже самое описать с помощью NVI правил?

 

[ShyLion]

22 минуты назад, LostSoul сказал:

Вы только что изобрели HSRP  и аналоги, которые в cisco более-менее нормально работают и многими используются :-)

 

Сравнили теплое с мягким, ага :)

[LostSoul]

7 минут назад, ShyLion сказал:

Сравнили теплое с мягким, ага :)

То есть общий IP или общий MAC на несколько нод ( физических узлов кластера , или по простому "компов" ) не применяется в системах высокой доступности?

 

[ShyLion]

6 минут назад, LostSoul сказал:

То есть общий IP или общий MAC на несколько нод ( физических узлов кластера , или по простому "компов" ) не применяется в системах высокой доступности?

 

Конечно применяется, только при чем тут НАТ? Те системы делаются так, чтобы быть 100% идентичными по отношению к другим узлам, а в Ваших хотелках совсем другое.

[LostSoul]

Мда, перепились похоже на Руси цисководы-богатыри-добры-молодцы....

 

[DRiVen]

Ни при чем тут цисководы, у вас хотелки сложнозадые. То, что при каждом соединении по L2 в arp роутера придут два запроса с разных физических интерфейсов, с разными mac, но с одним и тем же ip (и с результатом "кто первый встал того и тапки" пока запись по таймауту не удалится), вас никак не смущает? Не работает так протокол, осознайте уже.

[LostSoul]

3 часа назад, DRiVen сказал:

Ни при чем тут цисководы, у вас хотелки сложнозадые. То, что при каждом соединении по L2 в arp роутера придут два запроса с разных физических интерфейсов, с разными mac, но с одним и тем же ip (и с результатом "кто первый встал того и тапки" пока запись по таймауту не удалится), вас никак не смущает? Не работает так протокол, осознайте уже.

Не пойму откуда вы все это взяли.

Но специально для вас попробую нарисовать с другой стороны.

 

давайте я попробую изобразить по частям.

 

Вариант А

За маршрутизатором cisco находятся две локальных сети.

сеть1 10.10.1.0/24

сеть2 10.10.2.0/24

Блок реальных IP 195.10.10.0/24

Нужно настроить NAT чтоб сеть1 и сеть2 имели доступ в интернет с трансляцией адресов в реальный блок. 

При этом транслировались "хост в хост" .  То есть :

10.10.1.101 , 10.10.2.101 -->  195.10.10.101

10.10.1.102, 10.10.2.102 --> 195.10.10.102

и так все 256 адресов.

 

На данном этапе вам не видятся разные MAC с одним IP и прочее? ( у всех хостов разные IP и MAC )

 

Вариант Б

сеть1 10.10.1.0/24

сеть2 10.10.2.0/24

Блок реальных IP 195.10.10.0/24

 

Настраиваем  как в варианте А , но с следующим доп. условием:

Все входящие подключения на IP-адреса  из блока 195.10.10.0/24 по портам TCP и UDP транслируем на сеть 10.10.1.0/24

( кроме тех IP/портов для которых уже имеется динамическая исходящая трансляция с хостов сети 10.10.2.0/24 )

 

В таком варианте возражения есть?

 

Вариант В

Настраиваем как в варианте Б ,  но вместо адресов 10.10.1.0/24 используем сразу 195.10.10.0/24

То есть одна подсеть проходит сквозняком без трансляции ( за исключением IP/портов для которых созданы динамические правила трансляции из сети 10.10.2.0/24 ).

 

Так годно?

 

И для скептиков считающих что это работать не будет приведу пример настройки с которым все гарантировано и замечательно работает.

 

eth0 - интерфейс в провайдера

 

iptables -t nat -I POSTROUTING -s 10.10.2.0/24 -o eth0 -j SNAT --to-source 195.10.10.0-195.10.10.255 --persistent

 

И все! Одно правило,  работает точно так как описанный мной желаемый результат.

Тоже самое аналогично работает и в микротике.

 

И на циске это работает, единственная проблема - что опции no-alias для исходящей трансляции нету. ( Для входящей - есть )

 

Скорее всего результат делается через NVI , гуру подскажите.

 

[Дегтярев Илья]

LostSoul,

без overload такая схема работать не будет, т.к. трансляция не сохраняет использованный порт.

В linux именно overload вариант включен по-умолчанию.

 

В 07.09.2017 в 00:18, DRiVen сказал:

В свой сабинтерфейс серую сеть запихать никак?

Зачем? Просто надо писать не ip nat inside, а  ip nat enable.

Изменено 10 сентября, 2017 пользователем Дегтярев Илья

[LostSoul]

5 часов назад, Дегтярев Илья сказал:

без overload такая схема работать не будет, т.к. трансляция не сохраняет использованный порт.

В linux именно overload вариант включен по-умолчанию.

 

да хоть с чертом лысым.

лишь бы работало и умная циска себе алиас реального ip на супервизор не навешивала