LINUX.ORG.RU
решено ФорумAdmin

Openvpn клиент не видит сервер

 , ,


0

1

Доброго! Тема заезжена, но есть проблема
Есть сервер Openvpn на CentOS вот конфиг

local 172.172.70.231
port 443
proto udp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/serverCert.crt
key /etc/openvpn/keys/serverCert.key
dh /etc/openvpn/keys/dh.pem
crl-verify /etc/openvpn/keys/crl.pem
topology subnet
server 10.8.0.0 255.255.255.0
push «dhcp-option DNS 172.16.30.200»
push «dhcp-option DNS 8.8.8.8»
#push «route 172.18.0.0 255.255.0.0»
push «route 172.0.0.0 255.0.0.0»
#ifconfig-pool-persist /etc/openvpn/ipp.txt
keepalive 10 120
max-clients 10
client-to-client
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn.log
verb 9
mute 20
daemon
mode server
comp-lzo
user nobody
group nobody

ifconfig

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.172.70.231 netmask 255.255.255.0 broadcast 172.172.70.255

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
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

iproute
default via 172.172.70.1 dev eth0 proto static metric 100
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
172.172.70.0/24 dev eth0 proto kernel scope link src
172.172.70.231 metric 100

firewall-cmd --list-all

public (active)
target: default
icmp-block-inversion: no
interfaces: eth0
sources:
services: dhcpv6-client nfs ssh
ports: 443/udp 22/tcp
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:

Маскарадинг настроен

Клиент с win машины подключается. Но пинг до шлюза не идет.
Видимо я где-то ошибся, где не пойму
Вот route print с win машины


IPv4 таблица маршрута ===========================================================================
Активные маршруты: Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика 0.0.0.0 0.0.0.0 192.168.43.1 192.168.43.237 55
10.8.0.0 255.255.255.0 On-link 10.8.0.2 291
10.8.0.1 255.255.255.255 10.0.8.1 192.168.43.237 65
10.8.0.2 255.255.255.255 On-link 10.8.0.2 291
10.8.0.255 255.255.255.255 On-link 10.8.0.2 291
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
172.0.0.0 255.0.0.0 10.8.0.1 10.8.0.2 36
172.16.0.0 255.255.0.0 10.8.0.1 10.8.0.2 36
172.18.0.0 255.255.0.0 10.8.0.1 10.8.0.2 36
192.168.43.0 255.255.255.0 On-link 192.168.43.237 311
192.168.43.237 255.255.255.255 On-link 192.168.43.237 311
192.168.43.255 255.255.255.255 On-link 192.168.43.237 311
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.43.237 311
224.0.0.0 240.0.0.0 On-link 10.8.0.2 291
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.43.237 311
255.255.255.255 255.255.255.255 On-link 10.8.0.2 291
===========================================================================
Постоянные маршруты:
Отсутствует

IPv6 таблица маршрута
===========================================================================
Активные маршруты:
Метрика Сетевой адрес Шлюз
1 331 ::1/128 On-link
26 311 fe80::/64 On-link
17 291 fe80::/64 On-link
17 291 fe80::25fa:7475:ae32:e519/128
On-link
26 311 fe80::340a:8a8c:b990:599f/128
On-link
1 331 ff00::/8 On-link
26 311 ff00::/8 On-link
17 291 ff00::/8 On-link
===========================================================================
Постоянные маршруты:
Отсутствует

Конфиг клиента

client
dev tun
proto udp
remote XXX.XXX.XXX.XXX 443
persist-key
persist-tun
verb 3
route 172.16.0.0 255.255.0.0 vpn_gateway
route 172.18.0.0 255.255.0.0 vpn_gateway
route-method exe
route-delay 2
Спасибо

да уж заезжена так, что хоть в игнор добавляй.

вот брат близнец с похожей проблемой Openvpn wan & lan на одном интерфейсе.

Там все полезные советы (кроме посмотреть tcpdump-ом что в туннель попадает) уже были высказаны.

vel ★★★★★ ()
Последнее исправление: vel (всего исправлений: 1)

Что есть:
1. «клиент не видит сервер» ?
2. «Но пинг до шлюза не идет» - шлюз это кто?

ЗЫ А в целом конечно у вас забавно, пушим немного не мало 172.0.0.0/8 - что уже намекает на незнание.  Далее в клиенте почему-то добавляем кастомные
route 172.16.0.0 255.255.0.0 vpn_gateway
route 172.18.0.0 255.255.0.0 vpn_gateway
Почему именно в клиенте ?

ЗЫЫ
Ну и ещё интересный выбор порт/протокол 443/udp, чем обоснованно?

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

1. Клиент не видит сервер Клиент подключается к серверу, получает шлюз до сети vpn сервера, но пинговать его не может. Я что-то путаю с маршрутами, поэтому и прошу помощи.

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

Есть сети
172.16.10.0/24
172.16.11.0/24
До
172.16.70.0/24
Далее другое предприятие которое подключено к нам оптикой, по vpn нужно ходить именно через нас на оба
172.18.0.0/24
172.18.1.0/24
172.18.3.0/24 и далее
Теперь сеть еще одного предприятия
172.20.1.0/24-172.20.66.0/24
Поэтому, передавать маршруты клиенту буду именно так, кому что нужно.
Порт 443 использован для последующего поднятия stunnel, но это позже. Считай что от балды поставил.

Vlan-48 ()

Клиент с win машины подключается. Но пинг до шлюза не идет.

Что Вы шлюзом называете? До второй стороны туннеля (10.8.0.1) пинг со стороны клиента идет? И что должно получиться в результате? В какие сети должен ходить клиент через VPN, а в какие напрямую?

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

Шлюз для клиента 10.8.0.1
Клиент получает адрес 10.8.0.2
Ходить необходимо в сети которые я описал ранее, поэтому и 172.0.0.0/8
потому что есть 172.16-172.172/24 В связи с этим приходиться использовать /8
Т.К. /9 Ограничена 172.16.0.0-172.127.255.254
Сидеть и в руку прописывать сети мне не очень хочется. Сервер 10.8.0.1 не пингует клиента 10.8.0.2, клиент тоже не пингует сервер.

Vlan-48 ()
Ответ на: комментарий от Serge10

Сервер ovpn на виртуальной машине.
Интерфейсы eth0(172.16.30.*/24) и tun0(10.8.0.1/24) который поднимается openvpn.
За eth0 сеть 172.16.0.0/24(сеть больше но для примера так)
Клиент подключается к серверу и получает адрес 10.8.0.2/24 и должен увидеть сеть 172.16.0.0/24,но не пингует даже 10.8.0.1,хотя маршрут к ней на клиенте есть. Вот тут у меня и проблема.
Маршруты с клиента выше. С сервера тоже.

Vlan-48 ()
Ответ на: комментарий от Vlan-48

Клиент подключается к серверу и получает адрес 10.8.0.2/24
но не пингует даже 10.8.0.1

Это не проблема маршрутизации, тут явно что-то с файрволом не так. Проверьте, возможно у Вас файрвол (либо на сервере, либо на клиенте) просто не знает ничего об интерфейсе tun0 и по умолчанию все блокирует.

Serge10 ★★★★ ()
Ответ на: комментарий от Vlan-48

tcpdump говорит вот так при попытке пинга с клиента на сервер
16:19:12.082492 IP 176.59.*.*openvpn > 172.16.30.150.https: UDP, length 76
16:19:12.083559 IP 172.16.30.150.https > 176.59.*.*.openvpn: UDP, length 41
16:19:14.962317 IP 176.59.*.*.openvpn > 172.16.30.150.https: UDP, length 84

176.59.*.* клиент
172.16.30.150 адрес сервера

Vlan-48 ()
Ответ на: комментарий от Vlan-48

Сервер 10.8.0.1 не пингует клиента 10.8.0.2, клиент тоже не пингует сервер.

Что бы исключить fw и винду. Проверьте для начала с linux клиента.
Точно отключив fw и на первом и втором. И посмотрите tcpdump на соответствующих tun как сервера так и клиента. Пинговать только адреса клиента и сервера ovpn, пока забудем про остальные сети.

172.16-172.172/24

Некрасиво. Кто же так придумал? Я к тому что приватная это только 172.16/12 все что до и после принадлежит разным владельцам в интернете.

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

Ещё есть нюанс, если требуется активный трафик на столько сетей opvn такого может не выдержать. Есть хорошие истории баланса, но это явно не про ТС, так как он даже банальный не может настроить. Мне кажется выбираем «не тот инструмент», тут скорее ipsec лучше будет. Ну и ещё один момент из топика, проверяем на вин клиенте, он что роутер? win роутер? Что-то странное.

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

У меня уже есть настроенный сервер, который работает на другой площадке. Но мне неудобно ходить из той сети во все остальные. В том то и дело что настроены они одинаково. Но этот почему-то не работает.

Vlan-48 ()
Ответ на: комментарий от Serge10

Всем спасибо. Я просто удалил все правила iptables.И добавил разрешающие.Проблемы у меня были не в маршрутизации, а в нате. Для моей сети он был не нужен, т.к. уже есть нат на маршрутизаторе. Теперь все работает хорошо. Просто запарился.

Vlan-48 ()
Ответ на: комментарий от Vlan-48

Поздравляю с решением проблемы, хочу только напомнить, что отключить файрвол Вам советовали, минимум, два раза - здесь и здесь. Причем мне Вы ответили, что отключение файрвола не помогло :(.

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

Самое интересное что фаервол был действительно отключен. Проходило соединение , но связь не работала.Я просто не знаю, правила ната перестают действовать когда отключаешь iptables? Поэтому при удалении всего все пошло.

Vlan-48 ()
Ответ на: комментарий от Vlan-48

Я просто не знаю, правила ната перестают действовать когда отключаешь iptables?

Да, конечно, перестают. Но для того, чтобы пинговать другой конец туннеля, NAT не нужен.

Serge10 ★★★★ ()