автоподнятие шлюза c помощью openvpn

tap0 можно засунуть в бридж до поднятия VPN своим скриптом в INIT =)

так tap0 создаётся опенвпном, как ты себе это представляешь? а раз так, если реализовывать инит-скриптом, при рестарте опенвпна опять tap0 подымать. так что не кошерно инит-скрипты писать для этого

так tap0 создаётся опенвпном, как ты себе это представляешь?

ты ничего не путаешь? в сюсе изначально tap или tun устройство создаешь в сетевой конфигурации YaST потом создаешь мост. а потом уже впн поднимаешь и он ловит этот tapX. Показать в живую?

воу, а это интересно. не видел нигде такого трюка. не знал, что его можно создать заранее. отосплюсь - потыкаю, спасибо

незачто =) ежели не осилишь, стучись на почту. есть в профиле.

что-то ты больно добрый и отзывчивый. неспроста это

а ты слишком подозрительный. =)

tap0 создаётся опенвпном

Не угадал. Создаётся, если его ещё нет. Если он существует - openvpn к нему присоединяется. Так что никакие скрипты после поднятия VPN не нужны. Нужно так:

/etc/network/interfaces:

iface tap0 inet manual
up openvpn --mktun --dev tap0
down openvpn --rmtun --dev tap0

iface br0 inet static
bridge_ports eth0 tap0
address ...

/etc/openvpn/vpn.conf:

dev tap0
...

Если openvpn работает не из-под root, возможно, придётся при создании интерейсов указать --user=<openpnv_user>. Хотя по-моему, если он биндится до сброса привилегий, и так заработает.

up openvpn --mktun --dev tap0

down openvpn --rmtun --dev tap0

а это зачем, если девайс системой создаётся?

man interfaces

The manual Method
       This  method may be used to define interfaces for which no configuration is done by default. Such interfaces can be configured manually by means of
       up and down commands or /etc/network/if-*.d scripts.

у меня не ап и даун вызвали вопросы, а команда за ними. из мана опенвпн не смог понять смысл этой конструкции

Если машинка является шлюзом, то создовать мост для пересылки пакетов между tap0 <-> eth1 , как то не по феншую.

Есть такая штука, которая наверняка уже включена как ip_forward

man openvpn

--mktun Create  a persistent tunnel on platforms which support them such as Linux.  Normally TUN/TAP tunnels exist only for the period of time that an application has them open.  This option takes advantage of the TUN/TAP driver's ability to  build  persistent  tunnels  that live through multiple instantiations of OpenVPN and die only when they are deleted or the machine is rebooted.

Почему нет? Если, например, мы хотим вывести пользователей vpn с локальную сеть на уровне L2, чтобы они жили в той же подсети, с теми же DHCP/TFTP и чтобы мультикаст работал из коробки? Я так однажды делал

Почему нет?

Потому что он не нужен, для того чтобы и так все работало.

Если, например, мы хотим вывести пользователей vpn с локальную сеть на уровне L2, чтобы они жили в той же подсети, с теми же DHCP/TFTP и чтобы мультикаст работал из коробки?

Для того, что бы работало все что сказано выше не нужен мост.

Я так однажды делал

Спору нет, что оно работать будет. Использования моста накладывает ограничение на обработку трафика, который будет ходит через tap0 , что не всегда удобно, когда клиентов много.

Поэтому вопрос топикстару заключался именно в том, почему был выбран мост для реализации затеи.

Для того, что бы работало все что сказано выше не нужен мост

Ну-ка, как без бриджа сделать L2 VPN, объединённый с локальной сетью? Я прям заинтересовался

ограничение на обработку трафика, который будет ходит через tap0

Во-первых, если я хочу удалённых и локальных клиентов в одну физическую сеть сбить, значит мне его отдельно обрабатывать не надо, иначе сделал бы L3.
Во-вторых, ebtables.
В-третьих, при включенном я ядре CONFIG_BRIDGE_NETFILTER и заданных sysctl net.bridge.bridge-nf-call-arptables net.bridge.bridge-nf-call-ip6tables net.bridge.bridge-nf-call-iptables и iptables-ом отфильтровать можно. Точнее сказать, ты *внезапно* с большим удивлением обнаруживаешь, что он их всё-таки фильтрует :)

А что, tap0 создаваемый openvpn'ом какой-то особенный?

Ну-ка, как без бриджа сделать L2 VPN, объединённый с локальной сетью? Я прям заинтересовался

Никак

чтобы они жили в той же подсети, с теми же DHCP/TFTP и чтобы мультикаст работал из коробки?

Для этого ненужен мост. Если же речь идет о L2 мультикасте, то я умываю руки.

В-третьих, при включенном я ядре CONFIG_BRIDGE_NETFILTER и заданных sysctl net.bridge.bridge-nf-call-arptables net.bridge.bridge-nf-call-ip6tables net.bridge.bridge-nf-call-iptables и iptables-ом отфильтровать можно. Точнее сказать, ты *внезапно* с большим удивлением обнаруживаешь, что он их всё-таки фильтрует :)

Открыл доку почитал, да можно.

Но все же считаю должна быть специфическая задача, что бы для ее решения использовать мост, когда можно обойтись без него.

некорректно расписал. шлюзом машина будет только для впн-клиентов и в локальную сеть

Для этого ненужен мост. Если же речь идет о L2 мультикасте, то я умываю руки.

Бывает специфичное железо, которому L2 нужен, правда не multicast(а он L2 бывает?), а broadcast. Ну и при небольшом количестве клиентов, проще/быстрее/удобнее сделать L2, чем по отдельности морочаться с каждым куском - для DHCP сделай DHCP relay, для L3 multicast настрой IGMP и т. д.

У меня клиентами были мои же сетевые железки, стоящие в закрытых шкафах и обеспечивающие работу оборудования, от них я внезапной хакерской атаки не ждал :) А если клиенты неизвестны - тогда да, L3, злой фаерволл и собаки по периметру.

аа, то есть, строкой «iface tap0 inet manual» интефейс на самом деле не создаётся. а как делать брктлом? у меня всяко стоит

вопрос топикстару заключался именно в том, почему был выбран мост для реализации затеи

на машинах в локалке везде настроено 10.20.0.0/16. я хочу, чтобы мои опенвпн-клиенты были в той же подсети, только в маленьком куске её. как это реализовать с dev tun и маршрутизацией, я не сообразил, да долго и не искал способа. желания гонять широковещательный трафик нет, в локалке нет dhcp и очень много машин - маршрутизацию на каждой не настроишь. впн-шлюз и интернет-шлюз - разные машины. есть идеи?

tunctl-ом. brctl-ом в бридж добавлять, но этого явно делать не надо, при установленном bridge-utils достаточно опций в interfaces.

Хз, я openvpn-ом делал, оно без разницы. man tunctl

Как то так

sysctl net.ipv4.ip_forward=1

Разрешаем пересылку пакетов между интерфейсами

iptables -A FORWARD -i tap+ -j ACCEPT

Добавляем правило для пересылки пакетов в фаервол.

Маршруты клиенту может передавать сервер, если этого не сделано, то на клиенте

route add -net 10.20.0.0/16 gw 10.20.0.1 dev tap0

что-то ты видимо не понял. вопрос не в том, как сделать из машины шлюз и настроить пересылку пакетов и не в том, как маршруты передать клиенту. как сделать так, чтобы машины в локалке, уже настроенные статически в подсети 10.20.0.0/16 могли пересылать пакеты отправленные, например, на 10.20.0.0/26 через такой-то сервер, а не как обычно?

Сеть 10.20.0.0/26 входит в сетку 10.20.0.0/16 поэтому проблем с доставкой пакета до клиента за tap не будет. Клиент за tap0 пошлет пакет на сервер на котором поднят интерфейс eth1, с сетью 10.20.0.0/16 , на который уйдет пакет ( форвард включен ).

1)Я не гуру в сетях поэтому могу ошибаться, нужно проверить

2)Непонятно зачем клиентов впн выделять в отдельную сеть, если задача, как раз в том чтобы они были в одной сети и были доступны.

3)Как пакеты узнают куда идти, если они находятся в одном широковещательном домене ( http://edu.dvgups.ru/METDOC/GDTRAN/YAT/TELECOMM/PDI/METOD/PISHIKOV/Addressing... ). Подозреваю, что в случаи с впн на arp будет отвечать именно он.

Я не гуру в сетях поэтому могу ошибаться, нужно проверить

клиент за tap0 может отправить, проблема не в этом. я уже в который раз говорю, что нужен обратный процесс. чтобы машины в локалке видели опенвпн-клиента. а так как у них прописана подсеть 10.20.0.0/16 и ничего больше, они считают, что дефолтный шлюз тут ни причём. как тогда отправит машина из локалки опенвпн-клиенту пакет, без ещё одной записи в таблице маршрутизации?

так я и хочу, чтобы они были в одной подсети, просто для адресации впн-клиентов выделяются адреса из такой-то подсети

в одном широковещательном домене

а как ещё, кроме как мостом ты предлагаешь связать тап0 и локалку? если маршрутизацией, то причём тут широковещательный домен?

клиент за tap0 может отправить, проблема не в этом. я уже в который раз говорю, что нужен обратный процесс. чтобы машины в локалке видели опенвпн-клиента. а так как у них прописана подсеть 10.20.0.0/16 и ничего больше, они считают, что дефолтный шлюз тут ни причём. как тогда отправит машина из локалки опенвпн-клиенту пакет, без ещё одной записи в таблице маршрутизации?

Еще раз, отправит, как обычному локальному клиенту. Прочитай плз первый абзац по ссылке, что кидал выше.

а как ещё, кроме как мостом ты предлагаешь связать тап0 и локалку? если маршрутизацией, то причём тут широковещательный домен?

Клинт-локалка хочет послать запрос - смотрит по маске и адресу, что dst в его локалке - посылает arp на который отвечает VPN сервер - пакет передается ему.

П.С. Уже засомневался в своих рассуждениях, поднимука впн, проверю и скажу все ли так.

на который отвечает VPN сервер

вот как раз для этого и нужен мост, иначе сервер не ответит на запрос потому что интерфейс не тот. если не мост, то потребуется арп-прокси. хотя лучше, конечно, проверить

Такс поигрался с впн.

1)Снимаю шляпу был не прав, на arp ни клиент , ни сервер впн не отвечает. Самый простой способ это использовать мост.

2)Без моста тоже можно, если впн клиенты будут в другой сетке. Тогда на роуторе нужно просто добавить маршрут для сети в которой находятся впн клиенты. Так работать будет.

ну спасибо, что проверил, а то самому лень было

про то, что работать будет, если сетка другая, это понятно, но у меня задача, чтобы в текущей подсети было, я об этом писал