Статические маршруты.
-
А почему бы не сделать так, добавив сетевую карточку в pfsense, через которую пропустить трафик КШ? А в static routes pfsense прописать подсети, которые за КШ, установив сам КШ как шлюз.
а на новой сетевой карточке без разницы какой будет IP адрес 192.168.50.xx который из КШ в pf будет приходить? static routes что то типо этого? а rules нужны будут на LAN?
-
А почему бы не сделать так, добавив сетевую карточку в pfsense, через которую пропустить трафик КШ? А в static routes pfsense прописать подсети, которые за КШ, установив сам КШ как шлюз.
а на новой сетевой карточке без разницы какой будет IP адрес 192.168.50.xx который из КШ в pf будет приходить? static routes что то типо этого? а rules нужны будут на LAN?
Немного не понял вопроса. В принципе адрес КШ может быть любым, все настраивается. Лишь бы указать, какая подсеть скрывается за ним. "Рулить" lan-сетью в этом случае будет pfsense, и, например, можно указать шлюз по-умолчанию 192.168.50.6 для интернета (в настройках сервера DHCP), а для доступа к ресурсам openVPN указать шлюз 192.168.50.1 в static routes. В этом случае подсеть для lan клиентов может быть своя.
-
спасибо за совет! возможности управлять КШ к сожалению нет (да думаю если и попросить то врятли разрешат), т.е коммутатор с L3 это я так понимаю управляемый коммутатор? если я его ставить то на нем настраивается маршрутизация? исходя из моей схемы подключения мне его до КШ ставить нужно или как? еще вопросик а если я все же поставлю pf до своего КШ в тихоря ото всех что и куда нужно будет настраивать, т.е из железки Ростелекома в pf c pf в КШ и из КШ в LAN или как?
сейчас подключено так:
Не используйте сторонние сервисы для картинок. Некоторые как раз и ставят pfSense для защиты от них :).
Но вернемся к лирике.Можно оставить pfSense маршрутизатором по умолчанию и настроить на нем маршруты на адреса за КШ, но тогда скорее всего придется повешать NAT на все эти пакеты и с той стороны вас будут видеть как один компьютер(pfSense).
А L3 комутатор просто ставиться в сети.
-
А почему бы не сделать так, добавив сетевую карточку в pfsense, через которую пропустить трафик КШ? А в static routes pfsense прописать подсети, которые за КШ, установив сам КШ как шлюз.
а на новой сетевой карточке без разницы какой будет IP адрес 192.168.50.xx который из КШ в pf будет приходить? static routes что то типо этого? а rules нужны будут на LAN?
Немного не понял вопроса. В принципе адрес КШ может быть любым, все настраивается. Лишь бы указать, какая подсеть скрывается за ним. "Рулить" lan-сетью в этом случае будет pfsense, и, например, можно указать шлюз по-умолчанию 192.168.50.6 для интернета (в настройках сервера DHCP), а для доступа к ресурсам openVPN указать шлюз 192.168.50.1 в static routes. В этом случае подсеть для lan клиентов может быть своя.
если можно напишите подробнее, тоже не совсем понял т.е сейчас у моего КШ IP 192.168.50.1 LAN, новую сетевую которую я сейчас в pf вставил в ней ставим Static IPv4 и какой IP любой или такой же 192.168.50.1 но он не присваивается так как находится в одном сегменте? у меня DHCP не на pf а на контроллере домена RODC. получается IP КШ на нем на самом прописан жестко из нашей локали, т.е вставлю я с него патч корд в новую сетевую в pf и что дальше не пойму вообще, на сетевом интерфейсе то какой IP прописывать? и IP КШ 50.1 будет играть какую то роль или же уже нет. запутался…
к примеру я воткнул провод с КШ в pf, в pf на сетевом интерфейсе прописал к примеру IP 192.168.59.1, а в КШ сейчас прописан 192.168.50.1 мне его поменять нужно там или как, зайти и менять на нем что либо я не могу, а на сетевом интерфейсе IP с 50.xx никакой прописать не получается, как быть? -
в общем:
1. воткнул провод (еще не воткнул) от КШ в новую сетевую карту pf
2. присвоил новому сетевому интерфейсу имя и IP адрес 192.168.59.1
3. создал новый шлюз с IP 192.168.59.1
4. создал статический маршрут - тут вопрос какой шлюз ставить? 50.1 или новый 59.1, если последний то какую роль играет 50.1 ?
еще вопрос если пинговать по имени сервера то у них IP адреса у некоторых 192.168.0.3 к примеру и пошли еще с другими IP адресами и та же ситуация с другими серверами но они к примеру 192.168.1.7 и так же пошли еще несколько серверов из этой подсети, там где я указывал статические маршруты на скрине я правильно указал на всю же подсеть получается 192.168.0.0 и 192.168.1.0 ? или я что то не так делаю? пока не пробовал но что то сомневаюсь что я в правильном направлении, рабочий день закончится буду пробовать. -
попробовал так как писал выше, ничего не вышло :'(
когда я оставляю схему подключения такую как изначально:- создаю статический маршрут на 192.168.0.0/16 шлюз 192.168.50.1
- создаю статический маршрут на 192.168.1.0/24 шлюз 192.168.50.1
при этом в сетевом адаптере ставлю шлюз своего pf 192.168.50.6
то связь с удаленными серверами есть а именно есть пинг по именам и по IP но программы не работают нет соединения и все тут, ах да еще правила создавал на 192.168.0.0/16 и 192.168.1.0/24, куда копать, и пинги идут вроде бы но не работает и все тут.
может я с подсетями что то не допонимаю, хотя если ip адреса серверов на которые мы цепляемся начинаются 192.168.0.2 и 192.168.1.1 то и маршруты я указываю на всю подсеть
-
Так в сети еще и другой компьютер управляет сетью… Тогда настройки шлюзов для клиентов делать нужно на нем. А pfsense только для прокси. Ну или переносить все управление на pfsense. Клиенты должны получать всю нужную настройку от DHCP сервера - и шлюзы, и WINS. В общем, чтобы маршруты могли появиться у клиентов в автоматическом режиме. Так же программы могут не работать в виду отсутствия маршрута до какого-либо определенного сервера. Можно попробовать отследить куда они пытаются обратиться, и выяснить есть ли до него связь.
Адрес сетевой карты для связи с КШ можно выбрать, например, 192.168.50.254 (если у ростелекомовской железки не такой же IP).
Адрес WAN остается DHCP клиентом, т.е. 192.168.50.6
В статических маршрутах добавить следующие маршруты:
192.168.0.0/24, шлюз 192.168.50.1
192.168.1.0/24, шлюз 192.168.50.1Если есть эти два маршрута, то маршрут 192.168.0.0/16 не нужен, если нет других важных подсетей.
Так же, программы, возможно обращаются по адресу шлюза, тогда можно добавить маршрут вида:
192.168.50.1, шлюз - адрес сетевой карточки (хотя это излишне, и должно работать и так, проверить можно пингом).Ну и не забывать про правила файрвола, где должно быть разрешено ходить из локальной сети до шлюза.
Советую так же DHCP поднять на pfsense, а WINS можно оставить на контролере домена (прописав WINS сервер в настройках DHCP pfsense). Если не принципиально, то сделать подсеть отличную от подсети КШ.
-
Как вариант можно поробовать способ описанный в статье https://knasys.ru/%d0%bf%d0%be%d0%b4%d0%bd%d1%8f%d1%82%d0%b8%d0%b5-%d0%ba%d1%80%d0%b8%d0%bf%d1%82%d0%be%d1%88%d0%bb%d1%8e%d0%b7%d0%b0-%d0%bd%d0%b0-%d0%b1%d0%b0%d0%b7%d0%b5-%d0%ba%d0%be%d0%bd%d1%82%d0%b8%d0%bd%d0%b5/
-
Так в сети еще и другой компьютер управляет сетью… Тогда настройки шлюзов для клиентов делать нужно на нем. А pfsense только для прокси. Ну или переносить все управление на pfsense. Клиенты должны получать всю нужную настройку от DHCP сервера - и шлюзы, и WINS. В общем, чтобы маршруты могли появиться у клиентов в автоматическом режиме. Так же программы могут не работать в виду отсутствия маршрута до какого-либо определенного сервера. Можно попробовать отследить куда они пытаются обратиться, и выяснить есть ли до него связь.
Адрес сетевой карты для связи с КШ можно выбрать, например, 192.168.50.254 (если у ростелекомовской железки не такой же IP).
Адрес WAN остается DHCP клиентом, т.е. 192.168.50.6
В статических маршрутах добавить следующие маршруты:
192.168.0.0/24, шлюз 192.168.50.1
192.168.1.0/24, шлюз 192.168.50.1Если есть эти два маршрута, то маршрут 192.168.0.0/16 не нужен, если нет других важных подсетей.
Так же, программы, возможно обращаются по адресу шлюза, тогда можно добавить маршрут вида:
192.168.50.1, шлюз - адрес сетевой карточки (хотя это излишне, и должно работать и так, проверить можно пингом).Ну и не забывать про правила файрвола, где должно быть разрешено ходить из локальной сети до шлюза.
Советую так же DHCP поднять на pfsense, а WINS можно оставить на контролере домена (прописав WINS сервер в настройках DHCP pfsense). Если не принципиально, то сделать подсеть отличную от подсети КШ.
понятно что клиенты от DHCP сервера должны получать настройки, но если бы у меня все правильно было настроено на pf то по сути я бы просто в настройка DHCP сервера в маршрутизаторе поменял бы IP КШ на IP pf, и при перезагрузке ПК всем бы уже присваивались адреса со шлюзом pf
какие там еще настройки шлюзов, думаю только это ка на скрине больше настроек шлюзов там нет.
отследить обращение имеется ввиду командой tracert ?
адрес сетевой карты для подключения КШ я не могу выбрать из этой сети 50.xx
WAN адрес у меня PPPoE подключение статический IP адрес
а LAN 192.168.50.6 прописанный жестко на pf -
трейсы с клиента со шлюзом pf к удаленному серверу с IP 192.168.1.7
и трейсы обратно с удаленной подсети на моего клиента 192.168.50.156 со шлюзом pf
как выяснилось все нормально, но программы все же отказываются работать, остается убица об стену :'( -
А что говорит tcpdump -i интерфейс_lan на pfsense во время запуска тех программ? Куда они пытаются обратиться?
-
Угу, вижу, клиент …156 пробует достучаться на эти сервера:
192.168.1.7
192.168.1.124
192.168.0.3
192.168.0.4Они все доступны? И они видят самого клиента? Так же, нужно исключить эти подсети от обработки проксей, чтобы сертификат не подменивался
-
Угу, вижу, клиент …156 пробует достучаться на эти сервера:
192.168.1.7
192.168.1.124
192.168.0.3
192.168.0.4Они все доступны? И они видят самого клиента? Так же, нужно исключить эти подсети от обработки проксей, чтобы сертификат не подменивался
доступны в плане? пинги на них идут и обратно, трейсы проходят, порты открыты, и обратно, что исключить от обработки проксей? в настройках сквида прописать эти подсети в
Bypass Proxy for These Source IPs или Bypass Proxy for These Destination IPs или я не про то думаю? и еще мне наверное нужно на каждый IP сервера настраивать маршрут так как 192.168.1.124 это обычный клиент в их сети, он у меня к нему стучится. -
А что говорит tcpdump -i интерфейс_lan на pfsense во время запуска тех программ? Куда они пытаются обратиться?
12:50:00.150872 IP 192.168.50.156.49483 > 192.168.0.3.https: Flags [P.], seq 5282:5895, ack 2513, win 513, length 613
12:50:00.150879 IP 192.168.50.156.49483 > 192.168.0.3.https: Flags [P.], seq 5282:5895, ack 2513, win 513, length 613
12:50:00.150956 IP 192.168.50.156.49483 > 192.168.0.3.https: Flags [P.], seq 5895:6716, ack 2513, win 513, length 821
12:50:00.150963 IP 192.168.50.156.49483 > 192.168.0.3.https: Flags [P.], seq 5895:6716, ack 2513, win 513, length 821
12:50:00.151647 IP 192.168.50.156.49481 > 192.168.0.3.https: Flags [P.], seq 189:403, ack 2647, win 512, length 214
12:50:00.151653 IP 192.168.50.156.49481 > 192.168.0.3.https: Flags [P.], seq 189:403, ack 2647, win 512, length 214
12:50:00.161613 IP 192.168.50.156.49462 > pfSense.localdomain.3128: Flags [P.], seq 5070:5124, ack 24369, win 1024, length 54
12:50:00.161621 IP pfSense.localdomain.3128 > 192.168.50.156.49462: Flags [.], ack 5124, win 501, length 0
12:50:00.164740 IP 192.168.50.156.49481 > 192.168.0.3.https: Flags [P.], seq 403:664, ack 2754, win 511, length 261
12:50:00.164762 IP 192.168.50.156.49481 > 192.168.0.3.https: Flags [P.], seq 403:664, ack 2754, win 511, length 261
12:50:00.177165 IP 192.168.50.156.49481 > 192.168.0.3.https: Flags [.], seq 664:2072, ack 3143, win 517, length 1408
12:50:00.177191 IP 192.168.50.156.49481 > 192.168.0.3.https: Flags [.], seq 664:2072, ack 3143, win 517, length 1408
12:50:00.177269 IP 192.168.50.156.49481 > 192.168.0.3.https: Flags [P.], seq 2072:3389, ack 3143, win 517, length 1317
12:50:00.177276 IP 192.168.50.156.49481 > 192.168.0.3.https: Flags [P.], seq 2072:3389, ack 3143, win 517, length 1317
12:50:00.177386 IP 192.168.50.156.49481 > 192.168.0.3.https: Flags [.], seq 3389:4797, ack 3143, win 517, length 1408
12:50:00.177391 IP 192.168.50.156.49481 > 192.168.0.3.https: Flags [.], seq 3389:4797, ack 3143, win 517, length 1408
12:50:00.177394 IP 192.168.50.156.49481 > 192.168.0.3.https: Flags [P.], seq 4797:4802, ack 3143, win 517, length 5
12:50:00.177398 IP 192.168.50.156.49481 > 192.168.0.3.https: Flags [P.], seq 4797:4802, ack 3143, win 517, length 5
12:50:00.180000 IP 192.168.50.156.49483 > 192.168.0.3.https: Flags [.], ack 4619, win 517, length 0
12:50:00.180016 IP 192.168.50.156.49483 > 192.168.0.3.https: Flags [.], ack 4619, win 517, length 0
12:50:00.188426 IP 192.168.50.156.49483 > 192.168.0.3.https: Flags [.], ack 4704, win 516, length 0
12:50:00.188452 IP 192.168.50.156.49483 > 192.168.0.3.https: Flags [.], ack 4704, win 516, length 0
12:50:00.195514 ARP, Request who-has 192.168.50.18 tell 192.168.50.152, length 46
12:50:00.212102 IP 192.168.50.156.49481 > 192.168.0.3.https: Flags [.], ack 5846, win 517, length 0
12:50:00.212119 IP 192.168.50.156.49481 > 192.168.0.3.https: Flags [.], ack 5846, win 517, length 0
12:50:00.232219 IP pfSense.localdomain.3128 > 192.168.50.109.49493: Flags [P.], seq 940558:941980, ack 0, win 513, length 1422
12:50:00.236213 IP 192.168.50.156.49471 > 192.168.1.7.8443: Flags [P.], seq 15245:15282, ack 11493, win 64129, length 37
12:50:00.236241 IP 192.168.50.156.49471 > 192.168.1.7.8443: Flags [P.], seq 15245:15282, ack 11493, win 64129, length 37 -
в настройках сквида прописать эти подсети в Bypass Proxy for These Source IPs или Bypass Proxy for These Destination IPs или я не про то думаю?
Да. Думаю, может быть дело в подмене сертификата. Для проверки этой версии прокси можно попробовать вообще отключить.
-
в настройках сквида прописать эти подсети в Bypass Proxy for These Source IPs или Bypass Proxy for These Destination IPs или я не про то думаю?
Да. Думаю, может быть дело в подмене сертификата. Для проверки этой версии прокси можно попробовать вообще отключить.
прописал подсети, безрезультатно :'(
как вариант могу еще полностью отключить прокси, но позже.
а а какой подмене сертификата идет речь? -
в настройках сквида прописать эти подсети в Bypass Proxy for These Source IPs или Bypass Proxy for These Destination IPs или я не про то думаю?
Да. Думаю, может быть дело в подмене сертификата. Для проверки этой версии прокси можно попробовать вообще отключить.
прописал подсети, безрезультатно :'(
как вариант могу еще полностью отключить прокси, но позже.
а а какой подмене сертификата идет речь?к сожалению и полное отключение прокси не помогло, что характерно к примеру почтовый клиент цепляется к серверу, разрывается соединение, опять цепляется, т.е как бы его не совсем нет, а с разрывами, так же и с другими программами например через Citrix к 1C цепляешься, вроде бы подключается все норм, потом подключение разорвано, т.е не пишет что его совсем нет, так же с другим ПО подключение прервано.
-
Подмена сертификата - прокси использует свой КЦ, которым подписывает сертификаты удаленных узлов. Для программ скорей всего критично то, что сертификат используется подмененный (ну, по факту подписан "левым" КЦ).
По поводу проблемы - к сожалению, больше моих идей нет, не знаю что еще посоветовать кроме как попробовать перезагрузить шлюз. Ну, попробовать посмотреть настройки самого ПО, которое не может соединиться да глянуть инфраструктуру сети за КШ, может там что найдется, что мешает корректной работе.
-
Подмена сертификата - прокси использует свой КЦ, которым подписывает сертификаты удаленных узлов. Для программ скорей всего критично то, что сертификат используется подмененный (ну, по факту подписан "левым" КЦ).
По поводу проблемы - к сожалению, больше моих идей нет, не знаю что еще посоветовать кроме как попробовать перезагрузить шлюз. Ну, попробовать посмотреть настройки самого ПО, которое не может соединиться да глянуть инфраструктуру сети за КШ, может там что найдется, что мешает корректной работе.
понятно, спасибо!
-
подскажите где в релизе 2.3.2 поставить галочку Bypass firewall rules for traffic on the same interface, найти не могу, по идее она в предыдущих релизах должна была быть тут
System -> Advanced -> Firewall and NAT