OpenVPN nie działa na innym porcie


1

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

2
Czy masz włączony selinux na serwerze Linux? Może to powodować awarie. Spróbuj uruchomić sudo setenforce permissive tymczasowo i sprawdź, czy problem zniknie. Możesz biegać sudo semanage port --list | grep 500 sprawdzić, 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.
Argonauts

W rzeczywistości to działa (np. 5001). Jednak powodem, dla którego chcę 500, jest to, że jest on używany przez IPSec, a zatem prawdopodobnie nie jest blokowany przez restrykcyjny IPS. Nie mam zainstalowanego SELinux. Argument uprawnień jest również nieprawdziwy: zostawiam wszystko na serwerze (tj. Port 5001), po prostu zamień klienta na 500 i zmień moją zaporę sieciową z 500 na 5001 (zamiast 5001 na 5001). Problem pojawia się ponownie.
divB

W porządku, to prowadzi do rozwiązania: zmiana klienta na 501 (i router) na 501 prac. netstat -a -n -o na 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?
divB

1
Właśnie na to patrzyłem; Windows rezerwuje port 500 udp dla „IPsec Internet Security Association i Key Management Protocol (ISAKMP) (port UDP 500)”. Wyjaśnienie jest tutaj support.microsoft.com/en-us/kb/83201
Argonauts

Jeśli chodzi o powód, zgaduję, że to nie system Windows blokujący openvpn przed pobieraniem portu na podstawie twoich symptomów, ale albo odbierający port po pewnym czasie, albo odbierające pakiety openvpn przeznaczone dla IPSec, i wszystko znika z szyn.
Argonauts
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.