OpenVPN TAP
-
На ЛАН не хватает в самом верху явного правила для доступа в удален. сеть.
-
На ЛАН не хватает в самом верху явного правила для доступа в удален. сеть.
Тут две строчки:
Первая создаётся автоматически 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 клиента? Будут ли пользователи из клиентских сетей видеть друг друга? -
pfsense на виртуальной машине. tap туннель поднят. Как объединить сети, если у физ. компьютера, на котором pfsense, всего один физический интерфейс? Или решения нет. Сообщение чуть выше так же актуально (никто не ответил) Спасибо.
-
Доброе.
pfsense на виртуальной машине. tap туннель поднят. Как объединить сети, если у физ. компьютера, на котором pfsense, всего один физический интерфейс?
Стоп. Пф на той же машине или пф на др машине в виде вирт. ?
Если на той же :
1. Что в кач-ве гипервизора ?
2. У гипервизоров есть неск. типов сетей, к-ый они отдают вирт. маш. В Виртбоксе (гипервизор 2-го типа) - это сет. мост, NAT, внутр. сеть и др. Комбинируя эти сети на вирт. машине можно добиться необходимого вам.
