Вопрос по маршрутизации между VLAN
-
@werter said in Вопрос по маршрутизации между VLAN:
@antonr69
Вот хороший мануал по VLAN на пф https://nguvu.org/pfsense/pfsense-baseline-setup/Спасибо. Годная вещь.
-
@antonr69 Надо не пинговать а делать tracert. Очень легко может оказаться что у вашего провайдера где-то есть такой же IP внутри сети. Или не вашего, а вышестоящего. И пинговать вы будете не свой девайс.
Просто если не указывать gateway, то будет работать в соответствии с таблицей маршрутизации PF и тогда да, вполне что там есть роут до всех вланов. Но если указать шлюзом то через что вы ходите в инет, то там маршрутов до ваших вланов ни как быть не может. -
@sirota
Спасибо, учту. -
@antonr69
Вообщето, да, можно обойтись и двумя правилами, если во втором правиле изменить на разрешить, а в дист сделать инвертирование.
-
@werter said in Вопрос по маршрутизации между VLAN:
@antonr69
Ок
1-е - оставляем.
2-е - в src - VLAN net (вашу влан-сеть) и в Шлюз - указать имя шлюза в Инет.
3-е - откл
Сбросить states для чистоты.
Всё.Зы. Еще. Никогда не используйте VLAN 1 - это СЛУЖЕБНЫЙ тег.
Зы2. И русский в вебках ИНОСТРАННОГО ПО тоже не пользуйте. Это дурной тон.Короче странно, но не работает действительно:
К сожалению девайса за PF в этой подсети у меня подконтрольного нет чтобы с него проверить. Но в переделах интерфесов PF ни чего не работает.
А вот это вообще финиш:
и результат тот же, маршрут разрешается. 192.168.0.228 находится в подсети Lan net -
- Ping разрешен ТОЛЬКО на GUEST address.
- Трафик разрешен ТОЛЬКО через шлюз FailoverGroup, к-ый существует для выхода в инет.
Вопрос: C какого перепугу будет доступен хост 192.168.0.228 (сеть LAN) из сети GUEST, если для него НЕТ разрешающего правила?
ВЫШЕ правила с FailoverGroup добавьте правило для доступа в сеть LAN. В gw указать GUEST_GW (или ничего не указывать - проверить). При этом ВСЕ правила deny to other net должны быть откл.
-
@werter said in Вопрос по маршрутизации между VLAN:
- Ping разрешен ТОЛЬКО на GUEST address.
- Трафик разрешен ТОЛЬКО через шлюз FailoverGroup, к-ый существует для выхода в инет.
Вопрос: C какого перепугу будет доступен хост 192.168.0.228 (сеть LAN) из сети GUEST, если для него НЕТ разрешающего правила?
ВЫШЕ правила с FailoverGroup добавьте правило для доступа в сеть LAN. В gw указать GUEST_GW (или ничего не указывать - проверить). При этом ВСЕ правила deny to other net должны быть откл.
Ну... вот и я не пойму.
Reset states сделал естественно. -
@werter said in Вопрос по маршрутизации между VLAN:
- Ping разрешен ТОЛЬКО на GUEST address.
- Трафик разрешен ТОЛЬКО через шлюз FailoverGroup, к-ый существует для выхода в инет.
Вопрос: C какого перепугу будет доступен хост 192.168.0.228 (сеть LAN) из сети GUEST, если для него НЕТ разрешающего правила?
ВЫШЕ правила с FailoverGroup добавьте правило для доступа в сеть LAN. В gw указать GUEST_GW (или ничего не указывать - проверить). При этом ВСЕ правила deny to other net должны быть откл.
А вот тут у меня вообще взрыв шаблона
-
FailoverGroup - это gw для ИНТЕРНЕТА. Зачем его использовать для доступа из GUEST net в LAN net (2-й вопрс. знак) ?
Касаемо 1-го вопрс. знака.
Для доступа из GUEST net в LAN достаточно РАЗРЕШАЮЩЕГО правила:
IPv4* GUEST net * LAN net * *
Всё. Никаких GUEST address и т.д.GUEST address - это адрес САМОГО пф-а. Не надо его трогать без понимания.
Зы. Дорогие мои. Мой вам совет - начните работу с сетями со более СЛОЖНОГО. Купите б\у Микротик (или новый hap lite ~ 20$) и на нем потренируйтесь. Осилите МТ - велком ту пф. Нет? До свидания, it - это не ваше.
Есть множество др. достойных профессий. Потому как очередной идиотизм на рынке вакансий. В 90-е все в юристо-экономисты перлись за баблом, сейчас - в it.
И разочарую тех, кто думает, что курсы типа "За 1-2-3 месяца в девопсы\программисты" и т.д. чем-то помогут. Не помогут. Это ГОДЫ труда и борьбы с собою, с собственной ленью прежде всего. Это ГОДЫ (само)обучения. Простите, но назрело. Уже "залюбился" объяснять элементарные вещи (Зы3. Прекрасный и БЕСПЛАТНЫЙ курс по сетям. В закладки (для тех кто ХОЧЕТ)
https://linkmeup.ru/blog/1188/
https://linkmeup.gitbook.io/sdsm/
Пользую сам.Зы4. Кому интересно. Список ресурсов, к-ые просматриваю ЕЖЕНЕДЕЛЬНО. Нес-ко ДЕСЯТКОВ штук. Мои "университеты", т.с.
-
@werter said in Вопрос по маршрутизации между VLAN:
FailoverGroup - это gw для ИНТЕРНЕТА. Зачем его использовать для доступа из GUEST net в LAN net (2-й вопрс. знак) ?
Касаемо 1-го вопрс. знака.
Для доступа из GUEST net в LAN достаточно РАЗРЕШАЮЩЕГО правила:
IPv4* GUEST net * LAN net * *
Всё. Никаких GUEST address и т.д.GUEST address - это адрес САМОГО пф-а. Не надо его трогать без понимания.
Зы. Дорогие мои. Мой вам совет - начните работу с сетями со более СЛОЖНОГО. Купите б\у Микротик (или новый hap lite ~ 20$) и на нем потренируйтесь. Осилите МТ - велком ту пф. Нет? До свидания, it - это не ваше.
Есть множество др. достойных профессий. Потому как очередной идиотизм на рынке вакансий. В 90-е все в юристо-экономисты перлись за баблом, сейчас - в it.
И разочарую тех, кто думает, что курсы типа "За 1-2-3 месяца в девопсы\программисты" и т.д. чем-то помогут. Не помогут. Это ГОДЫ труда и борьбы с собою, с собственной ленью прежде всего. Это ГОДЫ (само)обучения. Простите, но назрело. Уже "залюбился" объяснять элементарные вещи (Зы3. Прекрасный и БЕСПЛАТНЫЙ курс по сетям. В закладки (для тех кто ХОЧЕТ)
https://linkmeup.ru/blog/1188/
https://linkmeup.gitbook.io/sdsm/
Пользую сам.Зы4. Кому интересно. Список ресурсов, к-ые просматриваю ЕЖЕНЕДЕЛЬНО. Нес-ко ДЕСЯТКОВ штук. Мои "университеты", т.с.
Дамс... Ты упускаешь суть непонимания.
Тут все правила кроме первых трех отключены. Согласно им мы запрешаем пакеты ip4 до узла 198.168.0.228, разрешаем доступ к GuestNet на интерфейсе Guest с маршрутом по умолчанию (не представляю зачем оно, но допустим пусть будет, по идее мы боролись там за то чтобы пинговать сам PF), потом разрешаем все, но только через группу шлюзов:
А все остальное по дефолту у нас запрещено.
Делаем пинг с самого ПФ (ведь правила эти и его касаются?)
Как так получается? reset states делал.Т.е. мы изначально вообще все эти пакеты запретили. а во вторых мы их еще потом и отправляем в интерфейс где нет этого назначения "априори".
И. Все я понимаю в плане что и зачем. Теперь на твои вопросики:
- "Касаемо 1-го вопрс. знака." ПРинудительно создаю правило в которые 100% должен попасть под пинг 192.168.0.228. Но не работает! Скорее всего сработает на устройствах в сети guest, но отличных от guest address (хотя я и это предусмотрел, но пофиг).
- Второй. Я принудительно для интерфейса Guest говорю "искать подсеть Lan net вот на этом шлюзе". Но он не ищет его на этом шлюзе, он берет его из таблицы маршрутизации по умолчанию и прямиком попадает именно в мою подсеть (об этом говорит и трассировка и очень малое время ответа.)
Выходит что непосредственно для самого PF все эти правила не работают?
По поводу микрота, там все предельно ясно. Input (то где дестенейшен сам микрот (любой его интерфейс)), Forward (все что проходит сквозь микрот) и Output (то что генерит сам микрот (его интерфейсы)). Если я создам правило к примеру с сорцем vlan10 и дестенейшеном vlan11 для цепочки форвард и буду дропать пакеты, то из подсети vlan10 я не получу доступ до vlan11, даже если маршрут определен, но при этом я смог пингануть с интерфейса микрота смотрящего в vlan10 подсеть vlan11. Чтобы это запретить надо создать такое же правило, но уже в цепочке output. Теперь вопрос - как это сделать для ПФ? И как так получается что я для интерфейса указываю что подсеть lan net надо искать на "шлюзе в интернете", а он все равно идет прямо в lan?
Сделай у себя тоже самое интереса ради. Человек же говорит что так у него не выходит изоляция вланов. Хотя я всеми руками за твое решение, оно изящно, но как видим почему-то не работает. ЗЫ во флоатинге у меня пусто.
-
@sirota said in Вопрос по маршрутизации между VLAN:
Как так получается? reset states делал.
Выходит что непосредственно для самого PF все эти правила не работают?Да, первым сверху правило мы запрещаем только проходящий через пф трафик (forwarding) до узла. И да, на сам пф это правило не действует.
Если всеже надо ограничить сам пф - идем во флоатинг рулез и там рисуем, использую в src - This firewall.
По поводу микрота, там все предельно ясно. Input (то где дестенейшен сам микрот (любой его интерфейс)), Forward (все что проходит сквозь микрот) и Output (то что генерит сам микрот (его интерфейсы)).
Там ДАЛЕКО не все так просто, поверь.
Кроме Input, Forward , Output есть еще Prerouting и Postrouting, к-ые играют важную роль.
https://mikrotik.wiki/wiki/%D0%9C%D0%B5%D0%B6%D1%81%D0%B5%D1%82%D0%B5%D0%B2%D0%BE%D0%B9_%D1%8D%D0%BA%D1%80%D0%B0%D0%BD:%D0%A1%D1%85%D0%B5%D0%BC%D0%B0_%D0%BF%D1%80%D0%BE%D1%85%D0%BE%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F_%D1%82%D1%80%D0%B0%D1%84%D0%B8%D0%BA%D0%B0И блокировать трафик на МТ можно (нужно) не допуская трафик до цепочки Input - еще в RAW, тем самым снижая нагрузку на роутер.
А уж по теме "Как ПРАВИЛЬНО балансировать нагрузку при мультиване на МТ" ТАКИЕ битвы на форумах идут, что закачаешься ) Там и ECMP, и VRRP, и PCC.
-
@werter said in Вопрос по маршрутизации между VLAN:
Да, первым сверху правило мы запрещаем только проходящий через пф трафик (forwarding) до узла. И да, на сам пф это правило не действует.
Если всеже надо ограничить сам пф - идем во флоатинг рулез и там рисуем, использую в src - This firewall.
Не. все равно не работает:
Пингует...@werter said in Вопрос по маршрутизации между VLAN:
Там ДАЛЕКО не все так просто, поверь.
Это к нашему вопросу отношения не имеет.
-
Не. все равно не работает
И не будет.
Галки на Quick нет.Зы. У пф хорошая дока. И по Флоатинг рулез тоже.
-
@werter Есть. Просто скрин сделал до того как поставил ее.
-
Добрый день. Стесняюсь спросить. Вот в ходе обсуждения был показан скрин правил в котором были два правила для dns. В каком случае они нужны? у меня и без них работает.
-
@antonr69 said in Вопрос по маршрутизации между VLAN:
Добрый день. Стесняюсь спросить. Вот в ходе обсуждения был показан скрин правил в котором были два правила для dns. В каком случае они нужны? у меня и без них работает.
Не всем клиентским устройствам в сети разрешено ходить везде. Чтобы определить можно ли клиентскому устройству пройти на нужный к примеру сайт необходимо чтобы клиент узнал ip адрес этого сайта и попробовал на него перейти. Так вот чтобы клиентское устройство узнало куда ему точно надо перейти всем разрешен доступ к службе DNS resolver пфсенса. Это второе правило. Первое правило с 127.0.0.1 нужно т.к. стоит правило редиректа, если клиент отправит пакет udp или tcp на 53 порт на устройство отличное от интерфейс пфсенса, то пакет будет переадресован на localhost пфсенса. Т.е. без разницы какой у клиента dns настроен, его запрос всегда обработаем именно мы (ну если мы у него основной шлюз).
Если у вас все устройства в сети ходят в инет, то оно вам не нужно. Но тогда я бы вообще вопрос потребности как такового пфсенса бы поднял. Какого-нибудь mikrotik hex s с включенным fasttrack вам мы было за глаза. -
@sirota said in Вопрос по маршрутизации между VLAN:
Не всем клиентским устройствам в сети разрешено ходить везде. Чтобы определить можно ли клиентскому устройству пройти на нужный к примеру сайт необходимо чтобы клиент узнал ip адрес этого сайта и попробовал на него перейти.
Это могут делать не только лишь все, не каждый может это делать...
Как бы понятно, но в тоже время не понятно. В вашем ответе есть посыл на ограничение доступа к DNS для ограничения доступа клиентов в интернет, но в тоже время оба этих правила сделают так, что клиент даже при не верно указанном DNS все равно его получит. Непонятно что задумал автор, толи ограничить, толи всем дать. Мне как то видится ограничение интернета немного по другому. Например, создание алиаса клиентских адресов которым можно выйти в интернет, или использовать средства Squid для ограничения к сайтам. Или допустим, запрерить всем все, но сделать алиас со списком разрешенных сайтов (служб скайп, вайбер) для посещения. Да и DNS нужен для разрешения имени, а если клиент пойдет не по имени, а по адресу, то DNS ему не нужен будет. По адресу он и так попадет. Какое же тут ограничение моя не понимать.
-
@antonr69 said in Вопрос по маршрутизации между VLAN:
что клиент даже при не верно указанном DNS все равно его получит
Речь не о непредставлении службы DNS клиенту.
@sirota said in Вопрос по маршрутизации между VLAN:
Т.е. без разницы какой у клиента dns настроен
Именно. Чуть расширю ответ:
Клиент защищен от подмены DNS на его локальном ПК.
Это же делает бессмысленным попытки клиента самостоятельно сменить DNS на на его локальном ПК. -
@pigbrother said in Вопрос по маршрутизации между VLAN:
Именно. Чуть расширю ответ:
Клиент защищен от подмены DNS на его локальном ПК.
Это же делает бессмысленным попытки клиента самостоятельно сменить DNS на на его локальном ПК.Спасибо. А вот это супер полезная опция. Есть вирусы которые пытаются подменить dns. А еще тогда вопросик. В предыдущей организации был керио-контрол. Периодически хром на клиентских машинах переставал открывать сайты. Выполняешь ipconfig /flushdns и проблема тут-же исчезала. При наличии таких двух правил что обсуждали выше, я так понимаю, таких проблем возникать не должно?
-
@antonr69 said in Вопрос по маршрутизации между VLAN:
При наличии таких двух правил что обсуждали выше, я так понимаю, таких проблем возникать не должно?
Трудно сказать. Эти правила не лечат проблемы DNS на локальном ПК.
