подредактируй сообщение с нормальной разметкой, c утра больше 5 строчек не воспринимается сходу ;)

КТО НИАСИЛИЛ ПРОЧИТАТЬ СТАВЬТЕ КЛАСС!!!!!!!!

«хотя я уже начанию сомневаюсь что эта технология openvpn bridge вообще работает...»
1. Оформите хотя-бы пост по человечески.
2. openvpn-bridge все прекрасно работает.Читайте документацию.

Лови конфиг.
cat server.conf |grep -v ^# |grep -v ^$
port 1194
proto tcp
dev tap
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key # This file should be kept secret
dh /etc/openvpn/keys/dh2048.pem
server-bridge 192.168.0.111 255.255.252.0 192.168.1.10 192.168.3.255
server-bridge
push «route 192.168.16.0 255.255.255.0»
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn-status.log
log /var/log/openvpn.log
verb 15
script-security 2
up /etc/openvpn/server_up.sh

#!/bin/sh
# Переводим интерфейс в состояние «up»
/sbin/ifconfig tap0 up
# Добавляем его в br0
/sbin/brctl addif br0 tap0

Ну и соответственно сам физический интерфейс на сервере должен быть включен в bridge

dev tap обязательно должен быть dev tap0, на клиенте, думаю, неважно. я мост создал только конфигом interfaces. думаю это неправильно, правильней наверное добавлять командами, как на https://wiki.debian.org/BridgeNetworkConnections. tap0, думаю не создается, просто поднимается из недр ядра... И вообще думаю дефолтный конфиг сервера закинуть и доводить отдельными строчками...

server-bridge 192.168.0.111 255.255.252.0 192.168.1.10 192.168.3.255 server-bridge а они друг другу не мешают? push «route.. думаю это явно указать внутреннюю сеть?

кстати помещал строку про server_up.sh в конф серва - ругалось в логах на уровень безопасности... переместил строку в interfaces но tap0 запускался только ручками... потом, заметил, засыпает...

tap0 должен быть всегда up чтобы работал мост?

и еще раз кстати - server-bridge 192.168.0.111 255.255.252.0 192.168.1.10 192.168.3.255 неправилен, т.к. х.255 это широковещание... и мост странный...

т.е. маска

давайте сначала создадим мост, затем добавим tap0. как всегда он должен быть связан с eth1 (green). пример - # brctl addbr br0 # brctl addif br0 eth1 tap0

затем в interfaces пишем bridge_utils и адаптеры, на разных сайтах туда пишут разные интерфейсы, могут написать и один, две или три через пробел... в моем случае это bridge_utils eth1 tap0? адрес, маска с eth1 переходят на br0 и на eth1 вместо static ставится manual? а что насчет tap0 в interfaces? его пишут и не пишут, даже добавляют автозагрузку.

в дальнейшем для траблшутинга - надо создать отдельный лог для openvpn, т.к. verbosity level в конфе серва не влияет на дефолтный лог в папке серва... надо погуглить как делается или сюда пжлст пример)))

и если я сделаю работающий мост с клиентами, видящими локалку то напишу мануал как раз для начинающих... а пока, думаю никто не даст мне пошаговую инструкцию по мостам, interfaces, конфам...

Заниматься сервом могу только после 19.00 мск+2, т.к. нужна сеть...

Забыл убрать , когда конфиг выкладывал.

и еще раз кстати - server-bridge 192.168.0.111 255.255.252.0 192.168.1.10 192.168.3.255 неправилен, т.к. х.255 это широковещание... и мост странный...

У меня тут все верно.


0.111 ip сервера
252 маска
192.168.1.10 192.168.3.255 - диапазон ( сам по маске посчитай, не хотелось 254 вписывать. )

16 подсеть push клиенту дается.

Ничего там сложного.
Делаешь bridge

cat /etc/network/interfaces

auto br0
iface br0 inet static
address 192.168.0.111
netmask 255.255.252.0
gateway 192.168.0.2
bridge_ports eth0
bridge_stp off
bridge_fd 0

не люблю извращаться по маскам... я ортодокс))) дошел до того что на клиенте открывается сайт по работе, к которому у нас доступ только с нашего внешнего айпи, значит весь трафик перенаправляется ч/з tap0. Осталась проблема - клиент не получает dns адрес, и следовательно не видит внутреннюю сеть... Гугл не помог, у каждого свои причины... Может и iptables мешает, но я давал команды на пропуск трафика ч/з мосты и интерфейсы.

кста gateway 192.168.0.2 не должен указываться в конфе если этот комп сам шлюз? у нас есть gateway на внешке. мне писал один что от двух gateway у ядра сносит башку...))))

вот пишут в interfaces всякие разные bridge_stp off bridge_fd 0 и еще много чего. а можно же прекрасно обойтись без них? и добавлять по мере проблем?

У меня vpn сервер за натом.
192.168.0.111 у меня виртуальная машина , шлюз 0.2

вот читаю маны и вижу что в конфе серва есть server-bridge 10.8.0.4 255.255.255.0 10.8.0.128 10.8.0.254 и просто server-bridge

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

Вышестоящий орган дал указание по внедрению защиты интернета

давно пора. от кого защищаете хоть?

If --server-bridge is used without any parameters, it will enable a DHCP-proxy mode, where connecting OpenVPN clients will
receive an IP address for their TAP adapter from the DHCP server running on the OpenVPN server-side LAN. Note that only clients
that support the binding of a DHCP client with the TAP adapter (such as Windows) can support this mode. The optional nogw flag
(advanced) indicates that gateway information should not be pushed to the client.

Так вроде же написано что: If --server-bridge is used without any parameters, it will enable a DHCP-proxy mode, where connecting OpenVPN clients will
receive an IP address for their TAP adapter from the DHCP server running on the OpenVPN server-side LAN.

да, планирую использовать server-bridge is used without any parameters, только пока времени нет.

tls_server = disabled пишет... хотя сгенерировал и закинул в корень серва и дал клиенту... tls_client = enabled пишет, ремил ключи и тп. не помогало...

сделал как здесь https://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethe... использовал server-bridge без параметров как на https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage на клиенте даже tap не подключается...

как скинуть лог клиента, конф сервера? пишет большое сообщение...

с дефолтным конфигом клиент сразу получил данные от параметра «server 10.8.0.0 255.255.255.0». а вот server-bridge с параметрами и без не катит. наверное мост неправилен... хотя в interfaces вернул eth1 к прежнему виду. пересоздал мост скриптом из https://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethe... и на автозагрузку прописал в interfaces.

кто глянет по удаленке (teamviewer) пишите на мыло в первом сообщении...

Для начала
1. Пропишите с server-bridge с параметрами
2. Создайте бридж
3. Запустите сервер
4. Покажите выхлоп
brctl show
ifconfig
и конфиг сервера
ЗЫ Ну и наверно конфиг клиента.

два других компа как подключились пропали из видимости тимвьюера. из дома получилось подключиться к шлюзу. ура. 2ip.ru кажет внешнюю статику шлюза, интернет есть, тима тоже работает, в Сетевых подключениях на домашнем (win7prosp1x64) TAP адаптер тоже кажет Доступ к интернету как и модемка 3G. РАБОЧИЙ КОМП ЗА ШЛЮЗОМ ПИНГУЕТСЯ. млин капс пошел...

но нет Сетевого окружения, lan messenger не видит контакты в подсети за шлюзом. Как я понял bridging может дать полноценное сетевое окружение как если бы я подключился напрямую к локлаьной сети? неясно со строкой redirect-gateway def1 bypass-dhcp, убрал def1.

TAP адаптер кажет то есть интернет то нет интернета... нестабильно как-то. использую server-bridge без параметров. помнится при использовании с параметрами OpenVPN GUI показывал на всплывающей подсказке какие адреса получил. но тогда он упорно не хотел получать dns, т.к. в «server-bridge 192.168.8.4 255.255.255.0 192.168.8.128 192.168.8.254» нет dns.

неясно со строкой redirect-gateway def1 bypass-dhcp, убрал def1.

man openvpn там все очень хорошо описано по параметру redirect-gateway

но тогда он упорно не хотел получать dns

Так же man openvpn
push «dhcp-option DNS 8.8.8.8»

может и bypass-dhcp тоже убрать? не нравится его описание))) - Add a direct route to the DHCP server (if it is non-local) which bypasses the tunnel (Available on Windows clients, may not be available on non-Windows clients). DHCP server как раз таки локальный - 192.168.1.1, хотелось бы чтобы клиенты брали dns и берут 192.168.1.1 а не внешние если буду ставить прокси-сервер Squid.

и может dns-суффикс example.org тоже мешает?)))) надо заремить завтра... жаль пока не сделал x11vnc...

тут netbios замешан? или просто настройкой сервера опенвпн возможно настроить чтобы клиенты видели сетевое окружение?

Caveats Redirecting all network traffic through the VPN is not entirely a problem-free proposition. Here are some typical gotchas to be aware of: Many OpenVPN client machines connecting to the internet will periodically interact with a DHCP server to renew their IP address leases. The redirect-gateway option might prevent the client from reaching the local DHCP server (because DHCP messages would be routed over the VPN), causing it to lose its IP address lease. Issues exist with respect to pushing DNS addresses to Windows clients. Web browsing performance on the client will be noticably slower.

смог подключиться к шаре за шлюзом по айпи-адресу «\\192.168.1.198\обмен» после того как увидел в интернете «В сетевом окружении вы компьютеры удаленной сети все равно не увидите, но к ним можно обращаться по IP-адресу...» но компы в локалке берут адреса от серва дшсп, так что айпишки не катят. Надо как-то настроить разрешение dns-имен в openvpn сервере... Подскажите пжлст))))

Я вам уже подсказал выше. А вообще в школу учиться, учиться и еще раз учиться + на винфак.
ЗЫ У хорошего админа и через tun несколько AD работают нормально. :)

может прописать /etc/openvpn/update-resolv-conf в конфиг серва?

нужен бродкаст? - но он прописан на мосту в interfaces

выложу завтра конфы серва, клиента, выхлоп ifconfiga. гляну лог опен-серва и клиента, додумался принести на работу 3g-модемку для теста...

опытным путем выведено что доступ к локалке можно настроить парой строк - server-bridge push «redirect-gateway def1 bypass-dhcp» если в сети уже есть сервера dhcp, bind9, н-р там же где и сервер openvpn. остальные строки, относящиеся к роутингу, бриджингу, имеющие цифры надо заремить, а другие не трогать.

но все еще остается нерешенной проблема видимости клиентами компьютеров в Сетевом окружении за шлюзом... Это критично для программ, работающих в локальной сети. wins не предлагать т.к. он только разрешает имена. кстати в Обзоре сети дебиана клиент виден.

Добавь client-to-client в файл конфигурации сервера

спасибо за совет, вот мои конфиги

server-bridge push «redirect-gateway def1 bypass-dhcp» port 1194 proto udp dev tap0 ca ca.crt cert server.crt key server.key dh dh2048.pem client-to-client keepalive 10 120 comp-lzo user nobody group nogroup persist-key persist-tun status openvpn-status.log log openvpn.log verb 6 # для запуска скрипта, поднимающего мост script-security 2 ------------------------------------------------------------------------------------- client dev tap proto udp remote ip-адрес шлюза 1194 resolv-retry infinite nobind ;user nobody ;group nogroup persist-key persist-tun ca ca.crt cert client.crt key client.key ns-cert-type server comp-lzo verb 6

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

ура!!! Сетевое окружение сделано!!! почему-то через шлюз бьет только beebeep, lan messenger видит только в своем сегменте, т.е. локальные не видят клиентов и обратно.

все работало хорошо, но после отпуска не работает сетевое окружение, net view дает ошибку 6118. компы пингуются по имени/адресу. мастер браузер работает, сервер wins тоже. дело не в клиентах, а на самом шлюзе дебиан. в чем может быть проблема?

пингую шлюз а кажет мой рабочий комп...

nbtstat -a 192.168.1.1

встав: Адрес IP узла: [192.168.1.198] Код области: []

Таблица NetBIOS-имен удаленных компьютеров

Имя Тип Состояние ---------------------------------------------------- DEBIAN <00> Уникальный Зарегистрирован DEBIAN <03> Уникальный Зарегистрирован DEBIAN <20> Уникальный Зарегистрирован ..__MSBROWSE__.<01> Группа Зарегистрирован MSHOME <00> Группа Зарегистрирован MSHOME <1B> Уникальный Зарегистрирован MSHOME <1D> Уникальный Зарегистрирован MSHOME <1E> Группа Зарегистрирован

Адрес платы (MAC) = 00-00-00-00-00-00

по выборам шлюз - 255

хммм... решилось добавлением 127.0.0.0/8 lo в interfaces... Думал что сетевое окружение работает сразу после запуска самбы, но оказалось компы отображались как бы по остаточному принципу, т.е. я не менял подсеть. После добавления loopback думаю сетевое окружение для винды окончательно настроено в самбе.

127.0.0.0/8 lo в interfaces...

имеется в виду строка «interfaces =» в smb.conf...