DD-WRT + OpenVPN

lőtt már be valaki ilyet?

windowsos kliens itt akad el:
Wed Jul 27 19:53:00 2011 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Jul 27 19:53:00 2011 TLS Error: TLS handshake failed
Wed Jul 27 19:53:00 2011 SIGUSR1[soft,tls-error] received, process restarting
Wed Jul 27 19:53:02 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Wed Jul 27 19:53:02 2011 Re-using SSL/TLS context

én meg perpill azt sem tudom mi fán terem a VPN

Hozzászólások

Configokat mutatsz?
Kulcsok létrehozási dátuma nem a jövőbe mutat? ( volt már hogy előbbre volt állítva az óra azon a gépen amelyiken a kulcsot készítettem, a másik gépen pedig nem működött és csak pislogtam, hogy wtf )

Itt a Router OpenVPN Config részben van 2 ip, amire nem igazán értettem, hogy mire valók.

-----------------------
Router OpenVPN Config
-----------------------
push "route 192.168.1.1 255.255.255.0"
server 192.168.66.0 255.255.255.0

dev tun0
proto udp
keepalive 10 120
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem

# Only use crl-verify if you are using the revoke list - otherwise leave it commented out
# crl-verify /tmp/openvpn/ca.crl

# management parameter allows DD-WRT\s OpenVPN Status web page to access the server\s management port
# port must be 5001 for scripts embedded in firmware to work
management localhost 5001

-----------------------
Windows OpenVPN config
-----------------------

remote xyz.no-ip.org 1194

client
remote-cert-tls server
dev tun0
proto udp
resolv-retry infinite
nobind
persist-key
persist-tun
float

#If the pushed routes appear not to be added on windows hosts, add the following:
route-delay 30

ca "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\client2.crt"
key "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\client2.key"

---------------
router itables
---------------
iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT

iptables -I FORWARD 1 --source 192.168.66.0/24 -j ACCEPT

# These next two lines may or may not be necessary.
# I (dereks) did not need them, but bmatthewshea did.
# Thus, we include them so that this works for more people:
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT

s/remote-cert-tls server/ns-cert-type server/

Azt az opciót az enyémben nem használom és így működik.

A push "route 192.168.1.1 255.255.255.0" opcióval mondod meg, hogy a belső hálód átrouteold a tunnelre. Windowsul így lehet érteni: "ROUTE ADD 192.168.1.0 MASK 255.255.255.0 VPN.SERVER.IP.MINT.GATEWAY" Itt mondjuk nem tudom miért az 192.168.1.1 van az 192.168.1.0 helyett.

"server 192.168.66.0 255.255.255.0" Ez a VPN subnet. Azaz nem egészen, mivel alapból P2P-t épít ki. Én még beleírnám a server configba hogy: topology subnet
A VPN szerver az első IP-t fogja a topology subnet módban adni magának: 192.168.66.1

http://openvpn.net/index.php/open-source/documentation/manuals/69-openv…

---

Update:

Nálad:
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem

Nálam:
ca ca.crt
cert client.crt
key client.key
dh dh384.pem

Kiterjesztést furcsállom. Alapból úgy generálnak a build* scriptek, ahogy írtam. Bár ez csak formaiság, ha a kulcs valójában jó, tökmindegy mi a fájlneve.

végülis 192.168.1.1 vagy 192.168.1.0? Ez az alapértelmezett átjáró? mert az 1.1

push "route 192.168.1.0 255.255.255.0"
server 192.168.66.0 255.255.255.0

dev tun0
proto udp
keepalive 10 120

#dh /tmp/openvpn/dh.pem
#ca /tmp/openvpn/ca.crt
#cert /tmp/openvpn/cert.pem
#key /tmp/openvpn/key.pem
ca ca.crt
cert client.crt
key client.key
dh dh384.pem

# Only use crl-verify if you are using the revoke list - otherwise leave it commented out
# crl-verify /tmp/openvpn/ca.crl

# management parameter allows DD-WRT\s OpenVPN Status web page to access the server\s management port
# port must be 5001 for scripts embedded in firmware to work
management localhost 5001

-------------------------

remote barii.no-ip.org 1194 # vagy fix ip-t is megadhatsz, ha van

client
#remote-cert-tls server
ns-cert-type server
dev tun0
proto udp
resolv-retry infinite
nobind
persist-key
persist-tun
float

#If the pushed routes appear not to be added on windows hosts, add the following:
route-delay 30

ca "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\ca.crt" # az elérési utat
cert "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\client2.crt" # helyesen add meg
key "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\client2.key"

--------------------------

Wed Jul 27 22:48:56 2011 OpenVPN 2.1.1 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Dec 11 2009
Wed Jul 27 22:48:56 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Wed Jul 27 22:48:57 2011 UDPv4 link local: [undef]
Wed Jul 27 22:48:57 2011 UDPv4 link remote: ***.***.***.***:1194
Wed Jul 27 22:49:57 2011 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Jul 27 22:49:57 2011 TLS Error: TLS handshake failed
Wed Jul 27 22:49:57 2011 SIGUSR1[soft,tls-error] received, process restarting
Wed Jul 27 22:49:59 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Wed Jul 27 22:49:59 2011 Re-using SSL/TLS context
Wed Jul 27 22:49:59 2011 UDPv4 link local: [undef]
Wed Jul 27 22:49:59 2011 UDPv4 link remote: ***.***.***.***:1194

Ellenőrizd a routerre felmásolt tanúsítványt nincs-e levágva a vége. Régebben volt ilyen hiba.
Olvasgasd az openvpn.net doksijait, hogy többet tudj róla.

Linuxscripting

Az eredeti DD-WRT elkövetője is, ráadásul valami ügyfelüknek - olyannyira, hogy a kódba bedrótozva ott maradt (a kód átdolgozását túlélve) néhány iptables szabály is. (Jópár éve volt, de azóta a ddwrt nálam nem játszik).

TCP vagy UDP alapokon megy? Azért kérdem, mert a log szerint a hálózati kapcsolattal val probléma, az openvpn alapból UDP-t szeret,az meg ugye stateless protokoll, azaz nem fog elfeküdni a kapcsolat nyitás, kezdő csomag küldés akkor sem, ha egyébként a túloldal nem elérhető. Innen kezdve a kapcsolat ugyan nem fog létre jönni, de az ovpn nem a kapcsolódásra fog szólni, hogy probléma van, mert azt nem tudja ellenőrizni - hanem arra, hogy a titkosított kapcsolat létrehozása az első fázisban padlót fogott.