Добрый день всем.Настраиваю простой проброс порта на циске, работает, но есть нюанс, который хотелось бы побороть.
Простейший случай. Два интерфейса, между ними нат:
Внешний nat outside 63.118.73.6/30 на провайдера
Внутренний nat inside 79.109.91.128/26 на DMZ зонупробросы работают на ура, например
ip nat inside source static tcp 79.109.91.141 501 63.118.73.6 501 extendable no-aliasно при этом перестаёт работать простой коннект снаружи на хост на этот порт.
грубо говоря до прописывания проброса работает прямой коннект 79.109.91.141 501
при прописывании правила проброса порта работает 63.118.73.6 501 но перестает работать
коннект 79.109.91.141 501правило ната перекрывает кислород прямой работе? как обойти, подскажите...
Вроде был такой глюк...
Можно место внешнего адреса прописать внешний интерфейс.
>Вроде был такой глюк...
>Можно место внешнего адреса прописать внешний интерфейс.В моем случае не подойдет :(... Мне тут понадобилось промаршрутизировать пакет с одного сервера в одном пуле на другой сервер в другом пуле.
Обрисую в деталях:
На внутреннем DMZ интерфейсе прилеплено два пула:
79.109.73.0/28 (primary ip on Fa1/0 79.109.73.1)
79.109.91.128/26 (secondary ip on Fa1/0 79.109.91.129)так вот понадобилось маршрутизировать порт 501 с сервера 79.109.73.6 на сервер 79.109.91.140
по идее оба сервера идут на один и тот же интерфейс циски. По этому использовать интерфейс в правиле ната не получается... Проброс работает, но по прежнему затыкается коннект на исходный адрес и порт.
А Вы можете показать конфиг со всеми натами и всем, что к ним относится?
>А Вы можете показать конфиг со всеми натами и всем, что к
>ним относится?interface FastEthernet1/0
description DMZ
ip address 79.109.91.129 255.255.255.192 secondary
ip address 79.109.73.1 255.255.255.240
ip access-group dmzin in
ip accounting output-packets
ip nat inside
no ip mroute-cache
ip policy route-map provider-map
duplex auto
speed 100
!
interface FastEthernet2/0
description PROVIDER
ip address 63.118.73.5 255.255.255.252
ip access-group providerin in
ip access-group providerout out
ip verify unicast reverse-path
ip nat outside
duplex auto
speed auto
!
ip nat log translations syslog
ip nat pool provider-space 63.118.73.5 63.118.73.5 netmask 255.255.255.252
ip nat inside source list ucs interface Tunnel0 overload
ip nat inside source route-map provider-map pool provider-space overload
ip nat inside source static tcp 79.109.91.140 501 79.109.73.6 501 extendable no-alias
ip classless
ip route 0.0.0.0 0.0.0.0 63.118.73.6
ip route 79.109.73.0 255.255.255.240 FastEthernet1/0
ip route 79.109.91.128 255.255.255.192 FastEthernet1/0
ip http server
ip http authentication local
ip http secure-server
!
route-map provider-map permit 20
match ip address permitinternet
match interface FastEthernet2/0
set default interface FastEthernet2/0
Наконец понял Ваш конфиг.
Если та информация которой я раполагаю верна, то или шашечки или ехать:
>ip nat inside source static tcp 79.109.91.140 501 79.109.73.6 501 extendable no-aliasА вот это зачем? Они же и так Connected.
>ip route 79.109.73.0 255.255.255.240 FastEthernet1/0
>ip route 79.109.91.128 255.255.255.192 FastEthernet1/0
>Наконец понял Ваш конфиг.а вот тут поподробнее пожалуйста %) Получается никак низя заставить работать и коннект по правилу статик ната и прямой коннект?
А есть ли варианты с глобальной реорганизацией чтобы это сработало?>Если та информация которой я раполагаю верна, то или шашечки или ехать:
>>ip nat inside source static tcp 79.109.91.140 501 79.109.73.6 501 extendable no-alias
>А вот это зачем? Они же и так Connected.
>>ip route 79.109.73.0 255.255.255.240 FastEthernet1/0
>>ip route 79.109.91.128 255.255.255.192 FastEthernet1/0Так ведь есть третий интерфейс который смотрит в LAN. 192.168.1.1 и подсеть у него 192.168.1.0/24. У локальных хостов то роутер 192.168.1.1, а без этих правил локальные хосты не пингуют хосты из сетей DMZ.
к тому же в таблице маршрутизации они все равно фигурируют как Connected
C 79.109.73.0/28 is directly connected, FastEthernet1/0
C 79.109.91.128/26 is directly connected, FastEthernet1/0
>а вот тут поподробнее пожалуйста %) Получается никак низя заставить работать и
>коннект по правилу статик ната и прямой коннект?
>А есть ли варианты с глобальной реорганизацией чтобы это сработало?
>
>>Если та информация которой я раполагаю верна, то или шашечки или ехать:
>>>ip nat inside source static tcp 79.109.91.140 501 79.109.73.6 501 extendable no-aliasНасчет глобальной реорганизации - это очень серьезный шаг.
А вот с натом есть такая странность в ИОСе...>[оверквотинг удален]
>Так ведь есть третий интерфейс который смотрит в LAN. 192.168.1.1 и подсеть
>у него 192.168.1.0/24. У локальных хостов то роутер 192.168.1.1, а без
>этих правил локальные хосты не пингуют хосты из сетей DMZ.
>
>к тому же в таблице маршрутизации они все равно фигурируют как Connected
>
>C 79.109.73.0/28 is directly connected, FastEthernet1/0
>
>C 79.109.91.128/26 is directly connected, FastEthernet1/0
>Правильно. У Connected метрика 0, у static 1. По моему эти 2 правила тут лишние. Но Вам виднее...
>Насчет глобальной реорганизации - это очень серьезный шаг.Самому не охота :) может удастся уговорить девелоперов обойти эту проблему не средствами сетевого отдела...
>А вот с натом есть такая странность в ИОСе...
как думаете, обновление версии иоса не поможет?
у меня сейчас не самая свежая... C7200-JK9S-M 12.3(18)>Правильно. У Connected метрика 0, у static 1. По моему эти 2
>правила тут лишние. Но Вам виднее...Сам понимаю что вродь излишество, но без этих правил пакеты в сети не ходят. В принципе они никому не мешают, так что пущай остаются :)
ИОС обновить это хорошее решение. Но... у Cisco иногда как у мелкомягких... Одно лечат, другое калечат. Так что будьте аккуратнее.
>ИОС обновить это хорошее решение. Но... у Cisco иногда как у мелкомягких...
>Одно лечат, другое калечат. Так что будьте аккуратнее.Вот и думаю, если решения это не даст то не стоит.
Сейчас посимулирую ситуацию на GNS3. С рабочими иосами.
>А Вы можете показать конфиг со всеми натами и всем, что к
>ним относится?попробовал исключить из ната f1/0, тогда проброс совсем не работает, работает только прямой коннект. что в общем то закономерно...
Вот как бы заставить работать и то и то... Попробовал проброс сделать с дмз интерфейса на внешний посредством айпишника и посредством указания интерфейса - один черт. Проброс работает, оригинал перестает. Грешил на то что пробрасывается все на том же самом интерфейсе, и источник и приемник, так нет... развел на разные интерфейсы - картина та же.
Приветствую!Интересно вообще у кого-то такое работает?
Static NAT – Mapping an unregistered IP address to a registered IP address on a one-to-one basis.
Может оно и не предполагает что внешний-внешний будет привязка и все ответные пакеты с порта 501
просто перезаписывает не пользуясь таблицей.
А что кажет sh ip nat tra | i 79.109.91.140 (или какой там)
Может стоит попробовать пробросить как в последнем посте тут http://www.certification.ru/cgi-bin/forum.cgi?action=thread&...
>Приветствую!
>
>Интересно вообще у кого-то такое работает?
>Static NAT – Mapping an unregistered IP address to a registered IP
>address on a one-to-one basis.
>Может оно и не предполагает что внешний-внешний будет привязка и все ответные
>пакеты с порта 501
>просто перезаписывает не пользуясь таблицей.
>А что кажет sh ip nat tra | i 79.109.91.140 (или какой
>там)а вот что. Пока пассивно и никого нету, показывает:
tcp 79.109.73.6:501 79.109.91.140:501 --- ---как только пытаюсь из инета обращение сделать на хост который принимает соединения
tcp 79.109.73.6:501 79.109.91.140:501 --- ---
tcp 79.109.73.6:501 79.109.91.140:501 89.213.197.150:49462 89.213.197.150:49462Если обращаюсь на хост на который пробрасывается порт - картинка не меняется:
tcp 79.109.73.6:501 79.109.91.140:501 --- ---
tcp 79.109.73.6:501 79.109.91.140:501 89.213.197.150:57879 89.213.197.150:57879транзакции идентичные в обоих случаях, на какой бы я из хостов не обращался.
>Может стоит попробовать пробросить как в последнем посте тут http://www.certification.ru/cgi-bin/forum.cgi?action=thread&...
Через роутмапы то? попробую.
>[оверквотинг удален]
>
>tcp 79.109.73.6:501 79.109.91.140:501
> ---
> ---
>tcp 79.109.73.6:501 79.109.91.140:501
> 89.213.197.150:57879 89.213.197.150:57879
>
>транзакции идентичные в обоих случаях, на какой бы я из хостов не
>обращался.
>А src порты то поменялись. А если обращаться на целевой хост, то строчки по идее не должно быть. А если она есть то она создается на обратном пакете(т.е. все ответы с 501-го порта целевого хоста просто переписываются).
>>Может стоит попробовать пробросить как в последнем посте тут http://www.certification.ru/cgi-bin/forum.cgi?action=thread&...
>
>Через роутмапы то? попробую.не..., там ip nat inside destination..., последний пост.
>не..., там ip nat inside destination..., последний пост.Помоему заработало :)
Во всяком случае телнеты на оба хоста проходят.
Из дому завтра прогу попробую, которая на этом порту с нашим сервером работает. Если все ок, то решение вот оно.
Спасибо %)
>Может стоит попробовать пробросить как в последнем посте тут http://www.certification.ru/cgi-bin/forum.cgi?action=thread&...Попробовал. Телнеты проходят на оба хоста, как бы работает... Завтра с утра из дому попробую запустить утилитку которая по этому порту с серваком работает, проверю все ли ок.
Вот куск конфига:
ip access-list extended portnat
permit tcp any host 79.109.73.6 eq 501
ip nat pool poolnat 79.109.91.140 79.109.91.140 netmask 255.255.255.0 type rotary
ip nat inside destination list portnat pool poolnat
Народ это круто! Но это костыли... (((
>Народ это круто! Но это костыли... (((Почему костыли?
• Enabling translation of inside destination addresses
ip nat inside destination { list <acl> pool <name>
| static <global-ip> <local-ip> }
This command is similar to the source translation command. For dynamic destination translation to make any sense, the pool should be a rotary-type pool.Вытащить например пассивный ftp наружу. А в этом случае просто один порт. Другое дело зачем так нужно...
>Вытащить например пассивный ftp наружу. А в этом случае просто один порт.
>Другое дело зачем так нужно...Ну в моем случае есть огромная куча хостов которая коннектится к этому сервису на старом сервере. а у меня переезд на новую платформу в самом разгаре. И постепенно клиенты сменят хост на новый. но сервис на старом хосте уже остановлен. А таким образом я обеспечиваю безостановочность работы сервиса и плавную смену без перебоев с этим связанными.
Кстати в этом методе, равно как и в других, все равно не работает еще один варинт. Если попытаться коннектиться с хостов которые сами находятся на интерфейсах меченых как ip nat inside.
У меня в моей конфигурации есть еще несколько интерфейсов - на локалку, на туннели, которые ip nat inside. Так вот с них коннект остался проблемным, но по другому. Тут не работает правило вовсе - коннект на новый хост есть, а коннект на хост который должен пробрасывать пакеты на новый - не работает...Решается это только если я выкидываю интерфейсы наружу роутинга дав им ip nat outside.
но тогда другие косяки... в общем вопрос интересный %)
>ip nat pool poolnat 79.109.91.140 79.109.91.140 netmask 255.255.255.0 type rotarynetmask только 255.255.255.192
>>ip nat pool poolnat 79.109.91.140 79.109.91.140 netmask 255.255.255.0 type rotary
>
>netmask только 255.255.255.192А собственно почему 192? минимум можно 255.255.255.252 тут поставить. тут пул из 1 хоста, но маску 32 поставить нельзя. только 30.
Здесь же вроде бы не обязательно маску ставить точно такую же, какая используется в определении рабочей подсети где идет наттинг. Насколько я помню маска пула и маска подсети это разные вещи.