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

OpenVPN между локальными сетями. Нет пинга между клиентами


0

2

Имеются две сети, территориально отдалённые друг от друга. Первая сеть ходит в интернет через белый статический IP, другая - через мопед Yota, соответственно NAT без возможности прокинуть порт, динамический IP и прочие «радости жизни». Настраиваю в первой сети OpenVPN сервер, во второй - клиент.

Первая подсеть: 192.168.1.0/24, шлюз 192.168.1.242 Вторая подсеть: 192.168.3.0/24, шлюз 192.168.3.3

Сеть для VPN 172.16.0.0/16

Сервер:

port 2000
proto tcp
dev tun

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/gw.crt
key /etc/openvpn/keys/gw.key
dh /etc/openvpn/keys/dh1024.pem

server 172.16.130.0 255.255.255.0

route 192.168.3.0 255.255.255.0

ifconfig-pool-persist /etc/openvpn/ipp.txt

push "route 192.168.1.0 255.255.255.0" # home subnet
push "dhcp-option DNS 192.168.1.242" #DNS
push "dhcp-option DOMAIN localnet.antora" #DNS suffix
push "dhcp-option WINS 192.168.1.242" #WINS

keepalive 10 120

comp-lzo
user nobody
group nogroup
persist-key
persist-tun

status /var/log/openvpn-status.log
log-append  /var/log/openvpn.log

verb 9
mute 20
client-to-client
client-config-dir /etc/openvpn/ccd

Клиент:

client
dev tun
proto tcp
remote <внешний IP адрес первой подсети> 2000
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/msk-client.crt
key /etc/openvpn/keys/msk-client.key
comp-lzo
verb 3

В общем, сам по себе прогресс есть. Идут пинги шлюз > шлюз, шлюз -> клиент и даже клиент->vpn_адрес_не_своего_шлюза. Но никак не проходят пинги клиент <-> клиент и клиент -> не_свой_шлюз.

В iptables клиента вписана всего лиш одна скупая строка:

iptables -t nat -A POSTROUTING ! -d 192.168.3.0/24 -j MASQUERADE

На первом шлюзе iptables побольше ввиду того, что несколько сетевых карт, несколько дополнительных подсетей внутри офиса и прямой проброс извне в локалку. Но для VPN суть та же, что и на втором шлюзе.

Роутинг прописан. На сервере первой подсети:

# ip route
192.168.3.0/24 via 172.16.130.2 dev tun0

Аналогчный и на сервере второй подсети:

# ip route
192.168.1.0/24 via 172.16.130.29 dev tun0

В общем, не понятно, почему не видят друг друга клиенты подсетей, если пинги со шлюзов идут куда угодно.

Проверял вывод tcpdump-а на втором шлюзе, так как там лёгкая таблица iptables. Выяснилось, что пакеты от клиентов даже не доходят до интерфейса tun0. Почему сервер их отшвыривает?

Выяснилось, что пакеты от клиентов даже не доходят до интерфейса tun0.

От каких клиентов не доходят пакеты, от первой или второй сети?

И я не совсем понял вашу топологию. У вас есть две сети, в каждой из них два шлюза, кто из них openvpn-сервер и openvpn-клиент? Компьютеры в этих локальных сетях вы тоже называете клиентами, но это другое, чем openvpn-клиент? Или у вас openVPN-соединение устанавливается между компьютером пользователя и шлюзом другой сети?

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

У вас есть две сети, в каждой из них два шлюза

Нет-нет. В каждой сети по одному шлюзу. Шлюз первой сети - VPN-сервер, шлюз второй сети - VPN-клиент.

Компьютеры в этих локальных сетях вы тоже называете клиентами, но это другое, чем openvpn-клиент?

Согласен, тут сильно запутал. В двух случаях я говорил про впн-клиент==шлюз второй подсети. В остальных случаях я говорил про компьютеры локальных подсетей. В общем идут пинги шлюз -> комп_другой_локалки, шлюз <-> шлюз и комп_одной_локалки -> vpn-адрес_шлюза_другой локалки. Нужно организовать трафик между комп_одной локалки <-> шлюз_другой_локалки и комп_одной_локалки <-> комп_другой_локалки

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

В общем, если судить по картинке из мануала http://www.opennet.ru/docs/RUS/iptables/ а именно, по етой: http://www.opennet.ru/docs/RUS/iptables/misc/iptables-tutorial/images/tables_..., то пакет теряется между filter FORWARD и mangle POSTROUTING. Есть ли способы понять, как его фильтрует ip route?

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

Это звучит странно, что пакет теряется между FORWARD и POSTROUTING. Попробуйте для нужных пакетов сделать ″-j TRACE″ в iptables и включить его логирование http://serverfault.com/questions/385937/how-to-enable-iptables-trace-target-o... . Чтобы в логах было видно, какие цепочки проходит пакет.

Посмотрите, добавляется ли на openvpn-клиенте маршут к 192.168.1.0/24 через tun0?

MASQRADE лучше привяжите к интерфейсу, а не к ip-адресу, чтобы он не срабатывал на пакеты через tun0:

iptables -t nat -A POSTROUTING -o ethX -j MASQUERADE

где вместо ethX тот интерфейс, который на модем YOTA.

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

Вот трейс на шлюзе первой сети. Вторую оттрейсить я смогу только вечером.

Sep 22 09:59:48 gateway kernel: [658099.434409] TRACE: raw:PREROUTING:policy:2 IN=eth1 OUT= MAC=00:1d:7d:05:ce:57:00:1d:7d:05:ce:a8:08:00 SRC=192.168.1.111 DST=192.168.3.3 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=28563 SEQ=3
Sep 22 09:59:48 gateway kernel: [658099.434423] TRACE: mangle:PREROUTING:rule:1 IN=eth1 OUT= MAC=00:1d:7d:05:ce:57:00:1d:7d:05:ce:a8:08:00 SRC=192.168.1.111 DST=192.168.3.3 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=28563 SEQ=3
Sep 22 09:59:48 gateway kernel: [658099.434433] TRACE: mangle:PREROUTING:policy:5 IN=eth1 OUT= MAC=00:1d:7d:05:ce:57:00:1d:7d:05:ce:a8:08:00 SRC=192.168.1.111 DST=192.168.3.3 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=28563 SEQ=3
Sep 22 09:59:48 gateway kernel: [658099.434445] TRACE: nat:PREROUTING:policy:20 IN=eth1 OUT= MAC=00:1d:7d:05:ce:57:00:1d:7d:05:ce:a8:08:00 SRC=192.168.1.111 DST=192.168.3.3 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=28563 SEQ=3
Sep 22 09:59:48 gateway kernel: [658099.434465] TRACE: mangle:FORWARD:policy:2 IN=eth1 OUT=tun0 MAC=00:1d:7d:05:ce:57:00:1d:7d:05:ce:a8:08:00 SRC=192.168.1.111 DST=192.168.3.3 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=28563 SEQ=3
Sep 22 09:59:48 gateway kernel: [658099.434475] TRACE: filter:FORWARD:policy:1 IN=eth1 OUT=tun0 MAC=00:1d:7d:05:ce:57:00:1d:7d:05:ce:a8:08:00 SRC=192.168.1.111 DST=192.168.3.3 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=28563 SEQ=3
То есть, вроде как пакеты в FORWARD пробрасываются в tun0. Но как по етим логам понять, куда они дальше идут?

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

Интересно, а ето нормально, что при разных отправителях меняется src в роутинге?

# ip route get 192.168.3.3192.168.3.3 via 172.16.130.2 dev tun0  src 172.16.130.1
    cache  ipid 0x9e04 rtt 133ms rttvar 89ms cwnd 10
# ip route get 192.168.3.3 iif eth1 from 192.168.1.111
192.168.3.3 from 192.168.1.111 via 172.16.130.2 dev tun0  src 192.168.1.242
    cache <src-direct>  ipid 0x9e04 rtt 133ms rttvar 89ms cwnd 10 iif eth1

abr_linux
() автор топика
Ответ на: комментарий от mky

Попробовал поднять ppp-тоннель. Та же самая история. Дальше filter FORWARD пакеты не проходят. В каком же месте косяк..

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

А в цепочке FORWARD (filter) точно ACCEPT всех пакетов?

Что касательно ″ip route get″, то это её нормальное поведение. Я не нашёл описание вывода этой команды, но, получается, что когда в выводе есть и ″from″ и ″src″, то первое означает src-адрес пакета, а второе интерфейс. В целом команда работает правильно и для случая PBR (ip rule), исключая маршрутизацию с маркировкой пакетов в iptables.

mky ★★★★★
()
Ответ на: комментарий от mky
# iptables -t filter -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

А есть мануалы по iptables debug, де было бы описано значение policy? Потому что я вижу mangle:PREROUTING:policy:5, nat:PREROUTING:policy:20, а что они означают найти не могу

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

Мануала не знаю, вроде как это должны быть номера сработавших правил. Покажите лучше вывод ″iptables-save -c″.

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

man openvpn | grep client-to-client

А вы просто поиском по етой странице пробегитесь и случайно обнаружите «client-to-client» в настройках сервера. Если реч о чём-то дополнительном, намекните

abr_linux
() автор топика
Ответ на: комментарий от mky
# iptables-save -c
# Generated by iptables-save v1.4.12 on Mon Sep 23 11:08:38 2013
*raw
:PREROUTING ACCEPT [4683215:3194563940]
:OUTPUT ACCEPT [58778:24532517]
[2:120] -A PREROUTING -s 192.168.3.119/32 -d 192.168.1.111/32 -j TRACE
COMMIT
# Completed on Mon Sep 23 11:08:38 2013
# Generated by iptables-save v1.4.12 on Mon Sep 23 11:08:38 2013
*filter
:INPUT ACCEPT [134261:43676132]
:FORWARD ACCEPT [5969007:3443140047]
:OUTPUT ACCEPT [129114:51778229]
COMMIT
# Completed on Mon Sep 23 11:08:38 2013
# Generated by iptables-save v1.4.12 on Mon Sep 23 11:08:38 2013
*mangle
:PREROUTING ACCEPT [6081498:3483521345]
:INPUT ACCEPT [130851:43160232]
:FORWARD ACCEPT [5950647:3440361113]
:OUTPUT ACCEPT [126149:51185233]
:POSTROUTING ACCEPT [6076182:3491636420]
COMMIT
# Completed on Mon Sep 23 11:08:38 2013
# Generated by iptables-save v1.4.12 on Mon Sep 23 11:08:38 2013
*nat
:PREROUTING ACCEPT [54335:3905229]
:INPUT ACCEPT [677:128180]
:OUTPUT ACCEPT [615:187071]
:POSTROUTING ACCEPT [242:70896]
[76722:5914965] -A POSTROUTING -o eth1 -j MASQUERADE
COMMIT
# Completed on Mon Sep 23 11:08:38 2013
abr_linux
() автор топика
Ответ на: комментарий от vxzvxz

ОК, счас почитаю. Может, и правда дело в маршрутизации

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

Это точно те правила iptables, от которых был лог/debug, приведённый выше? Потому что строка:

Sep 22 09:59:48 gateway kernel: [658099.434423] TRACE: mangle:PREROUTING:rule:1 IN=eth1 OUT= MAC=00:1d:7d:05:ce:57:00:1d:7d:05:ce:a8:08:00 SRC=192.168.1.111 DST=192.168.3.3 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=28563 SEQ=3
вроде как говорит, что в цепочке mangle:PREROUTING сработало правило 1, а у вас эта цепочка пустая.

Попробуйте на всякий случай отключить rp_filter (через sysctl или echo > /proc), может он мешается.

То, что через ppp не заработало, ИМХО, говорит, что client-to-client и iroute здесь вобще не при чём.

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

А касательно того, что проходят пинги

и даже клиент->vpn_адрес_не_своего_шлюза

они, эти пинги, видны в выводе ″tcpdump -i tun0 -n -nn″? Они нормально логируются через ″-j TRACE″?

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

Попробуйте на всякий случай отключить rp_filter

Я его изначально отключал. В общем, история оказалась довольно запутанной.

Дело в том, что изначально у нас обе сети общались по IPSec, который соединялся при помощи железки DI-804HV. Потом офис 192.168.3.0/24 переехал и ему искали проводной интернет с белым IP. Пока искали взяли йоту, как временное решение для интернета. После переезда канал, само собой не поднимался из-за двойного NAT йоты, но я решил на будущее переместить инициатора IPSec на линуксовский комп, чтобы в будущем забыть о железке и установил там racoon. Експерименты с IPSec не особо удались опять же из-за йоты и я решил его отключить, чтобы не мешал настраивать OpenVPN, которая за NAT вроде как неплохо себя чувствует.

Косяк оказался в том, что остались SA. И каким-то образом локальные пакеты не инкапсулировались в тоннель IPSec, а транзитные - да. ИМХО, не напрасно я обратил внимание, что у исходящих пакетов src 172.16.130.1, а у транзитных 192.168.3.3. В мануалах для настройки IPSec как-то обращается внимание на то, что нужно src прописывать.

В общем, я сделал

# racoon-tool sadflush
# racoon-tool spdflush

и пакеты пошли.

Другое дело, что нам дали нормальный инет с белым IP и теперь OpenVPN лежит на полочке, а мы продолжили использовать IPSec.

Всем спасибо за помощ! :)

abr_linux
() автор топика
Ответ на: комментарий от mky
# uname -a
Linux astmsk 3.2.0-53-generic #81-Ubuntu SMP Thu Aug 22 21:01:03 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Да, мне тоже странно было, потому что в любых схемах работы iptables между FORWARD и POSTROUTING никаких решений, кроме DROP не должно приниматся. Но факт остаётся фактом. Либо проблема была щё глубже и xfrm повлияли только косвенно

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