OpenVPN TAP

rubic

Там, вроде как, отличий нет особых, кроме того, что Tunnel Network указывать не обязательно. Ну и этот ваш L2 трафик должен же куда-то литься. Поэтому делают Bridge между OpenVPN интерфейсом и LAN.

A Former User

То есть получается мне надо поставить на обоих маршрутизаторах тип TAP и забриджевать интерфейсы, поставив галочку на Brige DHCP незабыть
Еще вопрос, если в головном офисе VPN и INTERNET идут одним оптическим кабелем и в нем разными виланами, разбитые тегами на WAN порту (2 интерфейса сделаны), никаких подводных камней не будет?

A Former User

Решил попробовать замутить связку PFSense сервер OVPN в режиме TAP а за клиента решил взять Mikrotik, кто такое настраивал?

pigbrother

@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/

A Former User

Спасибо, почитаю.
А конфиг можно глянуть, как у Вас в филиалах настроены микротики и сенс под них

werter

Доброе
Может ipsec попробовать ?
https://forum.pfsense.org/index.php?topic=106103 + на youtube -> pfsense mikrotik ipsec

pigbrother

@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 - произвольные, без них Микоротик не даст сохранить конфигурацию.

unijohnson

@rubic:

Там, вроде как, отличий нет особых, кроме того, что 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). То что находится в сети сервера не доступно.
Что еще нужно?

werter

Доброе
Правило fw на LAN ?

unijohnson

@werter:

Доброе
Правило 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

rules1.jpg_thumb

werter

На ЛАН не хватает в самом верху явного правила для доступа в удален. сеть.

unijohnson

@werter:

На ЛАН не хватает в самом верху явного правила для доступа в удален. сеть.

Тут две строчки:
Первая создаётся автоматически 22, 80 - для доступа к управлению через web и ssh
Вторая строчка открывает на этом интерфейсе всё что можно по протоколу ipV4 я так понимаю..
А как тогда доступ в удалённую сеть разрешить ?
Ведь на pfSense клиента точно так же правило прописано.
Помогите, ведь решение где то близко!

werter

Просто создайте явное правило , где в dest будет удален. сеть. Поставьте это правило в самом верху.

pigbrother

@werter:

Просто создайте явное правило , где в dest будет удален. сеть. Поставьте это правило в самом верху.

Просто для справки.
Недавно добавлял новый OVPN сервер site-to-site.
Заработало без добавления разрешающего правила на LAN pfSense в удаленную сеть за клиентом.
Похоже, negate rules, о которых в свое время писал ув. rubic, опять\пока в 2.3.2_1 могут работать без создания таких правил.

unijohnson

@werter:

Просто создайте явное правило , где в dest будет удален. сеть. Поставьте это правило в самом верху.

Извините, настраиваю tap первый раз и не совсем понимаю принцип прохождения трафика. Маршрутизировать трафик здесь не надо, как я понимаю, только направлять (открывать прохождение).
dest удалённая сеть - что здесь указать. Перепробовал все возможные варианты, которые указывают на удалённую сеть.
Итак, Если удалённая сеть клиента 192.168.1.Х, то этот трафик можно пропустить только через LAN интерфейс имеющий адрес той же подсети? В сети сервера, такая же подсеть 192.168.1.Х. Как разрулить пакеты которые, в удалённую сеть, а которые в локальную. Перебрал все варианты - трафик не идёт. Попробовал другой LAN интерфейс (с адресом 192.168.35.1) забриджевать с tap туннелем. но там подсеть другая 192.168.35.Х и явно пакеты из 1.Х сети не пойдут. Сделать мост на между этими интерфейсами (как на клиентской железке) невозможно - возникает кольцо. т к. один физ. интерфейс на виртуальной машине. Если не получиться придётся пробовать смоделировать сервер не на виртуальной машине, а на какой нибудь железяке, как клиентская часть.
Для чего всё это? Хочу объединить без маршрутизации две, три, четрыре локальные сети, имеющие одинаковые подсети.

werter

имеющие одинаковые подсети

Т.е. у вас одинаковая адресация в сетях ?

unijohnson

@werter:

имеющие одинаковые подсети

Т.е. у вас одинаковая адресация в сетях ?

Да. Это реально или я ошибаюсь? Вот например статья http://citforum.ru/nets/articles/tap_bridge/
Например для одной удалённой сети выделить 192.168.1.210 - 219, для другой 192.168.1.220 - 229 и т.п.

werter

Например для одной удалённой сети выделить 192.168.1.210 - 219, для другой 192.168.1.220 - 229 и т.п.

В таком случае - да, возможно.

unijohnson

Сначала собрал схему на столе - заработало. Потом объединил сети через TAP туннель и очень мне этот вариант понравился. Только пришлось пока сервер поднять на отдельной железке, а не на виртуальной машине.
Возникли выводы и вопросы, и если я ошибаюсь, поправьте:
1. На виртуальной машине не заработало (не видна сеть дальше виртуальной машины), возможно, потому что физически WAN и LAN интерфейсы виртуальной машины в одной сети. Значит их надо либо физически разделить, либо использовать VLAN?
2. Будет ли работать система tap сервер - два TAP клиента? Будут ли пользователи из клиентских сетей видеть друг друга?

unijohnson

pfsense на виртуальной машине. tap туннель поднят. Как объединить сети, если у физ. компьютера, на котором pfsense, всего один физический интерфейс? Или решения нет. Сообщение чуть выше так же актуально (никто не ответил) Спасибо.