Open VPN: проблемы с маршрутизацией

Статус
В этой теме нельзя размещать новые ответы.
P

past0r

Постоялец
Регистрация
3 Ноя 2008
Сообщения
94
Реакции
6
router office-1 router office-2
router VPN Server router VPN Client
LAN-1 ------| eth0 tap0 | --------- VPN ---------- | tap0 eth0 | ------ LAN-2
eth1 | --Inet Inet-- | eth1


LAN-1 = eth0 = 192.168.100.1/24
LAN-2 = eth0 = 192.168.150.1/24
VPN = tap0 = 192.168.200/24

Версия OpenVPN: 2.1_rc11 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Sep 18 2008




Параметры роутера с сервером OpenVPN
Версия OpenVPN: 2.1_rc11 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Sep 18 2008

VPN Server Config
---------------------
iGate:~# cat /etc/openvpn/server.conf
mode server
tls-server
daemon

ifconfig 192.168.200.1 255.255.255.0

port 1194
proto tcp-server
dev tap0

ca /root/openvpn/keys/ca.crt
cert /root/openvpn/keys/iGate.crt
key /root/openvpn/keys/iGate.key # This file should be kept secret
dh /root/openvpn/keys/dh1024.pem

client-config-dir /etc/openvpn/ccd
route 192.168.150.0 255.255.255.0 192.168.200.1
keepalive 10 120
client-to-client
comp-lzo
persist-key
persist-tun
verb 9
log-append /var/log/openvpn.log
---------------------

в /etc/openvpn/ccd находится 1 файл
---------------------
iGate:/etc/openvpn/ccd# cat NTagil
# приcваиваем ip-адрес
ifconfig-push 192.168.200.2 255.255.255.0

# роутинг на сети центрального офиса
push "route 192.168.100.0 255.255.255.0 192.168.200.1"
---------------------

кусочек конфига фаервола
---------------------
echo 1 > /proc/sys/net/ipv4/ip_forward
ipt="/sbin/iptables"

$ipt -v -A INPUT -i tun+ -j ACCEPT
$ipt -v -A OUTPUT -o tun+ -j ACCEPT
$ipt -A FORWARD -i tun+ -j ACCEPT
$ipt -A FORWARD -o tun+ -j ACCEP
---------------------

Таблица маршрутов:
---------------------
iGate:/etc/openvpn/ccd# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.199.246.12 * 255.255.255.252 U 0 0 0 eth1
localnet * 255.255.255.0 U 0 0 0 eth0
192.168.150.0 192.168.200.2 255.255.255.0 UG 0 0 0 tap0
192.168.200.0 * 255.255.255.0 U 0 0 0 tap0
default XXX.XXX.XXX.XX 0.0.0.0 UG 0 0 0 eth1
---------------------




Конфа Роутера в филиале
Версия OpenVPN: 2.1_rc11 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Sep 18 2008

Client config
---------------------
tgate:~/net# cat /etc/openvpn/client.conf
client
dev tap0
proto tcp


# адрес сервера в центрально офисе
remote XXX.XXX.XXX.XXX 1194
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
ns-cert-type server
ca /root/openvpn/keys/ca.crt
cert /root/openvpn/keys/ekb.crt
key /root/openvpn/keys/ekb.key
log-append /var/log/openvpn.log
status /var/log/openvpn/openvpn-status.log
---------------------

кусочек конфига фаервола
---------------------
echo 1 > /proc/sys/net/ipv4/ip_forward
ipt="/sbin/iptables"

$ipt -v -A INPUT -i tun+ -j ACCEPT
$ipt -v -A OUTPUT -o tun+ -j ACCEPT
$ipt -A FORWARD -i tun+ -j ACCEPT
$ipt -A FORWARD -o tun+ -j ACCEP
---------------------


Таблица маршрутов:
---------------------
tgate:~/net# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
93.95.168.96 * 255.255.255.252 U 0 0 0 eth1
192.168.100.0 192.168.200.1 255.255.255.0 UG 0 0 0 tap0
192.168.150.0 * 255.255.255.0 U 0 0 0 eth0
192.168.200.0 * 255.255.255.0 U 0 0 0 tap0
default XXX.XXX.XXX.XXX 0.0.0.0 UG 0 0 0 eth1
---------------------


История такая:

OpenVPN работает. Роутеры друг друга пингуют.
С роутера филиала (office-2) можно пропиновать ВСЮ локальную сеть центрального офиса LAN-1, а из локальной сети филиала (LAN-2) не пингуется ни роутер, ни локальная сеть.
И локальной сети центрально офиса можно пинговать роутер филиала, а дальше уже не идет.

В Чем может быть загвоздка, я уже голову всю сломал! Ж(

Проблема не в openvpn. Он работает стабильно, по какой то причине не порпрасываются пакеты между интерфейсами. на рутере удаленного подразделения, в чем может быть проблема, если форвардинг включен
 
allow tcp from me to [vpn server] dst-port 1723 out
allow tcp from [vpn server] 1723 to me in
 
Рискну слегка - может давно юзаете

но мне это решение очень нравится:

Соединяем две ethernet сетки чтобы они видели друг друга
как будто находятся в одному коммутаторе.

Делать будем на основе ядерного netgraph,
в частности модули ng_ether и ng_bridge.

Добавляем в /boot/loader.conf

netgraph_load="YES"
ng_ether_load="YES"
ng_bridge_load="YES"

Есть 2 варианта работы системы

1. Без модуля ng_bridge.
Мы получим как бы объединение сетевых интерфейсов в один невидимый.
Сами сервера с этими интерфейсами не будут видеть трафик на них.
Получается прозрачное соединение как будто между сетями
протянули физический кабель.
Весь трафик приходящий на интерфейс одного из серверов
будет прозрачно проходить на другой.

2. С модулем ng_bridge.
Мы получим как бы включение интерфейсов на обоих серверах в один свитч.
Сервера будут видеть трафик на интерфейсах.
Трафик не предназначеный для соседней
сети не пойдет по каналу (реализация обычного свитча).


Конфигурация:

Имеем два типичных роутера.

1.
Два сетевых интерфейса
fxp0 - белый интернет адрес для примера 1.1.1.1
fxp1 - серый локальный адрес 192.168.0.1

2.
Два сетевых интерфейса
fxp0 - белый интернет адрес для примера 1.1.1.2
fxp1 - серый локальный адрес 192.168.0.2

При загрузке модуля ng_ether на обоих роутерах в netgraph
атоматически были созданы узлы с названием сетевых карт.

lmik# ngctl list
There are 3 total nodes:
Name: ngctl3178 Type: socket ID: 00000009 Num hooks: 0
Name: fxp0 Type: ether ID: 00000001 Num hooks: 0
Name: fxp1 Type: ether ID: 00000002 Num hooks

Вариант №1 непрактичный и рассматривать его не будем,
просто напишу конфигурацию графов вдруг кому-то понадобится.

ngctl mkpeer fxp0 ksocket lower inet/dgram/udp
ngctl msg switch:link1 bind inet/1.1.1.1:1234
ngctl msg switch:link1 connect inet/1.1.1.2:1234
ngctl msg fxp1: setpromisc 1
ngctl msg fxp1: setautosrc 0

Вариант №2

На первом сервере конфигурация нетграфов будет выглядеть так:

#Создаем узел bridge и подключаем к его хуку link0 физический (нижний) уровень fxp1
ngctl mkpeer fxp1: bridge lower link0
#назовем этот узел switch
ngctl name fxp1:lower switch
#создадим узел ksocket и подсоединим его хуком inet/dgram/udp к хуку link1 нашего switch
ngctl mkpeer switch: ksocket link1 inet/dgram/udp
#Отправляем сообщение узлу switch:link1 (туда подключен узел ksocket)
#чтобы тот забиндил сокет для входящего трафика на нашем внешнем IP
ngctl msg switch:link1 bind inet/1.1.1.1:1234
#Отправляем команду узлу switch:link1 (туда подключен узел ksocket)
#чтобы тот соединился со вторым сервером
ngctl msg switch:link1 connect inet/1.1.1.2:1234
#Соединяем хук link2 нашего switch с верхним уровнем интерфейса fxp1
#т.е подключаем наш сервер в наш виртуальный свитч.
ngctl connect switch: fxp1: link2 upper
#включаем на сетевой карте прослушку всех пакетов,
#а не только тех что предназначаются ей.
ngctl msg fxp1: setpromisc 1
ngctl msg fxp1: setautosrc 0

На втором нужно изменить строчки:

ngctl msg switch:link1 bind inet/1.1.1.2:1234
ngctl msg switch:link1 connect inet/1.1.1.1:1234

Просто поменять местами адреса.

Для красоты оформляем запуск нашего виртуалсвитча в скрипт
и при желании кладем в /usr/local/etc/rc.d

#!/bin/sh

#тут указываем наш белый адрес
self=1.1.1.1
peer=1.1.1.2
#тут порт по которому будет бегать трафик
port=1234
#интерфейс который включаем в свитч
if=fxp1
case "$1" in
start)
echo "Starting netgraph switch."
ngctl mkpeer ${if}: bridge lower link0
ngctl name ${if}:lower switch
ngctl mkpeer switch: ksocket link1 inet/dgram/udp
ngctl msg switch:link1 bind inet/${self}:${port}
ngctl msg switch:link1 connect inet/${peer}:${port}
ngctl connect switch: ${if}: link2 upper
ngctl msg ${if}: setpromisc 1
ngctl msg ${if}: setautosrc 0
echo "Ok."
exit 0
;;
stop)
echo "Stopping netgraph switch."
/usr/sbin/ngctl shutdown ${if}:
/usr/sbin/ngctl shutdown switch:
echo "Ok."

exit 0
;;
restart)
sh $0 stop
sh $0 start
;;
*)
echo "Usage: `basename $0` { start | stop | restart }"
exit 64
;;
esac

Красота какая, никаких впн крутить не надо, просто запустить скрипт,
никаких реконектов и т.п...


Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.
 
Красиво, только от необходимости в VPN это не спасает.
 
Опытным путем выяснил, что между собой не общаются tap0 и eth0 на втором шлюзе, который находится в удаленном подразделении.

ip_forward = 1

в чем может быть проблема?
 
past0r написал(а):
Опытным путем выяснил, что между собой не общаются tap0 и eth0 на втором шлюзе, который находится в удаленном подразделении.

ip_forward = 1

в чем может быть проблема?
Нажмите для раскрытия...
вот так и хочется сказать: ы жедезе!
Но пока не говорю, спрашиваю: что там за шелезяго?
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху