fregatte

Теперь буду знать. Выглядит действительно правильнее, чем извращения с ACL. Спасибо всем за помощь!

Хочется именно этого. Я хочу, чтобы на пинг отвечал именно роутер, по всем IP-адресам, которые мне выдал провайдер. Потому что это наиболее простой способ контролировать, что провайдер не разломал у себя маршрутизацию и пакеты из внешней сети вообще добегают до роутера. Когда ответа роутера на пинг нет, при любых возникших проблемах возникает вопрос, это провайдер у себя что-то сломал или просто нат перестал работать на рутере? Каким образом убедиться, что пакет долетел до роутера? Причем тут маршруты? Провайдер выдал /29 белую сеть, в которой (и за которой) заведомо не может быть серых адресов. Так зачем мне выпускать за периметр пакеты с адресами назначения серых сетей? Коротко опишу, что хочется сделать. Есть несколько белых адресов, которые выдал провайдер. 1) Хочется чтобы по всем IP-адресам на пинг отвечал сам роутер. Это просто удобно для контроля живости интерфейса. 2) Один из адресов используется для динамического ната внутренних хостов наружу (в моем случае, это 60-й адрес, который отведен под nat overload). 3) На остальных адресах хочется пробросить отдельные порты на различные хосты внутри сети (у меня этого пока не написано), то есть нат адрес-в-адрес не подходит. Насколько это реализуемо? Пока ни один человек так и не объяснил, в чём проблема использовать secondary-интерфейсы, однако все говорят, что это плохо. Где об этом написано? Кто-нибудь может внятно объяснить почему?

Я уже писал выше. Если убрать адрес с интерфейса, он становится недоступен изнутри и снаружи роутера. А именно, роутер не отвечает по этому адресу на пинг и не работает статик-нат по конкретным портам на этом IP. При такой настройке в нат попадают, например, пакеты у которых src - 10.78.18.12, а dst - 192.168.20.20. То есть мы NAT-им в сеть провайдера пакеты к серым адресам, что в общем-то моветон. Зачем сделаны отдельные deny по каждому из 58-62, тоже написано выше, без них, трафик к этим адресам попадает в нат и не возвращается к 10.78.18.12. Собственно, на конкретный вопрос так никто и не ответил. Почему два secondary-адреса (58 и 59, например) с одинаковой настройкой работают на роутере по разному, на одном из них SSH-сервис роутера отдается, а на втором нет?

К сожалению, не помогло. Всё осталось точно так же, на 58-м адрес не отвечает.

Сделал вот так: interface GigabitEthernet0/1 description OUTSIDE_MAIN ip vrf forwarding VRF_MAIN ip address a.b.c.58 255.255.255.248 secondary ip address a.b.c.59 255.255.255.248 secondary ip address a.b.c.60 255.255.255.248 secondary ip address a.b.c.61 255.255.255.248 secondary ip address a.b.c.62 255.255.255.248 ip access-group FILTER_ISP_MTS_IN in ip access-group FILTER_ISP_MTS_OUT out no ip redirects ip nat outside ip virtual-reassembly in load-interval 30 duplex auto speed auto no cdp enable ip access-list extended NAT_SRC deny ip any 10.0.0.0 0.255.255.255 deny ip any 172.16.0.0 0.15.255.255 deny ip any 192.168.0.0 0.0.255.255 deny ip any host a.b.c.58 deny ip any host a.b.c.59 deny ip any host a.b.c.60 deny ip any host a.b.c.61 deny ip any host a.b.c.62 permit ip host 10.78.18.12 any ip nat pool EXT_IP x.y.z.60 x.y.z.60 netmask 255.255.255.248 ip nat inside source list NAT_SRC pool EXT_IP vrf VRF_MAIN overload При такой настройке всё работает почти так, как нужно. Все адреса на интерфейсе доступны как снаружи, так и изнутри сети. Под "доступны", я имею ввиду, что они отвечают на пинг. Но осталось несколько странностей. 1. Можно пояснить, почему нужно снимать с интерфейса адрес, который используется для NAT? Если я снимаю с интерфейса адрес, который сейчас используется в нат-пуле, пропадает связь ПК (10.78.18.12) со шлюзом провайдера и внешним миром. 2. И второй момент. В такой конфигурации я для проверки потыкался в SSH, запущенный на роутере и получил странный результат: a.b.c.58 - SSH не доступен (why?) a.b.c.59 - SSH доступен a.b.c.60 - SSH не доступен (что судя по всему логично, у нас этот адрес под nat overload) a.b.c.61 - SSH доступен a.b.c.62 - SSH доступен Почему недоступен SSH на 58-м IP-адресе? Он ничем не отличается от 61-го, на котором SSH отвечает.

Опять же, если вы посмотрите, то в нат-пул сейчас добавлен только один secondary-адрес, а недоступны все secondary. Я как-то не улавливаю связи.

Не вопрос, можете дать какие-то рекомендации, как надо вешать? Существует вариант настроить это так, чтобы адрес был доступен одновременно изнутри, снаружи и через него можно было натить? Повесить на разные сабинтерфейсы нельзя потому что рутер ругается на пересечение сетей на разных сабинтерфейсах. Вешать на разные физические outside-интерфейсы очень не хочется, потому что у меня уже сейчас две /29 на рутере, есть вероятность, что будет еще. Не отдавать же под каждый адрес физический порт?

Добрый вечер. Возникла непонятная проблема при настройке NAT-a на роутере. На схеме показана текущая рабочая конфигурация. С ПК имею доступ к роутеру и могу пинговать все его внешние интерфейсы с белыми адресами (x.y.z.58-62). Доступа к ISP при такой настройке мы понятно не имеем. Добавляю к текущей схеме следующие правила для NAT-а: ip access-list extended NAT_SRC deny ip any 10.0.0.0 0.255.255.255 deny ip any 172.16.0.0 0.15.255.255 deny ip any 192.168.0.0 0.0.255.255 permit ip host 10.78.18.12 any ip nat pool EXT_IP x.y.z.60 x.y.z.60 netmask 255.255.255.248 ip nat inside source list NAT_SRC pool EXT_IP vrf vrf_main overload И тут происходит магия, с ПК получаю доступ к шлюзу провайдера и Интернету, однако перестают пинговаться все белые secondary-интерфейсы роутера. Опытным путем выяснил, что это не зависит от того как делать NAT через pool или через interface. При установке одного из secondary-интерфейсов в качестве primary на Gi0/1 он начинает пинговаться изнутри сети, а secondary-интерфейс (бывший primary) отваливается. Что я делаю не так?