OpenVPN TAP
-
Здравствуйте.
Хотел бы задать вопрос по поводу общей настройки данной конфигурации между двумя офисами.
Сейчас функционирует TUN, но так как нужно объединить в один лес по доменом 2 филиала, нужен вариант с TAP.
Если у кого был опыт, посоветуйте где почитать? -
Там, вроде как, отличий нет особых, кроме того, что Tunnel Network указывать не обязательно. Ну и этот ваш L2 трафик должен же куда-то литься. Поэтому делают Bridge между OpenVPN интерфейсом и LAN.
-
То есть получается мне надо поставить на обоих маршрутизаторах тип TAP и забриджевать интерфейсы, поставив галочку на Brige DHCP незабыть
Еще вопрос, если в головном офисе VPN и INTERNET идут одним оптическим кабелем и в нем разными виланами, разбитые тегами на WAN порту (2 интерфейса сделаны), никаких подводных камней не будет? -
Решил попробовать замутить связку PFSense сервер OVPN в режиме TAP а за клиента решил взять Mikrotik, кто такое настраивал?
-
@Bansardo:
Решил попробовать замутить связку PFSense сервер OVPN в режиме TAP а за клиента решил взять Mikrotik, кто такое настраивал?
1. В Микротик RouterOS отсутствуют для OVPN:
поддержка UDP
поддержка LZO компрессии
поддержка TLS authentication
2. Если планируется массивный трафик - CPU Микротик будет почти всегда сильно загружен.
При этом сам использую Микротик в филиалах, правда в режиме tun. Основной трафик невелик, поэтому описанные моменты не напрягают.Обычный контроллер домена с синхронизацией через WAN может оказаться не самой лучшей идеей, присмотритесь к тому, что называется Read-Only Domain Controllers
Навскидку:
https://technet.microsoft.com/en-us/library/cc732801(v=ws.10).aspx
http://winitpro.ru/index.php/2010/11/21/rabota-s-kontrollerami-domena-read-only-rodc-chast-1/ -
Спасибо, почитаю.
А конфиг можно глянуть, как у Вас в филиалах настроены микротики и сенс под них -
Доброе
Может ipsec попробовать ?
https://forum.pfsense.org/index.php?topic=106103 + на youtube -> pfsense mikrotik ipsec -
@Bansardo:
Спасибо, почитаю.
А конфиг можно глянуть, как у Вас в филиалах настроены микротики и сенс под нихКонфиг сервера
dev ovpns4 verb 1 dev-type tun tun-ipv6 dev-node /dev/tun4 writepid /var/run/openvpn_server4.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto tcp-server cipher AES-256-CBC auth SHA1 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local a.b.c.d tls-server server 10.11.12.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc/server4 ifconfig 10.11.12.1 10.11.12.2 tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'ovpns2' 1" lport 1xxx management /var/etc/openvpn/server4.sock unix push "route a.a.2.0 255.255.255.0" ca /var/etc/openvpn/server4.ca cert /var/etc/openvpn/server4.cert key /var/etc/openvpn/server4.key dh /etc/dh-parameters.1024 persist-remote-ip float topology net30 route a.a.5.0 255.255.255.0 route a.a.4.0 255.255.255.0 route a.0.3.0 255.255.255.0
route a.a.5.0 255.255.255.0
route a.a.4.0 255.255.255.0
route a.a.3.0 255.255.255.0
Это - маршруты в другие филиалыКонфиг Микротика
Предварительно нужно импортировать в Микоротик сертификат и приватный ключ./interface ovpn-client add certificate=xxx-cert cipher=aes256 comment="BranchOVPN " connect-to=\ a.b.c.d mac-address=00:00:00:00:00:11 name=ovpn-out1 password=pass \ port=1xxx user=user
user и password - произвольные, без них Микоротик не даст сохранить конфигурацию.
-
Там, вроде как, отличий нет особых, кроме того, что Tunnel Network указывать не обязательно. Ну и этот ваш L2 трафик должен же куда-то литься. Поэтому делают Bridge между OpenVPN интерфейсом и LAN.
Подскажите, что еще не настроено:
OpenVpn tap поднят
Бридж на Lan сделал на клиенте и сервере
Rules полностью открыл
Сеть 192.168.1.X
Клиент pfsense работает на выделенной железке rBOX120, а Сервер pfsense на виртуальной машине WMWare
с сервера через Diagnostics - ping Все адреса в сети клиента пингуются.
С клиента пингуется только адрес шлюза (LAN интерфейс 192.168.1.1). То что находится в сети сервера не доступно.
Что еще нужно? -
Доброе
Правило fw на LAN ? -
Доброе
Правило fw на LAN ?На интерфейсе сети 192.168.1.Х - Firewall - Rules - LAN_1:
-
-
- LAN_1 Address 80 22 * * Anti-Lockout Rule
IPv4 * * * * * * none
И на всех других интерфейсах, кроме WAN так же. Никак пакеты не проходят. :-[
[img]https://forum.pfsense.org/index.php?action=dlattach;topic=114692.0;attach=93542;image
- LAN_1 Address 80 22 * * Anti-Lockout Rule
-
-
-
На ЛАН не хватает в самом верху явного правила для доступа в удален. сеть.
-
На ЛАН не хватает в самом верху явного правила для доступа в удален. сеть.
Тут две строчки:
Первая создаётся автоматически 22, 80 - для доступа к управлению через web и ssh
Вторая строчка открывает на этом интерфейсе всё что можно по протоколу ipV4 я так понимаю..
А как тогда доступ в удалённую сеть разрешить ?
Ведь на pfSense клиента точно так же правило прописано.
Помогите, ведь решение где то близко! -
Просто создайте явное правило , где в dest будет удален. сеть. Поставьте это правило в самом верху.
-
Просто создайте явное правило , где в dest будет удален. сеть. Поставьте это правило в самом верху.
Просто для справки.
Недавно добавлял новый OVPN сервер site-to-site.
Заработало без добавления разрешающего правила на LAN pfSense в удаленную сеть за клиентом.
Похоже, negate rules, о которых в свое время писал ув. rubic, опять\пока в 2.3.2_1 могут работать без создания таких правил. -
Просто создайте явное правило , где в dest будет удален. сеть. Поставьте это правило в самом верху.
Извините, настраиваю tap первый раз и не совсем понимаю принцип прохождения трафика. Маршрутизировать трафик здесь не надо, как я понимаю, только направлять (открывать прохождение).
dest удалённая сеть - что здесь указать. Перепробовал все возможные варианты, которые указывают на удалённую сеть.
Итак, Если удалённая сеть клиента 192.168.1.Х, то этот трафик можно пропустить только через LAN интерфейс имеющий адрес той же подсети? В сети сервера, такая же подсеть 192.168.1.Х. Как разрулить пакеты которые, в удалённую сеть, а которые в локальную. Перебрал все варианты - трафик не идёт. Попробовал другой LAN интерфейс (с адресом 192.168.35.1) забриджевать с tap туннелем. но там подсеть другая 192.168.35.Х и явно пакеты из 1.Х сети не пойдут. Сделать мост на между этими интерфейсами (как на клиентской железке) невозможно - возникает кольцо. т к. один физ. интерфейс на виртуальной машине. Если не получиться придётся пробовать смоделировать сервер не на виртуальной машине, а на какой нибудь железяке, как клиентская часть.
Для чего всё это? Хочу объединить без маршрутизации две, три, четрыре локальные сети, имеющие одинаковые подсети. -
имеющие одинаковые подсети
Т.е. у вас одинаковая адресация в сетях ?
-
имеющие одинаковые подсети
Т.е. у вас одинаковая адресация в сетях ?
Да. Это реально или я ошибаюсь? Вот например статья http://citforum.ru/nets/articles/tap_bridge/
Например для одной удалённой сети выделить 192.168.1.210 - 219, для другой 192.168.1.220 - 229 и т.п. -
Например для одной удалённой сети выделить 192.168.1.210 - 219, для другой 192.168.1.220 - 229 и т.п.
В таком случае - да, возможно.
-
Сначала собрал схему на столе - заработало. Потом объединил сети через TAP туннель и очень мне этот вариант понравился. Только пришлось пока сервер поднять на отдельной железке, а не на виртуальной машине.
Возникли выводы и вопросы, и если я ошибаюсь, поправьте:
1. На виртуальной машине не заработало (не видна сеть дальше виртуальной машины), возможно, потому что физически WAN и LAN интерфейсы виртуальной машины в одной сети. Значит их надо либо физически разделить, либо использовать VLAN?
2. Будет ли работать система tap сервер - два TAP клиента? Будут ли пользователи из клиентских сетей видеть друг друга?