Mam konfigurację OpenVPN z serwerem linux i klientem Windows na serwerze trybów z kranem i przez UDP. Wszystko działa z portem 1194. Ale chcę zmienić port 500.
Na mojej zaporze przekazuję port 500 UDP do odpowiedniego routera. Aby udowodnić, że moja konfiguracja sieci jest poprawna, używam na serwerze: nc -l -u -p 500 i na kliencie echo hello | nc -u server 500.
Rzeczywiście, na serwerze:
nc -l -u -p 500
hello
Teraz dodam port 500 linie do konfiguracji klienta i serwera i nagle klient pretenduje, że nie można do niego dotrzeć (powinienem sprawdzić łączność sieciową):
Mon Apr 25 19:21:37 2016 UDPv4 link local (bound): [undef]
Mon Apr 25 19:21:37 2016 UDPv4 link remote: [AF_INET]server:500
Mon Apr 25 19:22:37 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Apr 25 19:22:37 2016 TLS Error: TLS handshake failed
Ale to głupie, poza tym, że UDP ponad 500 działa doskonale z netcat, również serwer widzi żądanie połączenia, ale nie działa:
Apr 26 04:56:49 radix ovpn-server[465865]: client:44294 LZO compression initialized
Apr 26 04:56:49 radix ovpn-server[465865]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Apr 26 04:56:52 radix ovpn-server[465865]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Apr 26 04:56:55 radix ovpn-server[465865]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Apr 26 04:56:55 radix ovpn-server[465865]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Apr 26 04:57:03 radix ovpn-server[465865]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Apr 26 04:57:19 radix ovpn-server[465865]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Myślę, że mogę wykluczyć wszelkie problemy związane z siecią. Należy również pamiętać, że połączenie działało doskonale, ale w pewnym losowym momencie zaczęło zawieść.
Jako odniesienie dodam moje pliki konfiguracyjne:
klient:
client
remote server
rport 500
proto udp
resolv-retry infinite
dev tap
dev-node "OpenVPN"
tap-sleep 3
ca ca.crt
cert client1.crt
key client1.key
comp-lzo
comp-noadapt
ns-cert-type server
mute 5
verb 2
serwer:
mode server
tls-server
keepalive 5 30
local 192.168.200.1
proto udp
port 500
persist-key
user nobody
group nogroup
dev tap0
ca "/etc/openvpn/ca.crt"
cert "/etc/openvpn/server.crt"
key "/etc/openvpn/server.key"
dh "/etc/openvpn/dh1024.pem"
mute-replay-warnings
client-to-client
comp-lzo
comp-noadapt
sudo setenforce permissivetymczasowo i sprawdź, czy problem zniknie. Możesz biegaćsudo semanage port --list | grep 500sprawdzić, czy selinux zarządza tym portem. Jeśli selinux nie jest w to zaangażowany, może to być związane z dostępem roota do korzystania z portów poniżej 1024 w systemie Linux. Możliwe, że jakiś składnik openvpn działa pod regularnymi uprawnieniami użytkowników i jest blokowany - spróbuj użyć dowolnego portu powyżej 1024 z openvpn i sprawdź, czy to działa.netstat -a -n -ona Windows pokazuje, że svchost.exe nasłuchuje na UDP 0.0.0.0:500. Jest to usługa IKEEXT (IKE i AuthIP IPsec Keying Modules). W porządku, moje pytanie: DLACZEGO to miałoby znaczenie? I dlaczego połączenie z netcat działa bez żadnych problemów?