LINUX.ORG.RU
ФорумAdmin

Пустить устройство в рабочую сеть


0

1

Есть писюк с двумя сетевухами, eth0(инет) и eth1. На писюке поднят openvpn туннель до работы, соответственно имеется устройство tun0.

Есть тонкий клиент, который нужно завести в рабочую сеть через openvpn.

Я рассуждал следующим образом: создаем бридж, добавляем туда eth1 и tun0, втыкаем тонкий клиент, PROFIT.

Но на практике получается следующее, бридж создается, eth1 туда добавляется, а вот tun0 фигушки:

$brctl addif br0 tun0
can't add tun0 to bridge br0: Invalid argument
Так что я понимаю, что что-то не понимаю, вопрос что?

Вызов strace оканчивается вот чем:

socket(PF_FILE, SOCK_STREAM, 0)         = 3
access("/proc/net", R_OK)               = 0
access("/proc/net/unix", R_OK)          = 0
socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 4
ioctl(4, SIOCGIFINDEX, {ifr_name="tun0", ifr_index=6}) = 0
close(4)                                = 0
ioctl(3, SIOCBRADDIF, 0xbfc8567c)       = -1 EINVAL (Invalid argument)
ioctl(3, SIOCDEVPRIVATE, 0xbfc8567c)    = -1 EINVAL (Invalid argument)
write(2, "can't add tun0 to bridge br0: In"..., 47can't add tun0 to bridge br0: Invalid argument
) = 47
exit_group(1)  

Как быть? Или, есть ли другие способы завести тонкий клиент в сеть предприятия? cast blind_oracle

★★★★★

Последнее исправление: eagleivg (всего исправлений: 2)

eth1 куды смотрит или просто так болтается?

И шо такое тонкий клиент - он слишком мало кушал?

aeX1pu2b
()
Ответ на: комментарий от eagleivg

Разница в том, что tun это ip интерфейс и добавить его в бридж низя. А tap - ethernet интерфейс и отлично бриджуется. Так что смелее в бой :)

blind_oracle ★★★★★
()
Ответ на: комментарий от eagleivg

дык, echo 1 > /proc/sys/net/ipv4/ip_forward

и iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT

Это вкраце - гуглани по поводу построения роутера на лин

aeX1pu2b
()
Ответ на: комментарий от aeX1pu2b

Это если подсети разные. А он, я так понял, хочет запихать домашний девайс в броадкаст домен рабочей сети. Для этого надо на работе забриджевать tap в рабочую сеть, и дома тоже.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

К сожалению, не прокатит. На работе к настройкам OpenVPN не имею доступа. Разве что, действительно попробовать роутить через tun.

eagleivg ★★★★★
() автор топика
Ответ на: комментарий от eagleivg

А просто поднять на клиенте TAP пробовали? С OpenVPN дел не имел, но мне кажется что может сработать.

MrClon ★★★★★
()
Ответ на: комментарий от blind_oracle

да кака фиг разница, eth1 - 192.168.1.1, тонкий клиент 192.168.1.2 и еще одно правило в iptables (не хотел разжевывать, иногда надо и своей головой думать)

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

И пакеты побегут без замечаний :)

aeX1pu2b
()
Ответ на: комментарий от eagleivg

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

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Они пойдут, если на том конце знают про твою сеть и роутинг правильно повёрнут.

Вот ето правило:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

говорит, что все пакеты которые пойдут через интерфейс tun0 маркировать ip tun интерфейса и оборудованию на том конце нафиг не надо знать про твою сеть. А роутинги в уту сеть приходят при подключении openvpn.

aeX1pu2b
()
Ответ на: комментарий от aeX1pu2b

Я в курсе что такое нат, ага.

А роутинги в уту сеть приходят при подключении openvpn.

Если проходят, то да. Но это совсем не факт и не то же самое, как если бы ты сбриджевал удаленный tap интерфейс с езернетом тамошним.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Если проходят, то да.

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

Данная схема которую я описал называется типичный NAT, а преимущества ее в том - что если за eth1 находится домашняя подсеть, то все устройства из домашней сети получат доступ уту сеть :)

aeX1pu2b
()
Ответ на: комментарий от aeX1pu2b

Еще раз, смотри - есть в удаленной сети некий девайс, до которого строится из дома тоннель. За этим тоннелем твоя нат-сеть. Так вот девайсы в удаленной сети про твой openvpn ничего не знают, если девайс, до которого строится openvpn не является им шлюзом по умолчанию. А если ты сделаешь tap и бридж, то твой девайс домашний появится в их ethernet сети, будет отвечать на арп-запросы и т.п. и при этом никакого доп. роутинга делать не надо.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

девайсы в удаленной сети про твой openvpn ничего не знают

Совсем запутал, а зачем тогда админ в удаленной сети поднимал openvpn сервер? Обычно поднимают для того что бы удаленное устройство подключалось из инета к сетке предприятия и имело доступ на определенные сервера в сети предприятия. Так вот, в данном случае это удаленное устройство является роутером и этот удаленный роутер/комп имеет доступ к тем серверам в корпоративной сети, к которым разрешен доступ, а соответственно все устройства, которые находятся за удаленным устройством(за натом) так же имеют доступ. А бридж - это костыль. И будет ли он работать с VPN - большой вопрос. Во всяком случае я не пробовал. Да и зачем?

aeX1pu2b
()
Ответ на: комментарий от aeX1pu2b

Совсем запутал, а зачем тогда админ в удаленной сети поднимал openvpn сервер?

Да хрен его знает, может его поднял кто-то для своих нужд. Автор нам не дал данных для выводов

Так вот, в данном случае это удаленное устройство является роутером и этот удаленный роутер/комп имеет доступ к тем серверам в корпоративной сети, к которым разрешен доступ, а соответственно все устройства, которые находятся за удаленным устройством(за натом) так же имеют доступ.

Совсем не факт, что этот доступ двусторонний, смотри выше

А бридж - это костыль. И будет ли он работать с VPN - большой вопрос. Во всяком случае я не пробовал.

Это по твоему скромному мнению - костыль. А когда встает задача объеденить два броадкаст домена удаленных друг от друга, то вот тогда кроме как бриджом задачу не решить. И он отлично работает с tap-интерфейсами в общем (и с OpenVPN в частности), проверено многократно. Это, по сути, основа сетевой подсистемы виртуализации в линуксе, доступ VM к внешней сети обычно реализуется бриджеванием tap-интерфейсов гипервизора с физическими линками. Сейчас переходят на Open vSwitch, но это, по сути, просто умный бридж :)

Так что это ну никак не костыль.

blind_oracle ★★★★★
()
Последнее исправление: blind_oracle (всего исправлений: 1)
Ответ на: комментарий от blind_oracle

Совсем не факт, что этот доступ двусторонний, смотри выше

Ну дружище, вы совсем :) Где написано двухсторонний, в данном случае доступ только с клиента на сервер openvpn и сервера предприятия (вы хотятбы почитайте wiki про vpn, не обязательно openvon :)))

Это, по сути, основа сетевой подсистемы виртуализации в линуксе, доступ VM к внешней сети обычно реализуется бриджеванием tap-интерфейсов гипервизора с физическими линками.

Вот именно виртуальных машин на хосте, а где в вопросе темы про виртуальные машины? Да и кстати вопрос, а в решении с бриджем будет доступ на сервера предприятия с самой машины, не с тонкого клиента?

Дружище - вы попутали темы.

aeX1pu2b
()
Ответ на: комментарий от aeX1pu2b

А когда встает задача объеденить два броадкаст домена удаленных друг от друга, то вот тогда кроме как бриджом задачу не решить

А GW/шлюзы зачем придумали? Зачем придумали циски, опенбсд, айпитаблесы, ракэдж фильтры и т.д. и т.п.

P.S. Начните с изучения модели OSI, в wiki хорошо про это написано. Обратите внимание (в данном случае) про третий уровень.

aeX1pu2b
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.