Маршрутизация OVPN
-
зачем?
в опенвпн надо прописать маршруты, при настройке local\remote network прописывали?
буквально недавно пробегала тема в русской ветке
з.ы. сразу не замети - с учетом того что у вас оба девайса имеют локальную сеть одинаковую -192.168.10.100 и 192.168.10.101 - то в принципе есть вариант настройки туннеля что бы девайсы видели друг друга, но для этого:
надо что бы пфсенсы имели сетевую в локальной сети (192.168.10.х) и надо четко понимать чем грозит такое обеднение.
т.е. если вы не админ обоих сетей - лучше не рисковать :) -
зачем?
в опенвпн надо прописать маршруты, при настройке local\remote network прописывали?
буквально недавно пробегала тема в русской ветке
з.ы. сразу не замети - с учетом того что у вас оба девайса имеют локальную сеть одинаковую -192.168.10.100 и 192.168.10.101 - то в принципе есть вариант настройки туннеля что бы девайсы видели друг друга, но для этого:
надо что бы пфсенсы имели сетевую в локальной сети (192.168.10.х) и надо четко понимать чем грозит такое обеднение.
т.е. если вы не админ обоих сетей - лучше не рисковать :)ну так не вопрос дописать еще один IP на eth-lan можно```
ifconfig de0 inet 192.168.10.1 netmask 255.255.255.0 alias (где de0 интерфейст LAN)а в local\remote network прописаны внутренние сети 192.168.xxx.xxx . или можно через кустомы в настройках OVPN еще добавить сети ? > с учетом того что у вас оба девайса имеют локальную сеть одинаковую -192.168.10.100 и 192.168.10.101 - то в принципе есть вариант настройки туннеля что бы девайсы видели друг друга можно по подробнее про случай > т.е. если вы не админ обоих сетей - лучше не рисковать :) хм, а чем грозит как кроме безопасности? . если только этим то меня устроит , так как в дальнейших планах брать у провайдера прямую нитку на оптике между 2мя точками. и уже тогда всё разруливать в одной подсети . на данный момент пока что не могу бриджевать OVPN c LAN . в обоих сетях на PF DHCP-server. и боюсь каши. между ними -
читать разницу между tap\tun
по бриджеванию - http://doc.pfsense.org/index.php/OpenVPN_Bridging
не должно быть пересечений ипов, так как при tap и бриджевании - у вас будет как бы физический кабель между локальными интерфейсами пфсенсов. -
читать разницу между tap\tun
по бриджеванию - http://doc.pfsense.org/index.php/OpenVPN_Bridging
не должно быть пересечений ипов, так как при tap и бриджевании - у вас будет как бы физический кабель между локальными интерфейсами пфсенсов.да я в курсе .. я так и хочу длать . но только когда провайдер предоставит прямую нитку между 2-мя точками . на данный момент точки между собой пока связаны только по OVPN в режиме tun
-
По сколько физических интерфейсов на pfSense ? По три ?
-
-
По сколько физических интерфейсов на pfSense ? По три ?
физических LAN u WAN
Я бы предложил более правильную с точки зрения топологии схему
[CISCO]<–>[WAN PFSense1 LAN]<–>LAN subnet
[OPT1-1] <–openvpn--> [OPT2-1][SIEMENS]<–>[WAN PFSense2 LAN]<–>LAN subnet
- PFSense включаются между основным маршрутизатором и локалкой
- LAN и WAN интерфейсы бриждуются
- Между собой PFSense соединены по 3-им OPT1 интерфейсам
- Трафик LAN - WAN разрешен любой, но перед этим стоят правила PoliceRouting для заворачивания локального трафика для удаленной подсети на OPT(OPENVPN) интерфейс.
-
- PFSense включаются между основным маршрутизатором и локалкой
да как бы PF и являются основными роутаками в 2х разных филиалах
-
- PFSense включаются между основным маршрутизатором и локалкой
да как бы PF и являются основными роутаками в 2х разных филиалах
Тогда схема не очень понятно нарисована, по крайней мере мне. Где локалка, где инет, как трафик должен ходить..
-
про бридж опенвпн, может автору поможет :) http://xgu.ru/wiki/OpenVPN_Bridge
-
про бридж опенвпн, может автору поможет :) http://xgu.ru/wiki/OpenVPN_Bridge
ну я же написал что БРИДЖ на данном этапе мне не подходит. на данный момент это 2 сети в которых стоят DHCP server-PF. соответственно если их бриджануть то начнется кашa. DHCP-relay не подходи. по тому что если связь оборвется между офисами DHCP соответственно встанет.
накидал более подробную картину .. может так будет понятнее?
собственно задача в том что бы CISCO B SIEMENS смогли видеть друг друга
-
у дхцп можно разделить диапазонами, привязать статику под маки и тд..
в вашем случае - уже написал - только нат, поять таки надо убирать автоматическое правило ната и делать нат правила на пфсенсе2 вручную -
у дхцп можно разделить диапазонами, привязать статику под маки и тд..
предоставленными средствами управление DHCP я не смогу указать определнным MAC адресам разные ШЛЮЗЫ.
-
То есть у Вас за Сиеменсом и Циско одинаковые подсети ЛАН ?
Не думаю, что получится сделать такую маршрутизацию простыми средствами (кроме объединения сетей бриджем).
Нужно в одной из сетей сменить диапазон, чтобы не перекрывался. -
Нужно в одной из сетей сменить диапазон, чтобы не перекрывался.
ну даже если я сменю и укажу общий диапазон и сделаю БРИДЖ . как я буду указывать что клиентам из сети 1 получать шлюз ПФ1 а в сети 2 шлюз ПФ2 ?
-
То есть у Вас за Сиеменсом и Циско одинаковые подсети ЛАН ?
Не думаю, что получится сделать такую маршрутизацию простыми средствами (кроме объединения сетей бриджем).
Нужно в одной из сетей сменить диапазон, чтобы не перекрывался.даже в таком случае - у него у сименса другой шлюз, не пфсенс, и пропсать маршрут на сименсе он не может…
-
-
А что за железки сименс и циско? Зачем они нужны ДО PFSEnse ?
сименс это мед оборудование , циска тоже не простая . со своей прошивкой специальной . для диагностики аппарата. всё это за тем что бы из центра сименс могли подключиться к циске и могли диагностировать сименс
циска стоит в одном офисе а сименс в другом . единственное что связывает филиалы это OVPN