K*rva openvpn

Hálózatok egyéb

K*rva openvpn

  • 1072 megtekintés

( j_szucs | 2005. 11. 10., cs – 07:31 )

Ja, és még egy apróság: eddig ugye ppp-over-ssh vpn megoldást használtam.
A pppd vajon miért tudta létrehozni a route-ot mindkét vpn végponti ip címre? Ha pedig a pppd létre tudta hozni, akkor az openvpn miért nem? Hiszen az openvpn doksi szerint a bekonfigolt vpn működőképesség-ellenőrzésének első lépése a vpn végpontok pingelése!

( csiga | 2005. 11. 10., cs – 08:46 )

Hi

Szerintem itt tuti valami filterezéses error lesz.

Nekem ennyivel teljesen jól megy:

Szerver:

dev tun
ifconfig 10.100.0.1 10.100.0.2
secret /etc/openvpn/hem.key
proto udp
port 2100
user nobody
group nogroup
comp-lzo
verb 3

Kliens:

remote vpn.example.com
port 2100
proto udp
dev tun
tun-mtu 1500
ifconfig 10.100.0.2 10.100.0.1
mssfix 1400
secret /usr/private/openvpn-2.0/sbin/buttercup.key
ping 10
comp-lzo
verb 3

Mondjuk iptables van fenn rajtuk filterként, de ez nem kell, hogy jelentsen semmit.

Az a lényeg, hogy úgy csináltam, hogy készítettem mind két hoston:

- egy vpn nevü zónát;
- ezt az adott tun interface-hez rendeltem;
- aztán meg policynak acceptet határoztam meg neki;

Es ezek után mennie kell.

Próbáld meg teszt képpen lelőni egy kicsit a filteredet, vagy lődd le a ganyús szabályt, vagy engedj mindent egy pár pingig és kiderül a dolog.

A routingba meg nem kell semmi cucc.

Ennyivel mennie kell:

10.100.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
33.33.33.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 33.33.33.33 0.0.0.0 UG 0 0 0 eth0

buttercup:~# ping 10.100.1.2
PING 10.100.1.2 (10.100.1.2) 56(84) bytes of data.
64 bytes from 10.100.1.2: icmp_seq=1 ttl=64 time=116 ms

--- 10.100.1.2 ping statistics ---
2 packets transmitted, 1 received, 50% packet loss, time 1007ms
rtt min/avg/max/mdev = 116.975/116.975/116.975/0.000 ms
buttercup:~# ping 10.100.1.1
PING 10.100.1.1 (10.100.1.1) 56(84) bytes of data.
64 bytes from 10.100.1.1: icmp_seq=1 ttl=64 time=0.045 ms

--- 10.100.1.1 ping statistics ---

( gdavid v | 2005. 11. 10., cs – 10:43 )

nos nem tudom mit tud a freebsd. nekem 2 ubuntu breezy+debian sarge trio nyomul egyutt egy openvpn serververrel es gond nelkul fut.

mindossze egy erdekesseget tapasztaltam, mar ha ez annak szamit:
szerveren:
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.168.10.1 P-t-P:192.168.10.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:41853 errors:0 dropped:0 overruns:0 frame:0
TX packets:39948 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:3050712 (2.9 MiB) TX bytes:10972755 (10.4 MiB)
kliensen:
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.168.10.6 P-t-P:192.168.10.5 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:4892 errors:0 dropped:0 overruns:0 frame:0
TX packets:4558 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1898982 (1.8 MiB) TX bytes:549742 (536.8 KiB)

vagyis, a szerveren detektalt tun0 ipcim nem azonos a kliensen detektalt "szerverip"cimevel...

sot masik kliensen egeszen mas latszik...

viszont amikor csak 2 gepet kotottem ossze, (nem 3-at) akkor mindket oldalon ugyan az az ip cim latszott mindket (pl 192.168.10.1 a gep1 es 192.168.10.2 a gep2), de ennek a konfigja nagyon sokban eltert a kliens-szerver konfigtol...

( j_szucs | 2005. 11. 09., sze – 05:28 )

Az openvpn nagyon megszívatott: létrehoztam vele egy vpn linket két hálózat között, 10.4.0.1 és 10.4.0.2 vpn végponti ip címekkel. A két végponton a tun interfészek létre is jöttek, rendben meg is kapták az ip címüket.

Első lépésként megpróbáltam a vpn végpontokat pingelni. Egyik végpontról sem lehetett mind a kettőt pingelni :cry: .
Órákig kerestem a hiba okát, sőt az a gyanúm, hogy a hónapokkal ezelőtti első próbálkozásomkor ugyanitt akadtam el, és akkor napokat kínlódtam vele.

Aztán most rádöbbentem, hogy a vpn ettől még működik: minden ip címet bármelyik hálózaton lehet pingelni, csak éppen a helyi vpn végpont (tun interfész) ip címét nem.
Ilyen hülyeséget még nem láttam: ha a helyi vpn végpont (tun interfész) ip címét pingeled, akkor a csomagok egy másik interfészen (ed0) keresztül az internetre igyekeznének (már ha a tűzfal nem akasztaná meg őket). Mi a fene ennek az oka? Ennek így kell működnie? (Mindenesetre napokat töltöttem egy nem létező hiba keresésével ) :evil:

( Panther v | 2005. 11. 09., sze – 05:42 )

??????????????
[code:1:c61e748484]
zeratul ~ # ifconfig tap0
tap0 Link encap:Ethernet HWaddr ....
inet addr:10.1.0.2 Bcast:10.1.255.255 Mask:255.255.0.0
.....
zeratul ~ # ping 10.1.0.2
PING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.
64 bytes from 10.1.0.2: icmp_seq=1 ttl=64 time=0.065 ms

--- 10.1.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.065/0.065/0.065/0.000 ms
[/code:1:c61e748484]

( j_szucs | 2005. 11. 09., sze – 05:45 )

Vagyis nálad megy a dolog...
Akkor azt hiszem, mégiscsak utána kellene nézni, hogy itt miért nem. Mindjárt közlöm a részleteket.

( j_szucs | 2005. 11. 09., sze – 05:55 )

Ezzel a paranccsal hozom létre a linket:
openvpn --local 196.57.86.139 --remote 196.57.86.147 --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 --route 192.168.2.0 255.255.255.0 --comp-lzo --secret /usr/local/etc/openvpnkey

Itt az ifconfig kimenete ugyanezen a gépen:
[code:1:df4f390038]
ed0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet 196.57.86.139 netmask 0xfffffffc broadcast 196.57.86.140
ether 00:c0:0c:b0:35:47
tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1255
inet 10.4.0.2 --> 10.4.0.1 netmask 0xffffffff
Opened by PID 12285
[/code:1:df4f390038]
És itt a ping eredménye ugyanitt:
# ping 10.4.0.2
ping: sendto: Permission denied

A pingek ezen a tűzfal szabályon akadnak fenn:
00006 1890 158584 deny ip from any to 10.0.0.0/8 via ed0

Ha pedig ezt a tűzfal szabályt feloldom (azazhogy kifejezetten engedélyezem ezeket a csomagokat), akkor sincs válasz a pingre, mert ezek a csomagok tényleg az internetre mennek ki a privát ip címmel :(.

( gdavid v | 2005. 11. 09., sze – 09:07 )

route ???
nem lehet, hogy ehhez az ip cimhez nem jo route van beallitva?

( nc | 2005. 11. 09., sze – 09:21 )

Ja, a 10.4.0-ás hálózatot nem ártana betenni, a route konfigba :)
Ne szidd az OpenVPN-t neki semmi köze a te pingedhez.

( j_szucs | 2005. 11. 09., sze – 09:56 )

Route konfig? Itt egy helyi interfészről van szó!

Azt akarjátok mondani, hogy a FreeBSD kernel nem épít fel automatikusan route-ot a rendszerbe illesztett (helyi) interfészekhez? Ha ez így van akkor már megint tanultam valamit - de ebben erősen kételkedem.
Mellesleg: ha így is volna; akkor mivel magyarázható az, hogy a vpn link túlsó végét viszont alapból lehet pingelni?
Szóval: a vpn link helyi végét nem lehet pingelni, de a távolit igen?

Mellesleg az IP cím tartomány indifferens: hónapokkal ezelőtt a 192.168.228. tartománnyal jártam ugyanígy.