Работа OSPF маршрутов
-
@werter said in Работа OSPF маршрутов:
@Moron
Если интересно, то у меня на предыщей работе было 28 овпн-туннелей + ospf. Все поднималось\применялось за секунды. Но на обоих концах (головной + филиалы) были пф-ы.Зы. Настройки ospf + правила fw покажите. И таблицу марш-ции на пф.
Openvpn более сотни, с ним проблем нет.
Правила fw все открыто, т.к. все идёт через LAN
Как раз видно 192.168.0.0/16 (чтобы охватить все) и 192.168.12.0/23 (чтобы при экспериментах ничего не сломать) без которых ничего не работает.
Далее идут маршруты пришедшие через OSPF -
@werter said in Работа OSPF маршрутов:
@Moron
Зы. Настройки ospfНастройки OSPF:
Router ID: 10.1.0.1 и 10.1.0.2 соответственно на pfSense и CHRДалее просто анонс LAN интерфейса в Area 0.0.0.0
-
Собрал стенд, где pfSense и CHR связаны между собой сетью 172.31.250.0/24 и там бегает OSPF
За pfSense в сети 192.168.0.0/24 стоит WinXP, а за CHR сеть 192.168.1.0/24 так же стоит XP
Трафик из XP за pfSense свободно ходит в XP за CHR, наоборот не ходит.Далее отключаю полностью firewall на pfSense и все начинает бегать, как задумано.
-
@Moron
Посмотрите журнал файрвола , нет ли там заблокированных пакетов -
@Moron said in Работа OSPF маршрутов:
Трафик из XP за pfSense свободно ходит в XP за CHR, наоборот не ходит.
На pfSense есть multiwan?
Попробуйте добавить повыше на LAN pfSense правило вида
IPv4 * LAN net * 192.168.1.0/24 * * none -
@pigbrother said in Работа OSPF маршрутов:
@Moron said in Работа OSPF маршрутов:
Трафик из XP за pfSense свободно ходит в XP за CHR, наоборот не ходит.
На pfSense есть multiwan?
Попробуйте добавить повыше на LAN pfSense правило вида
IPv4 * LAN net * 192.168.1.0/24 * * noneБез multiwan
На стенде трафик стал бегать при добавлении правила в LAN на весь трафик Disable reply-to, на рабочей системе не помогло.
На рабочей системе в LAN уже есть правило
IPv4 * LAN net * * * * none -
@Moron said in Работа OSPF маршрутов:
IPv4 * LAN net * * * * none
Вы про Default allow LAN to any rule ?
IPv4 * LAN net * 192.168.1.0/24 * * none - это правило для negate rules, в свое время тут обсуждалось.
Оно не перекрывается Default allow LAN to any rule, и необходимо при multiwan, но иногда помогало при single wan. -
@pigbrother said in Работа OSPF маршрутов:
@Moron said in Работа OSPF маршрутов:
IPv4 * LAN net * * * * none
Вы про Default allow LAN to any rule ?
IPv4 * LAN net * 192.168.1.0/24 * * none - это правило для negate rules, в свое время тут обсуждалось.
Оно не перекрывается Default allow LAN to any rule, и необходимо при multiwan, но иногда помогало при single wan.Попробую, отпишусь.
Но как тогда это правило влияет на маршрут прописанный руками и пришедший через OSPF? -
Добрый
@MoronНо как тогда это правило влияет на маршрут прописанный руками и пришедший через OSPF?
Правило fw и маршрутизация - это как теплое vs мягкое.
Правило IPv4 * LAN net * 192.168.1.0/24 * * ЯВНО разрешает доступ в удаленную сеть, ориентируясь при этом на таблицу марш-ции.Правило IPv4 * * * * * разрешает доступ, ориентируясь на ДЕФОЛТНЫЙ gw, к-ый НЕ ЯВЛЯЕТСЯ gw для доступа в удален. сеть.
-
@werter said in Работа OSPF маршрутов:
Добрый
@MoronНо как тогда это правило влияет на маршрут прописанный руками и пришедший через OSPF?
Правило fw и маршрутизация - это как теплое vs мягкое.
Правило IPv4 * LAN net * 192.168.1.0/24 * * ЯВНО разрешает доступ в удаленную сеть, ориентируясь при этом на таблицу марш-ции.Правило IPv4 * * * * * разрешает доступ, ориентируясь на ДЕФОЛТНЫЙ gw, к-ый НЕ ЯВЛЯЕТСЯ gw для доступа в удален. сеть.
IPv4 * LAN net * 192.168.1.0/24 * * не помог.
Отключил вообще Firewall в System/Advanced/Firewall & NAT
Disable all packet filtering.Включил обратно и выключил NAT, перезагрузил pfSense, все равно не работает, но ICMP ходит.
-
@Moron
Скрины правил fw на ВСЕХ интерфейсах + правила NAT + таблицу марш-ции пф покажите. -
@werter said in Работа OSPF маршрутов:
@Moron
Скрины правил fw на ВСЕХ интерфейсах + правила NAT + таблицу марш-ции пф покажите.
-
LAN вроде Passive должен быть? Галка не стоит.
Тут https://forum.netgate.com/topic/147028/%D0%B4%D0%B2%D0%B0-%D0%BF%D1%80%D0%BE%D0%B2%D0%B0%D0%B9%D0%B4%D0%B5%D1%80%D0%B0-%D0%B8-openvpn-%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82/68?_=1606214566753 настраивал ospf (frr). Сравните скрины со своими. У меня с овпн работало.
Зы. В Monitor ip НЕ ПОЛЬЗУЙТЕ шлюз пров-а. Пользуйте , напр., ip гугло-днс (8.8.8.8). Потому что доступность gw про-ва НЕ ВСЕГДА подразумевает наличие Инета.
-
@Moron
Если не выгорит, то я бы рискнул перевести 1-2-3 филиала на овпн (да-да, только tcp и вот это вот всё или ROS 7 beta и овпн по udp) и попробовать связку ovpn +ospf. -
@werter said in Работа OSPF маршрутов:
@Moron
Если не выгорит, то я бы рискнул перевести 1-2-3 филиала на овпн (да-да, только tcp и вот это вот всё или ROS 7 beta и овпн по udp) и попробовать связку ovpn +ospf.Совершенно не приемлю использование OVPN для связи офисов при наличии в каждом IP адесов
LAN вроде Passive должен быть? Галка не стоит.
Поставил пассив, объявляю подключенный маршрут. Но все равно не работает.
Тут https://forum.netgate.com/topic/147028/два-провайдера-и-openvpn-клиент/68?_=1606214566753 настраивал ospf (frr). Сравните скрины со своими. У меня с овпн работало.
У вас овпн подключается к самому шлюзу и он один, у меня такая схема работает без проблем
Зы. В Monitor ip НЕ ПОЛЬЗУЙТЕ шлюз пров-а. Пользуйте , напр., ip гугло-днс (8.8.8.8). Потому что доступность gw про-ва НЕ ВСЕГДА подразумевает наличие Инета.
pfSense стоит в датацентре, так что шлюз либо доступен, либо недоступен
Главный вопрос - как они начинает работать при полностью отключенном firewall, что-то ведь пускает ICMP в обе стороны, но при этом остальной трафик только в одну сторону
-
Главный вопрос - как они начинает работать при полностью отключенном firewall, что-то ведь пускает ICMP в обе стороны, но при этом остальной трафик только в одну сторону
Вкл. логирование на fw и смотрите что там происходит. Пробуйте tracert и с пф и с клиента ЗА пф. Только помните, что tracert в никсах по-дефолту работает по udp.
Совершенно не приемлю использование OVPN для связи офисов при наличии в каждом IP адесов
Наличие адресов тут роли не играет (нужет только один "реальный" ip).
Овпн гибче в настройках, чем ипсек - один порт, можно иметь нес-ко овпн на одном интерфейсе, умеет и tcp и udp, умеет L2 (tap) + L3 (tun), умеет через прокси, умеет "шарить" порт между http, ssh и ovpn, умеет пушить роуты клиентам. В свежем 2.5.0 появилось много вкусного www.opennet.ru/opennews/art.shtml?num=53981
Из минусов овпн вижу, что не все железо из-коробки его умеет. Из плюсов же ипсек только нативная поддержка на множестве оборудования (и то только потому, что ипсек появился раньше) и наличие прямо в никсовом ядре.Зы. Три основные команды одмина - ping, tracert, nslookup ))
-
@Moron
Еще раз все внимательно посмотрел
Что-то мне подсказывает , что у Вас ассиметричная маршрутизация присутствует
Поэтому и не работает ваша схема в одну сторону
Какой шлюз по умолчанию у хостов сети 10.1.0.0/24 ? -
@Konstanti said in Работа OSPF маршрутов:
@Moron
Еще раз все внимательно посмотрел
Что-то мне подсказывает , что у Вас ассиметричная маршрутизация присутствует
Поэтому и не работает ваша схема в одну сторону
Какой шлюз по умолчанию у хостов сети 10.1.0.0/24 ?Шлюз 10.1.0.1, как раз тот pfSense
Верно, ассиметричная, пакет не обязательно должен идти тем же путем :)
CHR отправляет запрос сразу на хост, хост отвечает уже через pfSense.
Чтобы эта схема работала, включен Bypass firewall rules for traffic on the same interface
Маршруты через OSPF приходят аналогичные, что я прописываю руками, но без прописывания руками трафик ходит только в одну сторону, ICMP при этом в обе стороны. А если вообще выключить фаервол, весь трафик ходит нормально во все стороны. -
@Moron
Вот смотрите ,
к серверу от офиса
192.168.12.0/24->10.1.0.2->10.1.0.25
и обратно
10.1.0.25->10.1.0.1->10.1.0.2->192.168.12.0/24
видите разницу ?сервер всегда ждет ответный пакет от 10.1.0.1 ( а получает ответы напрямую от 10.1.0.2 )
тут нужен NAT Reflection , по-моему ( чтобы 10.1.0.2 слал пакеты 10.1.0.1, а не напрямую 10.1.0.25)
или проще на сервере прописать 1 статический маршрут
192.168.0.0/16 через 10.1.0.2 -
@Konstanti said in Работа OSPF маршрутов:
@Moron
Вот смотрите ,
к серверу от офиса
192.168.12.0/24->10.1.0.2->10.1.0.25
и обратно
10.1.0.25->10.1.0.1->10.1.0.2->192.168.12.0/24
видите разницу ?Разницу вижу и понимаю, pfSense должно быть все равно, что пакет идет другим путем, но ему становится все равно когда я выключаю полностью farewall
сервер всегда ждет ответный пакет от 10.1.0.1 ( а получает ответы напрямую от 10.1.0.2 )
Тогда почему при статичном маршруте работает?
тут нужен NAT Reflection , по-моему ( чтобы 10.1.0.2 слал пакеты 10.1.0.1, а не напрямую 10.1.0.25)
Вижу, что проблема в фаерволе, pfSense блочит, а городить NAT не правильный подход
