Добрый день.
Настраивал vpn для связи рабочих станций с облаком, теперь появилась необходимость связать часть офисной сети с облаком.
Все рабочие станции работают как того и надо, проблема появилась со связностью между сетями в облаке и офисе.
В качестве vpn gateway на обоих сторонах ubuntu 18.04
конфиг сервера openvpn
server 10.8.0.0 255.255.255.0
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
route 10.1.3.0 255.255.255.0 10.8.0.100
client-config-dir /etc/openvpn/ccd
topology subnet
keepalive 10 120
tls-auth ta.key 0
key-direction 0
cipher AES-256-CBC
auth SHA256
user nobody
group nogroup
persist-key
persist-tun
crl-verify crl.pem
explicit-exit-notify 0
verb 3
конфиг клиента:
client
dev tun
proto tcp
remote 89.208.*.* 443
nobind
user nobody
group nogroup
persist-key
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
tls-auth ta.key 1
key-direction 1
cipher AES-256-CBC
auth SHA256
verb 3
ccd файл клиента:
push «route 10.150.150.0 255.255.255.0 10.8.0.1»
push «route 10.150.151.0 255.255.255.0 10.8.0.1»
iroute 10.1.3.0 255.255.255.0
ifconfig-push 10.8.0.100 255.255.255.0
ifconfig сервера:
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.150.151.10 netmask 255.255.255.0 broadcast 10.150.151.255
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.8.0.1 netmask 255.255.255.0 destination 10.8.0.1
ifconfig клиента:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.1.3.22 netmask 255.255.255.0 broadcast 10.1.3.255
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.8.0.100 netmask 255.255.255.0 destination
10.8.0.100
ip route сервера:
default via 10.150.151.1 dev ens3 proto dhcp src 10.150.151.10 metric 100
10.1.3.0/24 via 10.8.0.100 dev tun0
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
10.149.149.0/24 via 10.150.151.5 dev ens3 proto dhcp src 10.150.151.10 metric 100
10.150.151.0/24 dev ens3 proto kernel scope link src 10.150.151.10
169.254.169.254 via 10.150.151.1 dev ens3 proto dhcp src 10.150.151.10 metric 100
ip route клиента:
default via 10.1.3.24 dev eth0 proto static
10.1.3.0/24 dev eth0 proto kernel scope link src 10.1.3.22
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.100
10.150.150.0/24 via 10.8.0.1 dev tun0
10.150.151.0/24 via 10.8.0.1 dev tun0
ip forwarding включен на обоих сторонах
для простоты пока выставил DEFAULT_FORWARD_POLICY в accept
так же на сервере настроен nat для тех клиентов, которые подключаются с рабочих станций и у которых все в порядке
iptables -t nat -v -L POSTROUTING -n --line-number
Chain POSTROUTING
num pkts bytes target prot opt in out source destination
2679 165K 128 MASQUERADE all — * ens3 10.8.0.0/24 0.0.0.0/0
Собственно проблема - не пингуется eht0 интерфейс(10.1.3.22) с соурса ens3(10.150.150.11), хотя маршруты на обоих сторонах вроде как есть
В обратную сторону точно такая же история
tcpdump 10.1.3.22 -> 10.150.151.11
на сервере:
tcpdump -i ens3 icmp - есть request/reply
12:42:56.574554 IP 10.150.150.14 > 10.1.3.22: ICMP echo request, id 522, seq 10997, length 64
12:42:56.606841 IP 10.1.3.22 > 10.150.150.14: ICMP echo reply, id 522, seq 10997, length 64
на клиенте:
tcpdump -i eth0 icmp - только request
12:45:31.736261 IP prmvpndev > 10.150.151.10: ICMP echo request, id 60726, seq 368, length 64
12:45:32.760272 IP prmvpndev > 10.150.151.10: ICMP echo request, id 60726, seq 369, length 64
на клиенте:
tcpdump -i tun0 icmp - на tun интерфейсе есть и request и reply
12:46:53.133397 IP 10.150.150.14 > prmvpndev: ICMP echo request, id 522, seq 11228, length 64
12:46:53.133442 IP prmvpndev > 10.150.150.14: ICMP echo reply, id 522, seq 11228, length 64
при пингах в другую сторону точно такая же ситуация
Получается, что пакеты возвращаются обратно на клиент и там уже дропаются?
Есть у кого идеи почему так и как поправить?