LINUX.ORG.RU
Форум — Admin  

Openvpn маршрутизация, почему сервер не видит внутренние адреса за клиентом?

 , ,


1

2

День добрый господа.

Есть OpenVPN сервер далеко в интернете, к нему подключается клиент, за которым есть сеть ( 192.168.100.0/255.255.255.0 ) эта сеть получает интернет через этот ОпенВПН сервер.

но почему с сервера я не могу пинговать сеть 192.168.100.0 ? например клиент опенВПН имеет внутренний адрес 192.168.100.192

# cat server.conf

port 1194 #Порт
proto udp #Протокол
dev tun   #Название виртуального устройства
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key # This file should be kept secret
dh /etc/openvpn/dh1024.pem
server 10.10.10.0 255.255.255.0 # vpn subnet
ifconfig-pool-persist ipp.txt # Тут будут храниться ip адреса клиентов
#push "route 192.168.100.0 255.255.255.0" # home
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log-append  openvpn.log
verb 4
mute 20
client-to-client
client-config-dir /etc/openvpn/ccd # Тут будут настройки для каждого филиала
route 192.168.100.0 255.255.255.0 # Маршрут от сервера до филиала 1


cat ccd/client1

iroute 192.168.100.0 255.255.255.0

маршрутизация на сервере 

# ip ro
default via 91.230.211.129 dev eth0
10.10.10.0/24 via 10.10.10.2 dev tun0
10.10.10.2 dev tun0  proto kernel  scope link  src 10.10.10.1
91.111.211.128/25 dev eth0  proto kernel  scope link  src 91.111.211.155
192.168.100.0/24 via 10.10.10.2 dev tun0



#iptables-save

# iptables-save
# Generated by iptables-save v1.4.21 on Thu Nov 27 09:44:51 2014
*filter
-A FORWARD -s 10.10.10.0/24 -d 192.168.100.0/24 -i tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
COMMIT
# Completed on Thu Nov 27 09:44:51 2014
# Generated by iptables-save v1.4.21 on Thu Nov 27 09:44:51 2014
*nat
-A POSTROUTING -s 192.168.0.0/16 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.10.0.0/16 -j MASQUERADE
COMMIT

Далее клиент.

# ifconfig

eth0      Link encap:Ethernet  HWaddr 00:15:e9:42:12:e7
          inet addr:192.168.100.192  Bcast:192.168.100.255  Mask:255.255.255.0
          inet6 addr: fe80::215:e9ff:fe42:12e7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9529433 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14498216 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1069870112 (1.0 GB)  TX bytes:4244836235 (4.2 GB)
          Interrupt:17 Base address:0xc00

eth1      Link encap:Ethernet  HWaddr 00:15:e9:4a:aa:ae
          inet addr:195.111.96.36  Bcast:195.111.96.63  Mask:255.255.255.192
          inet6 addr: fe80::215:e9ff:fe4a:aaae/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14219418 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9328431 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4058530661 (4.0 GB)  TX bytes:1339978921 (1.3 GB)
          Interrupt:21

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:31009 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31009 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:10254502 (10.2 MB)  TX bytes:10254502 (10.2 MB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.10.10.6  P-t-P:10.10.10.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:3334189 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3852969 errors:0 dropped:8986 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:437725017 (437.7 MB)  TX bytes:557979603 (557.9 MB)

#cat /etc/openvpn/client.conf

remote 91.111.211.155 1194
client
dev tun
proto udp
resolv-retry infinite # this is necessary for DynDNS
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/proxy.crt
key /etc/openvpn/proxy.key
comp-lzo
verb 4
mute 20
redirect-gateway
verb 4

#ip ro

10.10.10.5 dev tun0  proto kernel  scope link  src 10.10.10.6
91.211.211.155 via 195.209.96.1 dev eth1
195.111.96.0/26 dev eth1  proto kernel  scope link  src 195.111.96.36
192.168.100.0/24 dev eth0  proto kernel  scope link  src 192.168.100.192
10.10.10.0/24 via 10.10.10.5 dev tun0
default via 10.10.10.5 dev tun0

клиент имеет внутренний адрес 192.168.100.192, с сервера по этому адресу он не пингуется 

# traceroute 192.168.100.192
traceroute to 192.168.100.192 (192.168.100.192), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *

если я подключусь ещё одним клиентом с сетью 192.168.Х.0 то две сети друг друга видят по внутренним адресам, но сам клиент не видит противоположную сеть.

вот и хотел бы разобраться, почему это так. на сервере маршут имеется 

192.168.100.0/24 via 10.10.10.2 dev tun0
как раз указывающий что эта сеть в том туннеле.

Заранее спасибо.

← systemd user unit fencing
Падает php5-fpm →

Не включена маршрутизация на клиенте. Неправильные настройки межсетевого экрана на клиенте

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

а можно подробнее, что не так?

Маршрутизация на клиенте 

# ip ro
10.10.10.5 dev tun0  proto kernel  scope link  src 10.10.10.6
89.250.26.75 via 195.209.96.1 dev eth1
91.111.211.155 via 195.209.96.1 dev eth1
195.111.96.0/26 dev eth1  proto kernel  scope link  src 195.111.96.36
192.168.100.0/24 dev eth0  proto kernel  scope link  src 192.168.100.192
10.10.10.0/24 via 10.10.10.5 dev tun0
default via 10.10.10.5 dev tun0

межсетевой экран 

root@proxy:/# iptables-save
# Generated by iptables-save v1.4.4 on Thu Nov 27 11:54:15 2014
*nat
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.100.192:3128
-A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE
COMMIT
# Completed on Thu Nov 27 11:54:15 2014
# Generated by iptables-save v1.4.4 on Thu Nov 27 11:54:15 2014
*mangle
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 128
COMMIT
# Completed on Thu Nov 27 11:54:15 2014
# Generated by iptables-save v1.4.4 on Thu Nov 27 11:54:15 2014
*filter
:LOGDROP - [0:0]
-A FORWARD -i tun0 -j ACCEPT
-A LOGDROP -j LOG --log-prefix "LOGDROP "
-A LOGDROP -j DROP
COMMIT
# Completed on Thu Nov 27 11:54:15 2014

ilovemicrosoft
() автор топика

Серверу OpenVPN добавить директиву 

route 192.168.100.0  255.255.255.0
Разрешить пересылку пакетов через интерфейсы 
 echo 1 > /proc/sys/net/ipv4/ip_forward

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

Форвард разрешён, ведь сейчас сеть 192.168.100.0 получает интеренет через OpenVPN сервер.

про маршрут можно подробнее?

вот таблица маршрутизация на сервере

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         91.111.211.129  0.0.0.0         UG    0      0        0 eth0
10.10.10.0      10.10.10.2      255.255.255.0   UG    0      0        0 tun0
10.10.10.2      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
91.230.211.128  0.0.0.0         255.255.255.128 U     0      0        0 eth0
192.168.100.0   10.10.10.2      255.255.255.0   UG    0      0        0 tun0

последня маршрут я так понимаю он и есть?

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

У вас же SNAT на клиенте, т.е. когда с сервера пингуте 192.168.100.192, ответы приходят от 10.10.10.6 - это куда их пложить кроме как в мусор?

-A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE
rubic ★
()
Ответ на: комментарий от rubic

А вот это интересней, пробую совсем исключить маскарад, тоесть комментирую это правило, тогда весь инет работает, но я с клиентов сети не вижу ОпенВПН сервера.

  1     2 ms    <1 мс    <1 мс  PROXY [192.168.100.192]
  2     *        *        *     Превышен интервал ожидания для запроса.
  3     *        *        *     Превышен интервал ожидания для запроса.

теперь пытаюсь указать, что отправлять в НАТ надо только пакеты пришедшие с внутренний сети.

я верно понимаю?

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

я поясню коротко, почему так у меня.

Канал интернета через OpenVPN это основной канал, опенВПН сервер находится в зоне пиринга, с нулевой тарификацией и без ограничений по ширине полосы.

у клиента есть прямой выход в инет на интерфейсе eth1 но он шибко ограничен в ширине.

поэтому я не использую SNAT ибо если с пирингом что-то случается, что всё автоматом продолжает работать на прямом канале поэтому и используется маскарад без привязки к внешнему интерфейсу

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

Нет, если вы хотите с сервера видеть сеть за клиентом, то NAT на клиенте не нужен. Для внутренней сети сервер должен быть виден по адресу 10.10.10.1 просто на сервере надо сделать правило

-A INPUT -i tun0 -s 192.168.0.0/16 -j ACCEPT

какое-то такое (ну, если я верно понял, что вы имеете ввиду под «видеть сервер»).

SNAT на клиенте вам нужен только возможно на eth1, если внутренняя сеть через него должна куда-то попадать в обход OpenVPN.

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

Убираю правило с «маскарадом»

Трассировка маршрута к 10.10.10.1 с максимальным числом прыжков 30

  1    <1 мс    <1 мс    <1 мс  PROXY [192.168.100.192]
  2     *        *        *     Превышен интервал ожидания для запроса.
  3  ^C

Хотя с хоста PROXY 

# ping 10.10.10.1
PING 10.10.10.1 (10.10.10.1) 56(84) bytes of data.
64 bytes from 10.10.10.1: icmp_seq=1 ttl=64 time=3.81 ms

Вот так получается

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

Смотрите правила filter на клиенте. Инет у вас в сети есть, похоже, только по причине прокси сервера.

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

Фильтров нет 

#iptables-save

*filter
:INPUT ACCEPT [687673:352848268]
:FORWARD ACCEPT [6148274:819960197]
:OUTPUT ACCEPT [654726:302196570]
:LOGDROP - [0:0]
-A LOGDROP -j LOG --log-prefix "LOGDROP "
-A LOGDROP -j DROP
COMMIT
# Completed on Thu Nov 27 17:26:16 2014

таблица LOGDROP пустая.

про работу инета, я похоже поторопился.

C:\Users\user>tracert ya.ru

Трассировка маршрута к ya.ru [213.180.204.3]
с максимальным числом прыжков 30:

  1    <1 мс    <1 мс    <1 мс  PROXY [192.168.100.192]
  2     3 ms     3 ms     2 ms  10.10.10.1
*
  5    15 ms    15 ms    18 ms  host42-rs1.milecom.ru [91.221.180.42]
  6    14 ms    16 ms    16 ms  kuchum-xe-0-0-0-601.yndx.net [84.201.159.198]
^C

вот если маскарад выключаю

C:\Users\user>tracert ya.ru

Трассировка маршрута к ya.ru [213.180.204.3]
с максимальным числом прыжков 30:

  1    <1 мс     1 ms     1 ms  PROXY [192.168.100.192]
  2     *        *     ^C

хотя клиент (PROXY) в этот момент 

# traceroute ya.ru
traceroute to ya.ru (213.180.193.3), 30 hops max, 60 byte packets
 1  10.10.10.1 (10.10.10.1)  3.217 ms  3.665 ms  3.669 ms
 ** (это я удалил)
 4  host42-rs1.milecom.ru (91.221.180.42)  15.379 ms  19.586 ms  17.030 ms
 5  kuchum-xe-0-0-0-601.yndx.net (84.201.159.198)  17.107 ms  19.545 ms  17.012 ms

Хотя вот под рукой соседняя контора, правило маскарада удалено, и инет ходит.

ilovemicrosoft
() автор топика

Возможно, с клиента ответ уходит на другой интерфейс. На маршрут по умолчанию.

192.168.100.0/24 dev eth0  proto kernel  scope link  src 192.168.100.192

eth0, я так понимаю, это не VPN интерфейс?

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

Значит на OpenVPN сервере смотрите. У вас, судя по всему, с маршрутизацией порядок. Поэтому либо filter, либо - nat.

Вот что должно быть на стороне OpenVPN сервера:

nat:

-A POSTROUTING -s 192.168.0.0/16 -o eth0 -j MASQUERADE -A POSTROUTING -s 10.10.0.0/16 -o eth0 -j MASQUERADE (это если сам OpenVPN клиент тоже ходит в интернет через туннель)

filter: Либо все разрешено, либо:

-A FORWARD -i tun0 -s -s 192.168.0.0/16 -j ACCEPT -A FORWARD -i tun0 -s -s 10.10.0.0/16 -j ACCEPT (если необходимо)

На клиенте NAT нужет только на eth1:

-A POSTROUTING -s 192.168.0.0/16 -o eth1 -j MASQUERADE

а в filter у вас все и так разрешено

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

На сервере всё так (Forward это временные экспиременты пока не влияющие ни на что) 

# iptables-save
# Generated by iptables-save v1.4.21 on Fri Nov 28 10:13:17 2014
*filter
:INPUT ACCEPT [504985523:233481349762]
:FORWARD ACCEPT [57636870:12777880879]
:OUTPUT ACCEPT [273501662:170813579087]
-A FORWARD -s 10.10.10.0/24 -d 192.168.100.0/24 -i tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
COMMIT
# Completed on Fri Nov 28 10:13:17 2014
# Generated by iptables-save v1.4.21 on Fri Nov 28 10:13:17 2014
*nat
:PREROUTING ACCEPT [77430617:4882636934]
:INPUT ACCEPT [38148053:2179169739]
:OUTPUT ACCEPT [3544493:215634590]
:POSTROUTING ACCEPT [3544279:215621426]
-A POSTROUTING -s 192.168.0.0/16 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.10.0.0/16 -j MASQUERADE
COMMIT
# Completed on Fri Nov 28 10:13:17 2014

на клиенте eth1 это выход в инет, tun0 это выход в опенвпн. фильтр пустой, маскарад такой 

-A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE
если добавляю -o eth1 сеть за клиентом теряет соединение с инетом.

добавил eth1 

Трассировка маршрута к gw.****.ru [91.111.211.155]
с максимальным числом прыжков 30:

1 1 ms 2 ms <1 мс PROXY [192.168.100.192]
2 <1 мс <1 мс <1 мс 195.111.96.33 <--- это шлюз на eth1
3 * ^C

если пишу -o tun0 то инет работает, но тогда у меня будет бяда если Пиринг порвётся, и опенВПН будет недоступен.

ещё из моментов, комп сети за клиентом видит сервер по адресу

Трассировка маршрута к 10.10.10.1 с максимальным числом прыжков 30

  1     1 ms    <1 мс     1 ms  PROXY [192.168.100.192]
  2     2 ms     2 ms     2 ms  10.10.10.1

Трассировка завершена.
ilovemicrosoft
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← systemd user unit fencing
Admin
Падает php5-fpm →