Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Разрешить ВСЁ с WAN на LAN на USG Pro 4, UniFi Network
 
Всем привет, гуру Ubiquiti! Пытаюсь понять, как разрешить весь трафик с интерфейса WAN1 проходить на мои сети через интерфейс LAN1 — примерно как правило ANY ANY в других роутерах и файрволах. Вот моя конфигурация...

NAT успешно отключен благодаря этой статье: https://community.ui.com/questions/c96beb72-7784-4265-9706-a18a0d418f9f  
Однако, так как я использую USG Pro 4, в моём config.gateway.json файл использует eth2 вместо eth0.

Я проверил, что NAT отключен, общаясь с сетевым устройством, подключённым вне моего WAN1 интерфейса, с ноутбука, который был подключён к LAN1 интерфейсу. Сетевое устройство успешно видело мой IPv4 как адрес LAN, назначенный на LAN1.

USG Pro 4 WAN1 интерфейс = 172.16.99.50 /24 с дефолтным шлюзом @ 172.16.99.1  
Если подключить Ethernet ноутбука к тому же свитчу, где подключен USG Pro 4 WAN1, ноутбук получает IP 172.16.99.101 /24, дефолтный шлюз 172.16.99.1

USG Pro 4 LAN1 интерфейс = 10.6.2.1 /24  
Если подключить Ethernet ноутбука к тому же свитчу, что за LAN1, ноутбук получает IP 10.6.2.100 /24, дефолтный шлюз 10.6.2.1

Доступны пингуемые устройства на LAN1: 10.6.2.10, 10.6.2.11, 10.6.2.12, 10.6.2.13 и так далее.

Роутер, который находится в том же layer 2 свитче, что и WAN1 интерфейс USG Pro 4, имеет IP 172.16.99.1  
В этом роутере настроен статический маршрут для 10.6.2.0 /24 (подсеть LAN USG Pro 4) через 172.16.99.50 (IP WAN1 USG Pro 4).

Если я подключаю ноутбук в тот же layer 2 свитч, что и WAN1 USG Pro 4, ноутбук получает IP 172.16.99.101 /24 с дефолтным шлюзом 172.16.99.1. Но отсюда я НЕ МОГУ:  
- получить ответ на ping 172.16.99.50 (WAN1 USG Pro 4)  
- получить ответ на ping 10.6.2.1, 10.6.2.10, 10.6.2.11, 10.6.2.12... хотя если подключиться ноутбуком к layer 2 свитчу, который за LAN1, ответы на пинги приходят без проблем.

Я изучил туториалы по правилам файрвола USG, прочитал около двух десятков тем на форуме UniFi Routing, перепробовал кучу вариантов ANY to ANY правил, несколько раз буквально бился головой об стену — и всё равно не могу понять этот момент. Поэтому обращаюсь к вам, богам мира Ubiquiti, с просьбой помочь. Что я упускаю? Как мне:  
- заставить WAN1 отвечать на ping?  
- разрешить весь трафик, который приходит на WAN1 и направлен в подсеть LAN1, проходить сквозь роутер?

Плюсальный вопрос:  
- Можно ли настроить так, чтобы WAN1 позволял опрашивать SNMP-интерфейс?

Для контекста, и если кому интересно, зачем мне вообще разрешать весь трафик с внешней сети... Мой USG Pro 4 соединяет LAN здания с большим корпоративным MetroE WAN, и я полностью доверяю всем данным, которые приходят в мою LAN с MetroE WAN.

Как всегда, спасибо всем за прочтение и любую помощь, которую сможете предоставить!
 
И вот, я наконец решил проблему с пингом!!!!!! ВУХУУУУУ!!!!!! Для этого нужно создать правило в WAN LOCAL: Настройки -> Маршрутизация и брандмауэр -> Брандмауэр -> WAN LOCAL  
Имя: Отвечать на Ping  
Включено: ВКЛ  
Правило применяется: до предопределённых правил  
Действие: Принять  
Протокол: Все  
Логирование: Включено (мне так удобнее)  
Состояния: все сняты (предполагаются все состояния)  
Не сопоставлять пакеты IPsec  

Тип источника: Группа адресов/порта  
Группа адресов: выбрать группу (оставить пустым)  
Тип назначения: Группа адресов/порта  
Группа адресов: выбрать группу (оставить пустым)  
Нажмите Сохранить  

И теперь я могу пинговать интерфейсы WAN1 и LAN1 с моего RMM! Сегодня был отличный день!!! Надеюсь, это кому-то поможет.
 
Итак, я задумался над своей ситуацией и решил немного покопаться в правилах... Мое первоначальное правило, которое я назвал «WAN In - Allow All», было рекомендовано технической поддержкой UBNT следующим образом...

Нужно создать правило разрешения в WAN IN. Обратите внимание на следующее правило:

Имя: на ваше усмотрение.  
Включено: ВКЛ  
Правило применяется: перед стандартными правилами  
Действие: Разрешить  
Протокол: Все  
Логирование: на ваше усмотрение  
Состояния: все сняты (предполагает все состояния)  
Не применять к IPsec-пакетам  

Тип источника: Address/Port Group  
Группа адресов: создайте группу адресов с любым именем и адресом 172.16.99.0/24  
Тип назначения: без изменений (оставьте пустым)  
Нажмите «Сохранить»  

Потом я вернулся к своему правилу «WAN IN» и убрал группу адресов. Теперь это выглядит так...

Нужно создать правило разрешения в WAN IN. Обратите внимание на следующее правило:

Имя: WAN In - Allow All  
Включено: ВКЛ  
Правило применяется: перед стандартными правилами  
Действие: Разрешить  
Протокол: Все  
Логирование: включено  
Состояния: все сняты (предполагает все состояния)  
Не применять к IPsec-пакетам  

Тип источника: Address/Port Group  
Группа адресов: выбрать группу (оставить пустым)  
Тип назначения: Address/Port Group  
Группа адресов: выбрать группу (оставить пустым)  
Нажмите «Сохранить»  

Теперь весь трафик с подсетей других наших зданий свободно проходит в эту сеть, и мне больше не надо постоянно обновлять группу адресов каждый раз, когда мы подключаем новое здание к нашему WAN.  

Надеюсь, это кому-то поможет!
 
Привет, Mellis — на этот ответ я скажу и да, и нет. Нашёл ли я приемлемое решение или обходной путь, чтобы всё заработало для меня? Да. Нравится ли мне это решение или обход? Нет. ДА!!! Смотри мои два предыдущих поста ниже про необходимые изменения и дополнительное правило WAN Local. Вот что мне наконец прислала служба поддержки UBNT второго уровня (через несколько недель после открытия моего тикета).

Опять же, это решение предполагает, что NAT на твоём USG уже отключён и что в роутере сверху настроены нужные маршруты, чтобы найти сеть, которая находится на LAN стороне твоего USG.

Проблема в том, что у меня…  
Мой интерфейс WAN1 — 172.16.99.50  
Мой интерфейс LAN1 — 10.6.2.1  

Я НЕ МОГУ ПИНГОВАТЬ НИ ТОТ, НИ ДРУГОЙ С ВЕРХНЕГО РОУТЕРА!!!  
Если я нахожусь в сети 172.16.99.1 (IP моего верхнего роутера, который напрямую подключён к WAN1), я не могу пропинговать ни 172.16.99.50, ни 10.6.2.1.  

Однако я МОГУ пропинговать свой тестовый ноутбук, который стоит за LAN1 с адресом 10.6.2.14!  

Причина, по которой мне раздражает невозможность пропинговать 172.16.99.50 или 10.6.2.1, в том, что моя удалённая система управления и мониторинга использует ping как один из множества факторов для определения, онлайн ли устройство и работает ли оно. Без пинга мне пришлось придумывать странные обходные пути, чтобы моя RMM могла отчитываться о том, в сети ли устройство или нет.  

Желаю удачи в твоих экспериментах! Если найдёшь что-то новое — обязательно напиши обратно!  

С наилучшими пожеланиями,  
Brad
 
У меня та же проблема. Ты так и разобрался с ней?
 
Это было очень полезно, но всё равно не позволяет пропускать трафик по портам. Чтобы трафик по портам работал, нам всё ещё нужно настроить правила проброса портов и использовать WAN IP на USG в качестве адреса назначения.
 
Спасибо — у меня была похожая проблема, и твой пост очень помог. С наилучшими пожеланиями.
Страницы: 1
Читают тему (гостей: 1)