Fórumok
Sewastok!
Adott egy OpenVPN szerver és a hozzá kapcsolódó helyi hálózatot szeretném az internetrõl elérni. A kliens és a szerver között felépül a kapcsolat, tudom pingelni a szerver belsõ hálóra "nézõ" csatolóját, azonban a belsõ hálón lévõ gépeket már nem érem el.
A szerver beállításai:
local xx.xx.xx.xx
port xxxx
proto udp
dev tun
ca xxxx/ca.crt
cert xxxx/server.crt
dh xxxx/dh1024.pem
key xxxx/server.key
server 192.168.3.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.2.0 255.255.255.0"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
A szerveren Shorewall-lal állítottam be a tûzfalat, ahol felvettem a tun0-t, illetve beállítottam a vpn zónát és engedélyeztem a vpn zónából és a hozzá menõ kapcsolatokat, illetve kinyitottam az openvpn portokat.
Többféle bellítással is próbálkoztam már, de semmi eredmény.
Hozzászólások
Gondolom megfelelő IP-t adtál meg a VPN zónára és azt is hogy adott irányba átjöhetnek. A pontos tűzfal és routing szabályokat (kliens és szerver) meg tudod mutatni?
A policyben beállítottam azt, hogy a vpn felé érkező és a vpntől induló kapcsolatok átmehetnek (all vpn ACCEPT; vpn all ACCEPT), illetve a net és a tűzfal, a tűzfal és a helyi hálózat, valamint a helyi hálózat és a net között, illetve mindhárom esetben a másik irányba is kinyitottam az OpenVPN által használt portokat. A routing pedig:
Ehhez nem nyúltam, az OpenVPN indítása után lesznek a szabályok.
attol meg, hogy a belos labat pingelni tudod,ami default tobb halokartyas gep eseten, nat-ot is be kell allits a tartomanyok kozott
a
push "route ..."
mellett nezd meg a
route
es
iroute
parametereket is!
http://hup.hu/node/37366
Pórbálgattam többféle beállítást, de még mindig semmi. :( A pingelésre Request timeout-ot kapok. Észrevettem, hogy hiába adom meg az openvpn címtartománynak a 255.255.255.0-s maszkot, a kliens .252-t kap, a szerveren a tun0 pedig .255-re végződik. Ezen kívül a kliens gépen a virtuális hálózati csatoló nem kapja meg a default gateway címét (nem vagyok benne biztos, hogy ez probléma), de még mindig az a gyanúm, hogy a szerveren a route-olás nincs jól megoldva, és ezért nem tudok a szerver mögött lévő belső háón pingelni.
3 halozat lesz. egyik a szerver ethernet kapujan, masik a kliens ethernet kapujan (ha nincs mogotte halozat akkor nem szamit) es a harmadik a tun POINTOPOINT kapcsolata ahol azert kap /32 maskot mert P-t-P a kapcsolat, a szervernel azert kap /30 maskot mert 1 kapcsolathoz 4 ip cimre van szuksege, de jo hogy /24-et adsz meg mert innen fogja kivalasztani a 4 cimet. a kliens gep push "redirect-gateway"-re allitja at a default gateway-t a tun csatolora.
Köszönöm!
És mit állítottam be rosszul, vagy mi hiányzik ahhoz, hogy a csatlakozó kliens elérje a vpn szerver mögött lévő helyi hálózatot?
mivel nem tudok mindent ezert majd behelyettesited a helyes ertekeket :)
ha a szerver lokalis ethernet kapujanak (eth1) a cime pl. 192.168.2.1 (push "route 192.168.2.0 255.255.255.0"-bol gondolom valami ilyesmi lehet) akkor a szerver mogotti gepek default gateway-enek is ennek kell lenni, hogy a visszafele meno csomag jo iranyba induljon el. ha mar a szerverig visszajutott a csomag utana a tobbit elintezi. gondolom csak -o eth0 -ra illeszkedo csomagokat NAT-olsz - ha van NAT egyaltalan - , vagyis a -o tun0 -ra illeszkedo csomagok siman route-olodnak a tun0-n keresztul a kliens tun0 csatolojahoz. ha ez mind fennall, akkor mar csak a tuzfal szabalyok kozott kell engedelyezd a kovetkezoket:
iptables -A INPUT -i tun0 -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A OUTPUT -o tun0 -j ACCEPT
iptables -A OUTPUT -o eth1 -j ACCEPT
echo 1 >/proc/sys/net/ipv4/ip_forward
ha igy mukodik szigorithatod a szabalyokat.
ha nem mukodik kene egy tracepath a szerver mogotti gepre.
meg a tuzfal szabalyok:
iptables -t filter -L -v -n
iptables -t nat -L -v -n
iptables -t mangle -L -v -n
A szerver két fizikai csatolóval rendelkezik: eth0 (internet) és eth1 (belső háló), erre jön a tun0, mint virtuális csatoló. Az iptables-t shorewall-lal konfiguráltam és masquerade van az eth1 és eth0 között, mert osztva van a net a belső hálóra. Ha jól értem akkor az eth1 és tun0 között kellene NAT-ot létrehoznom. Átnéztem a shorewall doksiját és a fájlokat, de nem jöttem rá a megoldásra. Esetleg tudna vki segíteni a shorewall vpn-es beállításában? A vpn-es zóna és az összes többi között a kapcsolat engedélyezett mindkét irányba. Ezt már beállítottam. :)
a szerveren a tun0 kimeno csomagokra nem kell NAT, mivel route-olod! a shorewall-t nem ismerem, de ha az altalam leirt parancsokkal kilistazod az iptables szabalyokat, akkor meg lehet nezni hogy jok-e. valamint az ip_forward-nak is 1-nek kell lennie.
Az ip_forward az 1, már csak a netmegosztás miatt is. :)
iptables -t filter -L -v -n
iptables -t nat -L -v -n
iptables -t mangle -L -v -n
csak atfutottam mert most nincs idom es ezt talaltam:
most ez van, igy minden csomagot a 192.168.2.0/24-es halozatbol NAT-ol de ez nem jo
Chain eth0_masq (1 references)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * * 192.168.2.0/24 0.0.0.0/0 policy match dir out pol none
ez kellene, igy csak azokat a csomagokat NAT-olja amik a 192.168.2.0/24-es halozatbol ES az eth0-n akarnak kimenni az internet fele
Chain eth0_masq (1 references)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * eth0 192.168.2.0/24 0.0.0.0/0 policy match dir out pol none
(...) 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. (...)
lásd: http://openvpn.net/howto.html#scope
Már próbáltam, de semmi. Az elérendő alhálózat nem a csatlakoz kliens mögött van, hanem a szerver mögött.
Probléma megoldva! NAT volt a gond. Mindenkinek köszönöm a segítséget!
Hali.
Kifejtenéd bővebben? Szórúl-szóra ez a jelenség áll fent nálam is. Már az őrületbe kerget lassan.
--
Nem az erős, aki sosem esik el, hanem az, aki mindig fel tud állni!
Az volt a helyzet, hogy az OpenVPN szerverkent funkcionalo gep a vpn felol erkezo csomagokat bekuldte a helyi halozatra, forras IP-kent pedig a vpn-es forras maradt a csomagban - helyesen. A helyi halon levo celgep viszont nem tudta, hogy ezt a csomagot merre kuldje vissza. Ket lehetoseg van: NAT-olsz a vpn szerveren, vagy a helyi halon megadod a gepek route tablajaban, hogy a vpn-es halozatot merre talaljak.
Tipp:
Spoof protection (reverse-path filter) volt a dolog oka.
Vagyis a belso halozat kap egy kerest egy szamara ismeretlen privat ip cimrol, es eldobja, ahelyett, hogy a default route fele valaszolna.
Ha a spoof protection-t kikapcsolod (vagy ismert subnet-kent feltunteted a vpn tulso veget), vagy nat-olod a vpn tulvegen levo gepet a belso halo fele, megoldodik.
Remek..
Mostmár minden gépet tudok pingelni IP alapján, de van egy samba szerver, és 1 db domain. Legyen ez az "SMB" nevű. Minden egyes gépet megtudok pingelni _ip_ alapján, de se az SMB munkacsoportot nem tudom böngészni, se név alapján nem tudom pingelni egyik gépet sem. Ha a samba megosztást IP alapján akarom elérni, gond nélkül megy. Tehát akkor iptables-el nem lehet gubanc. Mi lehet a gond? Neharagudjatok ha számotokra lámer a kérdés, de hidjétek el, nem ide rohantam először kérdezni, volt google barát 2 napon át.
Köszi előre is.
--
Nem az erős, aki sosem esik el, hanem az, aki mindig fel tud állni!
Nem fog menni, hacsak nem csinálsz a Samba szerverből WINS szervert is egyben, és be is állítod klienseken. Ugyanis Te TUN-t használsz, ami egy TCP/IP alapú megoldás, route-olással. Csak az IP alapú protokolok működnek: broadcast nem --->> NetBios.
VAGY
Ha nem a TCP/IP (layer 7??!!) szintjén akarod a VPN-t, hanem layer 2-3 szinten, ami protokoltol függetlenül továbbítja az Ethernet csomagokat akkor TAP-ot és ethernet bridge-t kell használjál.
http://openvpn.net/index.php/documentation/howto.html#vpntype
http://openvpn.net/index.php/documentation/miscellaneous/ethernet-bridg…
Attila, Perger
-----------------------------------------------------
"Az a szoftver, amelyiket nem fejlesztik, az halott!"
Basszus.. Szerinted innen melyiket egyszerűbb megoldani, ill. te melyiket csinálnád?
--
Nem az erős, aki sosem esik el, hanem az, aki mindig fel tud állni!
Ahol most te tartasz az a WINS bevezetését indokolja... nem túl nehéz hozzáadni a Samba konfigurációjához a WINS server sort :-)
4-5 gépen beállítod a kliens dolgokat és teszteled. Ha megy nyertél, bár nem tudom hány gépen kell ezt végigjátszani, hogy mindenhol be legyen állítva. Én "ethernet-bridge"-dzsel kezdtem :-)
Többször is írtam róla itt.
Attila, Perger
-----------------------------------------------------
"Az a szoftver, amelyiket nem fejlesztik, az halott!"
Hát...
[global]
wins support = yes
name resolve order = wins lmhosts hosts bcast
Ez bekerült a smb.conf-ba, a kliensnek pedig beírtam kézzel a samba szerver ip címét, és nem megy. Ennyi lenne az összes dolog amit tennem kéne?
tcpdump ezt mutatja mióta beállítottam a winst, amikor megpróbálok pingelni:
16:31:12.309730 00:0c:29:ab:38:32 > 00:1b:11:49:a2:71, ethertype IPv4 (0x0800), length 92: 10.8.0.4.137 > 192.168.2.1.137: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
16:31:12.309988 00:1b:11:49:a2:71 > 00:0c:29:ab:38:32, ethertype IPv4 (0x0800), length 98: 192.168.2.1.137 > 10.8.0.4.137: NBT UDP PACKET(137): QUERY; NEGATIVE; RESPONSE; UNICAST
--
Nem az erős, aki sosem esik el, hanem az, aki mindig fel tud állni!
Mondjuk ez a leírás nem mondja azt, hogy ne működne a gépek beolvasása, sőtt..
http://wiki.hup.hu/index.php/Az_OpenVPN_finomhangol%C3%A1sa
--
Nem az erős, aki sosem esik el, hanem az, aki mindig fel tud állni!
Ha linux alól próbálod, akkor a "ping" parancs a DNS szerverrel oldja fel a nevet. Gondolom a használt DNS szerver nem a helyi háló DHCP-vel összekötött dinamikus bejegyzésű megvalósítása, mert akkor eddig is működött volna.
Engem jobban érdekelne egy következő parancshoz hasonló eredménye
(Ez itthonról készült:
Ati01----vpn_ethernet_bridge---->>Iroda1<<---vpn_ethernet_bridge---->>Iroda2---BARENSRVG (egy gép a hálon a VPN-t a Linuxok csinálják):
Ha ez szerver nevét visszadja az már jó jel... és sorban a kliensekét is.
A Samba ugyanis a WINS szervertől kéri a névfeloldást és nem a DNS szervertől, épp ezt állítottad be.
Windows alatt a NetBios engedélyezése a TCP/IP feletti beállítás segíthet!
Attila, Perger
-----------------------------------------------------
"Az a szoftver, amelyiket nem fejlesztik, az halott!"
Sziasztok!
Én is routolással küzdök. Valószínűleg nálam is a NATolással lesz a gond.
Adott egy szerver, egy fizikai csatolóval (eth0), router mögött. Ehhez szeretnék otthonról OpenVPN-en keresztül csatlakozni úgy, hogy lássam a szerveren lévő Samba megosztás és tudjak internetezni a szerveren keresztül.
A Sambát látom. Viszont a routert már pingelni se tudom és a DNS-eket se oldja fel.
Ami még érdekes, hogy a Win7 nem kapja meg az alapértelmezett átjáró címét, egyszerűen üres marad.
Részlet az OpenVPN server.conf-ból:
proto udp
dev tun
server 10.8.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 84.2.44.1"
push "dhcp-option DNS 84.2.46.1"
client-to-client
Csak a fentebb írt iptables szabályokat állítottam be.
root@intermedius-server:/home/gyengus# iptables -t filter -L -v -n
Chain INPUT (policy ACCEPT 16 packets, 800 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
2772 310K ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- tun0 eth0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- eth0 tun0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 16 packets, 800 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * tun0 0.0.0.0/0 0.0.0.0/0
623 162K ACCEPT all -- * eth0 0.0.0.0/0 0.0.0.0/0
root@intermedius-server:/home/gyengus# iptables -t nat -L -v -n
Chain PREROUTING (policy ACCEPT 92 packets, 12738 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 54 packets, 4364 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * eth0 10.8.0.0/24 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 54 packets, 4364 bytes)
pkts bytes target prot opt in out source destination
root@intermedius-server:/home/gyengus# iptables -t mangle -L -v -n
Chain PREROUTING (policy ACCEPT 3662 packets, 401K bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 3662 packets, 401K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 1702 packets, 620K bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 1712 packets, 621K bytes)
pkts bytes target prot opt in out source destination
MODding | Asztali PC | Személyes weboldalam
'Everybody loves LEDs'
Közben megoldódott.
MODding | Asztali PC | Személyes weboldalam
'Everybody loves LEDs'