znaczacy > comp.os.* > comp.os.linux.sieci

MaRc (20.10.2010, 18:55)
witam
mam pewien problem/dylemat z vpenem. w sieci mam kilkanascie vlanów. w
kazdym z vlanów m.in. kilkanascie urzadzen do których m.in. mozna dostac
sie po adresie mac oraz to ze maja poustawiane inne bramy niz mój serwer
vpn i teoretycznie ma tak zostac a praktycznie maja byc pousuwane bramy na
tych urzadzeniach.
po prostu przez vpn musi byc dostep do wszystkich urzadzen w sieci, we
wszystkich vlanach.
dlatego chce zrobic ethernet bridging.
o ile dziala mi to z jednym eth i jednym tap to problem i dylemat sie
pojawia gdy musze do tego dodac vlany.
w dokumentacji openvpn jest napisane, zeby najpierw pobridgeowac wszystkie
ethernety najlepiej skryptem:

#!/bin/bash

#################################
# Set up Ethernet bridge on Linux
# Requires: bridge-utils
#################################

# Define Bridge Interface
br="br0"

# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap="tap0"

# Define physical ethernet interface to be bridged
# with TAP interface(s) above.
eth="eth0"
eth_ip="192.168.8.4"
eth_netmask="255.255.255.0"
eth_broadcast="192.168.8.255"

for t in $tap; do
openvpn --mktun --dev $t
done

brctl addbr $br
brctl addif $br $eth

for t in $tap; do
brctl addif $br $t
done

for t in $tap; do
ifconfig $t 0.0.0.0 promisc up
done

ifconfig $eth 0.0.0.0 promisc up

ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast

jak widac ze skryptu, tworzy on mi br0 do którego dodaje tap0 oraz moje
eth. jak zaczne dodawac moje interfejsy vlanowe to ruch z nich zacznie byc
forwardowany do innych a nie takie zalozenie bylo tworzac vlany :( miedzy
vlanami nie moze przejsc zaden pakiet

móglby mi ktos podpowiedziec jak to w OpenVPN pokonfigurowac?
Czy musze na kazdy interfejs vlan dodac interfejs tap oraz bridge? np.
jesli mam vlan250 to:
openvpn --mktun --dev tap250
brctl addbr br250
brctl addif br250 tap250
brctl addif br250 vlan250

i wówczas w konfiguracji serwera wpisac wszystkie tapX??
czy dobrze kombinuje? a moze jakos inaczej powinienem to zrobic??
ein (20.10.2010, 23:56)
On 10/20/2010 06:55 PM, MaRc wrote:
> witam
> mam pewien problem/dylemat z vpenem. w sieci mam kilkanascie vlanów. w
> kazdym z vlanów m.in. kilkanascie urzadzen do których m.in. mozna dostac
> sie po adresie mac oraz to ze maja poustawiane inne bramy niz mój serwer
> vpn i teoretycznie ma tak zostac a praktycznie maja byc pousuwane bramy
> na tych urzadzeniach.


Co masz na mysli piszac, ze mozna dostac sie po adresie fizycznym?

[..]
> brctl addif br250 vlan250
> i wówczas w konfiguracji serwera wpisac wszystkie tapX??
> czy dobrze kombinuje? a moze jakos inaczej powinienem to zrobic??


Troche to bez sensu, poniewaz jak z polaczysz wszystkie swoje VLANy w 2
warstwie, to jest tak naprawe jak bys z nich zrezygnowal.

Ja widze 2 wyjscia:
- puszczasz caly ruch klienta przez domyslna brame, która jest serwer
VPN i on routuje klienta do Twoich poszczególnych VLANów.
- puszczasz do klienta trasy dla kazdego z VLANów i routujesz takze na
serwerze VPN.

Moim zdaniem pierwszy sposób jest bardziej kompleksowy i prostszy do
wdrozenia, ale wymaga sporej predkosci uploadu po stronie serwera.

Pozdrawiam.
MaRc (21.10.2010, 09:08)
> Co masz na mysli piszac, ze mozna dostac sie po adresie fizycznym?

po mac. np. do mikrotików jest taki fajny programik winbox. on wyszukuje
wszystkie mikrotiki w sieci i wlasnie do tego wykorzystuje 2 warstwe

> Troche to bez sensu, poniewaz jak z polaczysz wszystkie swoje VLANy w 2
> warstwie, to jest tak naprawe jak bys z nich zrezygnowal.


no tak samo mysle. ale jesli na iptables zrobie forward na deny pomiedzy
vlanami to powinno pomoc.

> - puszczasz caly ruch klienta przez domyslna brame, która jest serwer
> VPN i on routuje klienta do Twoich poszczególnych VLANów.


no ale 2 warstwy nie przeroutuje a mi na tym wlasnie zalezy

> - puszczasz do klienta trasy dla kazdego z VLANów i routujesz takze na
> serwerze VPN.


to na zwyklym tun. tez o tym myslalem. w sumie to byloby najlepsze,
najmniej komplikujace rozwiazanie ale wlasnie ta 2 warstwa.
ein (21.10.2010, 10:31)
On 10/21/2010 09:08 AM, MaRc wrote:
> po mac. np. do mikrotików jest taki fajny programik winbox. on wyszukuje
> wszystkie mikrotiki w sieci i wlasnie do tego wykorzystuje 2 warstwe
> no tak samo mysle. ale jesli na iptables zrobie forward na deny pomiedzy
> vlanami to powinno pomoc.


Jak bedzie _drop_ - to to spelni zadanie.

>> - puszczasz caly ruch klienta przez domyslna brame, która jest serwer
>> VPN i on routuje klienta do Twoich poszczególnych VLANów.

> no ale 2 warstwy nie przeroutuje a mi na tym wlasnie zalezy


Bedzie dzialac, jezeli wszystkie interfejsy VLANów beda spiete w jednym
bridge-u.

>> - puszczasz do klienta trasy dla kazdego z VLANów i routujesz takze na
>> serwerze VPN.

> to na zwyklym tun. tez o tym myslalem. w sumie to byloby najlepsze,
> najmniej komplikujace rozwiazanie ale wlasnie ta 2 warstwa.


Do tego jest "tap" wlasnie - 2 warstwa, a routing tez mozesz na nim
postawic.

Postaw tam wirtualke i podepnij do niej wszystkie interfejsy VLAN -
bedzie prosciej... (;
ein (21.10.2010, 10:39)
On 10/21/2010 10:31 AM, ein wrote:
> On 10/21/2010 09:08 AM, MaRc wrote:
>> no ale 2 warstwy nie przeroutuje a mi na tym wlasnie zalezy

> Bedzie dzialac, jezeli wszystkie interfejsy VLANów beda spiete w jednym
> bridge-u.


Czyli (pisze z pamieci):

brctl add br br0
brctl add if br0 tap0 (vpn)
brctl add if br0 eth0.0 (vlan0)
brctl add if br0 eth0.1 (vlan1)
....
brctl add if br0 eth0.1 (vlan253)

ifconfig br0 X.X.X.X/X up
ifconfig tap0 0.0.0.0 up
ifconfig eth0.0 0.0.0.0 up
ifconfig eth1.0 0.0.0.0 up
....
ifconfig eth0.253 0.0.0.0 up

(most moze miec z tego co pamietam max 256 urzadzen)
ein (21.10.2010, 10:41)
Tak mialo byc
[..]
MaRc (21.10.2010, 10:56)
> Czyli (pisze z pamieci):
[..]
> ifconfig eth1.0 0.0.0.0 up
> ...
> ifconfig eth0.253 0.0.0.0 up


dzieki. wlasnie tak zrobilem. do testu z 2 vlanami i dziala.
z drugiej strony, ja tu kombinuje, mecze sie a tu mi przed chwila szef
mówi, ze 2 warstwy nie musze bridgowac :/

dodatkowo chce aby kilku userow mialo dostep do wszystkiego a nieliczni
tylko do samby.

robie tak:

mkdir ccd
echo "irotue 172.16.16.0 255.255.255.0" > ccd/marcin

w server.conf dopisuje:
client-config-dir ccd
route 172.16.16.0 255.255.255.0

zgodnie z howto ze strony openvpna i niestety w tablicy klienta nie laduje
ta siec 172.16.16.0/24 :(

Thu Oct 21 10:55:01 2010 marcin/10.0.0.22:53178 OPTIONS IMPORT: reading
client specific options from: ccd/marcin
Thu Oct 21 10:55:01 2010 marcin/10.0.0.22:53178 MULTI: Learn: 172.17.2.6
-> marcin/10.0.0.22:53178
Thu Oct 21 10:55:01 2010 marcin/10.0.0.22:53178 MULTI: primary virtual IP
for marcin/10.0.0.22:53178: 172.17.2.6
Thu Oct 21 10:55:01 2010 marcin/10.0.0.22:53178 MULTI: internal route
172.16.16.0/24 -> marcin/10.0.0.22:53178
Thu Oct 21 10:55:01 2010 marcin/10.0.0.22:53178 MULTI: Learn:
172.16.16.0/24 -> marcin/10.0.0.22:53178
Thu Oct 21 10:55:03 2010 marcin/10.0.0.22:53178 PUSH: Received control
message: 'PUSH_REQUEST'
Thu Oct 21 10:55:03 2010 marcin/10.0.0.22:53178 SENT CONTROL [marcin]:
'PUSH_REPLY,route 172.17.2.0 255.255.255.0,route 172.17.2.0
255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 172.17.2.6
172.17.2.5' (status=1)
ein (21.10.2010, 11:16)
On 10/21/2010 10:56 AM, MaRc wrote:
> dzieki. wlasnie tak zrobilem. do testu z 2 vlanami i dziala.
> z drugiej strony, ja tu kombinuje, mecze sie a tu mi przed chwila szef
> mówi, ze 2 warstwy nie musze bridgowac :/


Jezeli ta aplikacja dziala wykorzystujac broadcast to ja innego wyjscia
nie widze. Natomiast jezeli unicast to moze sie udac.

> dodatkowo chce aby kilku userow mialo dostep do wszystkiego a nieliczni
> tylko do samby.
> robie tak:
> mkdir ccd
> echo "irotue 172.16.16.0 255.255.255.0" > ccd/marcin
> w server.conf dopisuje:
> client-config-dir ccd
> route 172.16.16.0 255.255.255.0


Nie stosowalem tego, ale jezeli masz malo klientów to moze spróbuj po
jego stronie. (w jego pliku konfiguracyjnym - uwaga! skladnia bedzie inna).
[..]
Olek (21.10.2010, 14:00)
On 21.10.2010 10:56, MaRc wrote:
> w server.conf dopisuje:
> client-config-dir ccd
> route 172.16.16.0 255.255.255.0


A nie powinno byc tak?
push "route 172.16.16.0 255.255.255.0"
MaRc (21.10.2010, 14:07)
> A nie powinno byc tak?
> push "route 172.16.16.0 255.255.255.0"


no wlasnie zgodnie z dokumentacja nie

"Next, we will deal with the necessary configuration changes on the server
side. If the server configuration file does not currently reference a
client configuration directory, add one now:

client-config-dir ccd

In the above directive, ccd should be the name of a directory which has
been pre-created in the default directory where the OpenVPN server daemon
runs. On Linux this tends to be /etc/openvpn and on Windows it is usually
\Program Files\OpenVPN\config. When a new client connects to the OpenVPN
server, the daemon will check this directory for a file which matches the
common name of the connecting client. If a matching file is found, it will
be read and processed for additional configuration file directives to be
applied to the named client.

The next step is to create a file called client2 in the ccd directory.
This file should contain the line:

iroute 192.168.4.0 255.255.255.0

This will tell the OpenVPN server that the 192.168.4.0/24 subnet should be
routed to client2.

Next, add the following line to the main server config file (not the
ccd/client2 file):

route 192.168.4.0 255.255.255.0

Why the redundant route and iroute statements, you might ask? The reason
is that route controls the routing from the kernel to the OpenVPN server
(via the TUN interface) while iroute controls the routing from the OpenVPN
server to the remote clients. Both are necessary.

Next, ask yourself if you would like to allow network traffic between
client2's subnet (192.168.4.0/24) and other clients of the OpenVPN server.
If so, add the following to the server config file.

client-to-client
push "route 192.168.4.0 255.255.255.0"

This will cause the OpenVPN server to advertise client2's subnet to other
connecting clients."

pytanko do uzywajacych.
ustawilem w serwer.conf opcje client-to-client. czy w otoczeniu sieciowym
powinienem widziec udostepnione zasoby zalogowanych klientów??
Olek (21.10.2010, 14:20)
On 21.10.2010 14:07, MaRc wrote:
> pytanko do uzywajacych.
> ustawilem w serwer.conf opcje client-to-client. czy w otoczeniu
> sieciowym powinienem widziec udostepnione zasoby zalogowanych klientów??


Ale masz odpalony WINS i klienci podlaczani przez VPN dostaja jego adres?
MaRc (21.10.2010, 14:32)
> Ale masz odpalony WINS i klienci podlaczani przez VPN dostaja jego adres?

o qrde. no tak. na smierc zapomnialem o wins.
musze go odpalic na sambie i podac klientom w ten sposób?
push "dhcp-option WINS 172.16.16.10"
ein (21.10.2010, 15:08)
On 10/21/2010 02:32 PM, MaRc wrote:
>> Ale masz odpalony WINS i klienci podlaczani przez VPN dostaja jego adres?

> o qrde. no tak. na smierc zapomnialem o wins.
> musze go odpalic na sambie i podac klientom w ten sposób?
> push "dhcp-option WINS 172.16.16.10"


Ja to robie przez DHCPd, a WINS _nie_ jest wymagany przy sieciach
broadcast multiaccess.
MaRc (21.10.2010, 15:17)
> Ja to robie przez DHCPd, a WINS _nie_ jest wymagany przy sieciach
> broadcast multiaccess.


ale ja w sieci nie uzywam dhcpd.
siec w której jest samba to 172.16.16.0, adres serwera to 172.16.16.10.
klieci z vpn lacza sie z adresami 172.17.2.0

w smb.conf dopisalem:

...
[global]
wins support=yes
hosts allow = 172.16.16.0/24 172.17.2.0/24 127.0.0.1

w otoczeniu sieciowym na kliencie nie widac ani serwera samby ani
udostepnionych zasobów klientów. klient na vpn dostaje serwer wins jako
172.16.16.10. teoretyczni powinno hulac. czy jeszcze moze o czyms zapomnialem?
ein (21.10.2010, 15:27)
On 10/21/2010 03:17 PM, MaRc wrote:
[..]
> udostepnionych zasobów klientów. klient na vpn dostaje serwer wins jako
> 172.16.16.10. teoretyczni powinno hulac. czy jeszcze moze o czyms
> zapomnialem?


Tak - blokujesz gdzies ruch, albo na routerze, albo na koncówkach.
Rozwijanie adresu po nazwie z WINS chodzi jak powinno?
Czy przegladarka glówna (SMB) jest router laczacy poszczególne podsieci?

Podobne w±tki