LINUX.ORG.RU
ФорумAdmin

openvpn, nat и маршрутизация

 , ,


0

1

Добрый день.

Настраивал 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

при пингах в другую сторону точно такая же ситуация
Получается, что пакеты возвращаются обратно на клиент и там уже дропаются?
Есть у кого идеи почему так и как поправить?

1. На всякий случай уточню, на сервере на вижу ничего про сеть 10.150.150.0 или она за defgw ?
2. Что такое prmvpndev ? Запускайте ping с ключиком -n а то вам может и понятно а нам нет.
3. Ну вроде как пакет улетел пакет прилетел

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
Где проблема?

anc ★★★★★ ()
Ответ на: комментарий от anc

1 - да, она за дефолтом

2 - это хостнейм клиента, пардон, забыл про ключ

3 - проблема вот:
пинг source ens3 на сервере, destination eth0 на клиенте
ping -n -I ens3 10.1.3.22
PING 10.1.3.22 (10.1.3.22) from 10.150.151.10 ens3: 56(84) bytes of data.
--- 10.1.3.22 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4080ms

пинг source tun0 на сервере, destination eth0 на клиенте
ping -n -I tun0 10.1.3.22
PING 10.1.3.22 (10.1.3.22) from 10.8.0.1 tun0: 56(84) bytes of data.
--- 10.1.3.22 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 32.584/33.303/34.022/0.719 ms

и в обратную сторону такая же ситуация
притом:
маршрут до ip eth0 интерфейса клиента на сервере
ip route get 10.1.3.22
10.1.3.22 via 10.8.0.100 dev tun0 src 10.8.0.1 uid 1001

маршрут до ip ens3 интерфейса сервера на сервере
ip route get 10.150.151.10
10.150.151.10 via 10.8.0.1 dev tun0 src 10.8.0.100 uid 1001

mpegushin ()
Ответ на: комментарий от mpegushin

опечатался в последней выкладке
правильно так:
маршрут до ip ens3 интерфейса сервера на клиенте
ip route get 10.150.151.10
10.150.151.10 via 10.8.0.1 dev tun0 src 10.8.0.100 uid 1001

mpegushin ()
Ответ на: комментарий от anc

Спасибо, думал подставляется ip интерфейса!

Пинги с сервера ни клиент пошли, обратно тоже

Но не ходят пинги с машин в подсетях 10.150.151.0/24 и 10.1.3.0/24

например с сервера 10.150.151.8(находится в подсети openvpn сервера) до openvpn клиента 10.1.3.22 или до другой машины в этой подсети 10.1.3.21

ip route на 10.150.151.8
ip route
default via 10.150.151.1 dev ens3 proto dhcp src 10.150.151.8 metric 100
10.1.3.0/24 via 10.150.151.10 dev ens3
10.149.149.0/24 via 10.150.151.5 dev ens3 proto dhcp src 10.150.151.8 metric 100
10.150.151.0/24 dev ens3 proto kernel scope link src 10.150.151.8
169.254.169.254 via 10.150.151.1 dev ens3 proto dhcp src 10.150.151.8 metric 100

опять же ip route на openvpn клиенте(10.1.3.22):
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

tcpdump на openvpn сервере(10.150.151.10) - реквесты и реплаи

sudo tcpdump -i ens3 icmp
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
21:38:08.979401 IP 10.150.151.8 > 10.1.3.22: ICMP echo request, id 1641, seq 9, length 64
21:38:09.013041 IP 10.1.3.22 > 10.150.151.8: ICMP echo reply, id 1641, seq 9, length 64
21:38:10.003313 IP 10.150.151.8 > 10.1.3.22: ICMP echo request, id 1641, seq 10, length 64
21:38:10.037907 IP 10.1.3.22 > 10.150.151.8: ICMP echo reply, id 1641, seq 10, length 64
21:38:11.027577 IP 10.150.151.8 > 10.1.3.22: ICMP echo request, id 1641, seq 11, length 64
21:38:11.065679 IP 10.1.3.22 > 10.150.151.8: ICMP echo reply, id 1641, seq 11, length 64

не могу понять, если пакеты роутятся в тоннель, реплай тоже роутится в тоннель, даже виден на локальном ens3 интерфейсе openvpn сервера, то где они теряются?

фаервол на 10.150.151.8 на время тестов выключил, находится эта машина в той же подсети, что и openvpn сервер

mpegushin ()
Ответ на: комментарий от anc

Выключил в sysctl.conf на обоих серваках, где openvpn, но там ассиметричной маршрутизации нет, балансировщиков тоже нет
К сожалению не помогло
sysctl -a | grep net.ipv4.conf.all.rp_filter
net.ipv4.conf.all.rp_filter = 0

Попробую поискать статистику по дропам пакетов, может это сможет прояснить немного

mpegushin ()
Ответ на: комментарий от mpegushin

Ну ещё смотреть на каждой точке что с fw. Пока другого в голову не приходит.
PS Вы показали только all.rp_filter = 0 а на самих интерфейсах не включен ли? Все посмотрели? Грепните по rp_filter

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 2)
Ответ на: комментарий от mpegushin

ip tables правила для openvpn сервера и клиента

А покультурнее выложить нельзя? Это не наезд, но вы бы ещё на какой-нибудь маилсру или тындыксдиск выложили. Качать не буду.

Далее, как я предлагал проверяйте на всех точках. От первой до последней. Что бы понять на какой именно дропается. Не эфемерно догадываться, а вот например точно с узла «клиент ovpn» не улетает/прилетает пакет с такого-то интерфейса.

И все-таки хоть и удалил свой комментарий, думаю дело не в этом, но надо повторить, там не винда на оконечных точках?

anc ★★★★★ ()
Ответ на: комментарий от anc

Извините, тут подойдет?

iptables -L -v -n для openvpn сервера:
https://pastebin.com/RrcWrj0k

iptables -L -v -n для openvpn клиента:
https://pastebin.com/0UjQEV9z

Нет, 2 ubuntu серевера, один в режиме клиента, другой в режиме сервера, тоннель поднимается, друг друга с локальных интерфейсов пингуют, но другая машина(тоже не виндовая) в локальной подсети одного из ендпоинтов не пингует ендпоинт на другом конце

Смог в итоге локализовать проблему, пакеты теряются между openvpn сервером и сервером 10.150.151.8, пока правда не успел разобраться почему

mpegushin ()
Ответ на: комментарий от mpegushin

Смог в итоге локализовать проблему, пакеты теряются между openvpn сервером и сервером 10.150.151.8, пока правда не успел разобраться почему

Я правильно понял «ICMP echo reply» с сервера 10.150.151.10 с интерфейса ens3 улетают, но на 10.150.151.8 их уже не видно?

anc ★★★★★ ()
Ответ на: комментарий от anc

Если tcpdump захватывает пакеты уже после всех правил фаервола - то да

На 10.150.151.8 фаервол отключен, а они в одной подсети
Так что либо проблема с дропом исходящих пакетов на 10.150.151.10, либо что-то у хостера, ему уже тоже отписал, чтобы дамп снял

mpegushin ()
Ответ на: комментарий от mpegushin

Ну облако оно понятие размытое. :) Хотя честно говоря эту часть я потерял(точнее не учел, что это хостинг) в процессе обсуждения. Вы более детально все стали выкладывать, а с учетом, что там ещё за defgw подсетка представилось уже полностью подконтрольные себе сетки.
Извините, думал что всё своё и на «левые» варианты не подумал. :( Надо быть внимательней на будущее.
ЗЫ Хотя конечно почему icmp reply не проходит, достаточно интересно. Как сделать такое я знаю, зачем не знаю.

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

Ответили, действительно была проблема со стороны хостера

Может кому будет полезно: «Вероятно эта проблема связана с работой функции безопасности “allowed-address pairs“, не разрешающей восходящий трафик на порту виртуальной машины с IP-адресов, отличных от тех, которые ей назначены. В данный момент настройка этой функции возможна только с помощью Openstack API. Для проверки мы разрешили восходящий трафик с любым “Source IP“ на интерфейсе “10.150.151.10“. Проверьте пожалуйста, изменилась ли ситуация.»

mpegushin ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.