Назад | Перейти на главную страницу

Невозможно подключиться к серверу OpenVPN с устройств, находящихся в той же сети, что и сервер VPN

У меня есть открытый VPN-сервер, к которому я могу подключиться с устройств из Интернета, но я не могу подключиться к VPN-серверу с устройств, находящихся в той же сети, к которой подключен другой конец VPN-сервера.

Надеюсь, следующая картинка дает более ясное представление о том, что я имею в виду.

Сетевое изображение

Таким образом, с портативного компьютера A VPN работает отлично без каких-либо проблем, но с портативного компьютера B соединение VPN не работает, но единственное, что я вижу в журналах на стороне сервера:

Sat Jul 16 13:01:25 2016 192.168.8.110:54838 TLS: Initial packet from [AF_INET]192.168.8.110:54838, sid=df0e4ebd 28b00efc
Sat Jul 16 13:02:26 2016 192.168.8.110:54838 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Jul 16 13:02:26 2016 192.168.8.110:54838 TLS Error: TLS handshake failed
Sat Jul 16 13:02:26 2016 192.168.8.110:54838 SIGUSR1[soft,tls-error] received, client-instance restarting

По моим собственным оценкам, в моих iptables есть что-то, что мне нужно настроить, но я не уверен, что именно.

iptables-save вывод "Router & VPN server":

# Generated by iptables-save v1.4.21 on Sat Jul 16 15:50:52 2016
*nat
:PREROUTING ACCEPT [30:5047]
:INPUT ACCEPT [8:564]
:OUTPUT ACCEPT [277:46054]
:POSTROUTING ACCEPT [166:38786]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Sat Jul 16 15:50:52 2016
# Generated by iptables-save v1.4.21 on Sat Jul 16 15:50:52 2016
*filter
:INPUT DROP [353:82150]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1338:193477]
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
COMMIT
# Completed on Sat Jul 16 15:50:52 2016

eth0 подключен к локальной сети A, а eth1 - к локальной сети B

Конфигурация сервера openvpn:

dev tun 
proto udp
port 1194 
ca   /etc/openvpn/easy-rsa/keys/ca.crt 
cert /etc/openvpn/easy-rsa/keys/vpn.crt
key  /etc/openvpn/easy-rsa/keys/vpn.key
dh   /etc/openvpn/easy-rsa/keys/dh2048.pem
server 10.9.0.0 255.255.255.0 

# Allow traffic between clients
client-to-client 
keepalive 10 120 
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0 
cipher AES-128-CBC 
comp-lzo 
user nobody 
group nogroup 
persist-key 
persist-tun 
status /var/log/openvpn-status.log 20 
log /var/log/openvpn.log 
verb 3
topology subnet

# Makes openvpn server to advertise this network to other clients
push "route 192.168.43.0 255.255.255.0"

Также на сервере установлен net.ipv4.ip_forward = 1.

route -n вывод сервера

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.8.1     0.0.0.0         UG    202    0        0 eth0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.8.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
192.168.43.0    0.0.0.0         255.255.255.0   U     203    0        0 eth1

Конфигурация клиента для ноутбука B: ПРИМЕЧАНИЕ. Эта конфигурация аналогична той, что я использую для портативного компьютера. Единственное отличие - удаленная линия для портативного компьютера A (общедоступный IP-адрес).

client
dev tun
proto udp
remote 192.168.8.2 1194
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ns-cert-type server
key-direction 1 
cipher AES-128-CBC
comp-lzo
verb 1
#mute 20
auth-nocache 0
<ca>...</ca>
<cert>...</cert>
<key>...</key>
<tls-auth>...</tls-auth>

Я думаю, ваша проблема связана с правилом NAT POSTROUTING. ЛЮБОЙ пакет покидает eth0 интерфейс подлежит MASQUERADEдаже пакеты, исходящие от вашего сервера OVPN.

Проблема связана с тем, что ваш клиент OVPN подключается к серверу OVPN на udp/1194, и из-за MASQUERADE Правило, сервер OVPN отправляет свои ответы с другого порта, которого не ожидает клиент OVPN, отсюда таймаут.

Если это правило разрешает доступ из локальной сети B к локальной сети A, возможно, вы исправите следующую модификацию:

-A POSTROUTING -s <LAN B subnet> -o eth0 -j MASQUERADE

Надеюсь это поможет.