https://www.softether.org/4-docs/1-manual/5._SoftEther_VPN_Bridge_Manual/5.3_...

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

Ну прокинь порт openvpn через шлюз и всё (DNAT/SNAT). Не вижу проблем.

в iptables? как будет выглядеть шаблонная строка?)

На память не помню, погугли «проброс порта в локальную сеть iptables»

в iptables? как будет выглядеть шаблонная строка?)

«Вы за меня еще и есть будете?»

наверное это верный путь?)))

https://serverfault.com/questions/540671/filter-broadcast-traffic-in-a-bridge...

1) Пробрасываешь порт: http://bfy.tw/G7IW
2а) Настраиваешь маршруты на роутере, чтобы до клиентов пакеты доходили: http://bfy.tw/G7If
2б) Прячешь всех клиентов за адресом vpn сервера: http://bfy.tw/G7Ih

Если сервера RHEL\CentOS, гуглить аналогично, но по firewall-cmd

Как читал в инете iptables юзают для уровня 3, а ebtables для уровня 2. Проблема в возможности использовании бродкаста определенными мессенджерами, н-р Squiggle A free open source LAN Messenger видит клиентов по обе стороны шлюза, а Qualia LAN Messenger нет. Второй удобней и на русском, на первом русского нет...((( ,Думаю поиграться с ebtables, как бы настроить чтобы явно указывал мессенджерам куда и через что рассылать бродкасты.

/me чукча не читатель, чукча пейсатель…

наверное проблема в передаче udp датаграмм от клиента на порт 50000 шлюза. один месенжер бьет ч/з шлюз, другой нет. который бьет юзает много портов кроме 50000, другой только 50000 и не бьет... iptables или ebtables поможет? много правил перепробовал не помогает...(((

ура, в логах месенжера вижу что они видят друг друга ч/з шлюз, но как будто находящихся на самом шлюзе, т.е. на 192.168.1.1. виноват NAT?

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

Без чёткой схемы сказать не просто, вполне вероятно, есть NAT, там где он не нужен.

в разделе *nat

-A POSTROUTING -j MASQUERADE чтобы интернет пошел на клиентов в локальной сети шлюза.

истина где-то рядом)

udp уходит на нашу широковещалку Sending UDP datagram to 192.168.1.255:50000

а прилетает только с сервера (шлюза) UDP datagram received from 192.168.1.1

думаю надо разрешить исходящие udp с сервера, если не пойдет то и входящие

Без схемы сети, тяжковато и лениво вникать. Но в общем случае, изучи iptables, включи логи и счетчики на правилах - ничего сложного, но немного утомительно. :) Тогда попроще будет.

А если твои lan мессенджеры будут на компах из разных подсетей, они друг друга видеть не смогут? Это я к тому, что может удобней настроить подключение к openvpn в режиме tun?

Твои мессенджеры используют L2 броадкаст или L3?

режим моста, tap как бы расширяет сеть на клиентов, они как бы оказываются внутри нашей сети, видны в Сетевом окружении. Рассылают бродкасты в пределах локальной сети, да уровень 2. Squiggle даже без дополнительных модулей бьет через шлюз, но он на английском((

позже попробую серв опена в режиме tcp, может даже и на порте 50000...)))

голову сломал...

пжлст подскажите в чем именно проблема...

1) openvpn не пропускает мульти- и/или бродкаст; 2) виноват маскарадинг, nat в iptables; 3) просто перекинуть порты?

искал, пробовал, всё не то, просто некуда прибиться...

поведение локального месенжера: udp отправляет на нашу широковещалку Sending UDP datagram to 192.168.1.255:50000

а видит клиентов за шлюзом как сидящих на одном адресе (шлюза) UDP datagram received from 192.168.1.1

Пара других месенжеров видят за шлюзом, но они не вариант. Отсюда вытекает что udp работает, требуемый месенжер использует только один порт udp 50000, а бьющий ч/з шлюз несколько...

wireshark на клиенте на tap0 протокол ICMP показывает

что для источника 192.168.1.1 недоступны на клиенте порты udp 55015, 58089, и другие близкие из этого диапазона, примерно 49000 и выше.

Показывайте настройки, как сервера так и клиента, так же схемку реальную не лишне, плюс выхлопы всяких ip a, ip s. Да и iptables-save

схема обычная звездочка с центром-шлюзом 192.168.1.1, openvpn как мост, или вирт.коммутатор, расширяющий сеть

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 48:5b:39:ed:48:56 brd ff:ff:ff:ff:ff:ff inet белый айпи/30 brd белый айпи.5 scope global eth0 valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000 link/ether 9c:d6:43:63:03:56 brd ff:ff:ff:ff:ff:ff 4: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 100 link/ether 16:35:9a:14:63:c6 brd ff:ff:ff:ff:ff:ff 5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 16:35:9a:14:63:c6 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global br0 valid_lft forever preferred_lft forever

# Generated by iptables-save v1.4.21 on Fri Nov 18 20:26:43 2016 *mangle :PREROUTING ACCEPT [118826651:26150918668] :INPUT ACCEPT [111998010:22380745707] :FORWARD ACCEPT [7366664:3815591543] :OUTPUT ACCEPT [97588441:17771447572] :POSTROUTING ACCEPT [104960516:21587947505] COMMIT # Completed on Fri Nov 18 20:26:43 2016 # Generated by iptables-save v1.4.21 on Fri Nov 18 20:26:43 2016 *filter :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] -A FORWARD -d 192.168.1.170/24 -j ACCEPT -A FORWARD -s 192.168.1.170/24 -j ACCEPT -A FORWARD -m string -j DROP --string «BitTorrent» --algo bm --to 65535 -A FORWARD -m string -j DROP --string «BitTorrent protocol» --algo bm --to 65535 -A FORWARD -m string -j DROP --string «peer_id=» --algo bm --to 65535 -A FORWARD -m string -j DROP --string ".torrent" --algo bm --to 65535 -A FORWARD -m string -j DROP --string «announce.php?passkey=» --algo bm --to 65535 -A FORWARD -m string -j DROP --string «torrent» --algo bm --to 65535 -A FORWARD -m string -j DROP --string «announce» --algo bm --to 65535 -A FORWARD -m string -j DROP --string «info_hash» --algo bm --to 65535 COMMIT # Completed on Fri Nov 18 20:26:43 2016 # Generated by iptables-save v1.4.21 on Fri Nov 18 20:26:43 2016 *nat :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A PREROUTING -p tcp -m tcp -s 192.168.1.0/24 --dport 80 -j REDIRECT --to-ports 3128 -A PREROUTING -p tcp -m tcp -s 192.168.1.0/24 --dport 443 -j REDIRECT --to-ports 3129 -A POSTROUTING -j MASQUERADE COMMIT # Completed on Fri Nov 18 20:26:43 2016

www.linux.org.ru/help/lorcode.md
В нормальном виде выложите, для вас тэг [ code]

что для источника 192.168.1.1 недоступны на клиенте порты udp 55015, 58089, и другие близкие из этого диапазона, примерно 49000 и выше.

Теперь.
1. Почему так решили?
2. Что на клиенте? ip a; ip r s; iptables-save

1. даже если просто опенвпн-клиент связывается сразу в wireshark идут 4-5 строк icmp port unreachable.

2. клиенты обычные windows хр и семерки...

на сервере

> ip r s
default via белый айпи.113 dev eth0 
белый айпи.112/30 dev eth0  proto kernel  scope link  src белый айпи
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1

2. клиенты обычные windows хр и семерки...

Антивири и другие радости офтопа.

Можно изначально проверить на онтопе в кач-ве клиента.

антивирус беспл. Авира, он не замечен в блокировке чего-либо в отличие от того же, кажем, 360 Total Security... Брандмауэры как правило отключаю. Просветите что на Вашем жаргоне означает «онтоп».

Просветите что на Вашем жаргоне означает «онтоп».

linux. И это не «мой жаргон», вы на сайте linux.org.ru
Попробуйте на linux, что бы не задумываться о глюках win.

Вообще грешу на конф сервера openvpn - в дефолте есть там строка push «redirect-gateway def1 bypass-dhcp», я использую push «redirect-gateway bypass-dhcp bypass-dns» чтобы машина клиента на 7-ке получила Шлюз по умолчанию IPv4. Наверное не стоит использовать его, подозрение на то что клиенты не получают маршрут к сети за шлюзом. Надо ковырять другие параметры.((

да, давно хотел, используя дефолтный конфиг сервера опена настроить по новой, в качесвте клиента используя н-р Runtu. Можете подсказать где самый простой и толковый мануал настройки клиента опена на debian/ubuntu?

Ну хотите, ковыряйте... я вам выше уже все что смог предложил... смотрим рутинг, смотрим fw. И повторюсь, что бы не грешить на win, сначала попробуйте на linux клиенте. Если не заработает будем здесь подробно разбирать, если заработает то ковыряйте винду.

bypass-dhcp bypass-dns

Читаем маны, все очень просто:

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).

bypass-dns -- Add a direct route to the DNS server(s)  (if  they
              are  non-local)  which bypasses the tunnel (Available on Windows
              clients, may not be available on non-Windows clients).

Можете подсказать где самый простой и толковый мануал настройки клиента опена на debian/ubuntu?

Не поверите, но там же где и для всех остальных дистров.

антивирус

На днях заходил на https://sourceforge.net/

Там пользуются Bitdefender...

попробовал на чистой установке ХР, затем попробовал также на win7 (минимальное изменение конфа, основные параметры - server-bridge, push «redirect-gateway def1 bypass-dhcp», кста при этом клиент на win7 не получает шлюза Ipv4 но клиент виден как за белым ip, и инф.интернет-система доступна только по этому белому ip), та же проблема. Думаю, проблема в nat. без него клиентам не будет инета, но и за шлюзом адреса клиентов будут nat-иться и отображаться как адрес шлюза... но почему месенжер долбится не на внешний белый ip-адрес сервера а на внутренний его локальный адрес 192.168.1.1? Месенжер, рассылающий udp, получает ответ «UDP datagram received from 192.168.1.1», т.е. видит других как сидящих на одном ip (192.168.1.1), но различает их по своему идентификатору, н-р user 7085C24D4FAAADMIN, user E8039A36DBD3ADMIN, user F07959DF15F6ADMIN, 80EE7339FEE9ADMIN и т.п.

кста при этом клиент на win7 не получает шлюза

1. Запускать от имени администратора
2. В конфиг клиента route-delay 30
3. Возможно. В конфиг клиента route-method exe

Думаю, проблема в nat. без него клиентам не будет инета,

-A POSTROUTING -o eth0 -j MASQUERADE

>-A POSTROUTING -o eth0 -j MASQUERADE

хммм прикольно... у меня -A POSTROUTING -j MASQUERADE, т.е. тупо на все интерфейсы... Под «eth0», думаю, вы имеете в виду внешний интерфейс. Что-то страшно ковырять NAT, т.к. опасаюсь меня отрежет от интернета, потому что сижу по удаленке. И еще думаю, что это правило должно заменять имеющееся, неважно идет ли оно первым.

Что-то страшно ковырять NAT, т.к. опасаюсь меня отрежет от интернета, потому что сижу по удаленке.

Для этого изобретают велосипеды. Например в крон возврат через определенное время старых конфигов и старт их или совсем по хардкору ребут.
Вполне рабочее решение. 1. Проверяеш что конфиги вернулись. 2. Пишеш в крон задачу с периодом удобным для тебя. 3. Ковыряеш fw.

УУУУУУУУУУУУРРРРРРРРААААААААААААА!!!!!!!!!!!!!!!!!!

ВСЕ КЛИЕНТЫ из разных населенных пунктов В МЕСЕНЖЕРЕ ВИДНЫ вместе!!!

Для win7 помог только push «redirect-gateway bypass-dhcp bypass-dns», от админа не требуется и для ХР подходит.

РЕШЕНИЕ для страждущих - не натить все подряд а только внешний интерфейс. Большое спасибо anc!!!)))

при push «redirect-gateway bypass-dhcp bypass-dns» через некоторое время на win7 теряется связь с мостом, с дефолтным push «redirect-gateway def1 bypass-dhcp» пока полет нормальный.

окончательно будет

push «redirect-gateway def1»