Назад | Перейти на главную страницу

Получение OpenVPN для полного соединения двух сетей

У меня есть клиент (который также является шлюзом для сети 192.168.203.0/24), который пытается подключиться к удаленному серверу (это шлюз для сети 192.168.150.0/24) и создать между ними мост.

У клиента есть следующая конфигурация OpenVPN:

dev tun
remote gs.example.com
ca OurCompany-CA.crt
client
port 5800
proto udp 
comp-lzo 
verb 3
cipher BF-CBC
ca /etc/openvpn/gs-keys/ca.crt
cert /etc/openvpn/gs-keys/kang.crt
key  /etc/openvpn/gs-keys/kang.key
keepalive 10 60
status /var/log/openvpn-status.log
log-append  /var/log/openvpn.log

На сервере есть:

port 5800
proto udp
dev tun
push "route 192.168.150.0 255.255.255.0"
    push "route 192.168.203.0 255.255.255.0"
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/kang-server.crt
key /etc/openvpn/keys/kang-server.key 
dh /etc/openvpn/keys/dh1024.pem
server 192.168.155.0 255.255.255.0
keepalive 10 120
comp-lzo
status /var/log/openvpn-status.log
log /var/log/openvpn.log
verb 3
persist-key
persist-tun
client-config-dir /etc/openvpn/ccd

В файле /etc/openvpn/ccd/kang.exmaple.org содержится следующее:

    iroute 192.168.203.0 255.255.255.0

Из kang (192.168.203.1) я могу пинговать 192.168.150.1, но больше ничего (150.10, 150.11 и т. Д.) Все дают мне "Destination Port Unreachable". Из gs (192.168.150.1) я могу пинговать что угодно в подсети 203 нормально.

Из любого места в сети 203 я могу пинговать 192.168.150.1, но не что-либо еще в этой подсети (получаю «Destination Port Unreachable, когда я пингую 192.168.150.10). Из всего, что находится в подсети 150 (например, если я нахожусь в 192.168 .150.10) Я даже не могу пинговать 192.168.203.1.

Брандмауэр на kang имеет правило ACCEPT для всего, что проходит через его адаптер tun. На gs у меня также есть ACCEPT для tun0, но у меня все еще есть эти проблемы, даже если я полностью отключу брандмауэр.

Мне интересно, читаются ли правила iroute из файлов ccd. Как они должны отображаться в журналах?

РЕДАКТИРОВАТЬ:

ip_forwarding (/ proc / sys / net / ipv4 / ip_forward) установлен в 1 на обеих машинах.

На шлюзе gs (192.168.150.1), если я выполняю traceroute:

traceroute 192.168.203.40
traceroute to 192.168.203.40 (192.168.203.40), 30 hops max, 38 byte packets
 1  192.168.155.6 (192.168.155.6)  396.019 ms  372.837 ms  362.607 ms
 2  192.168.203.40 (192.168.203.40)  364.324 ms  387.439 ms  366.329 ms

Тот же traceroute из 192.168.150.10:

traceroute 192.168.203.40
traceroute to 192.168.203.40 (192.168.203.40), 30 hops max, 38 byte packets
 1  192.168.150.1 (192.168.150.1)  1.409 ms  1.173 ms  1.958 ms
 2  192.168.150.1 (192.168.150.1)  1.475 ms  1.222 ms  1.068 ms

И таблица маршрутизации 192.168.150.10:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.11.0    *               255.255.255.0   U     0      0        0 br-lan
192.168.150.0   *               255.255.255.0   U     0      0        0 eth0.2
default         192.168.150.1   0.0.0.0         UG    0      0        0 eth0.2

Подобные трассировки от 192.168.203.1 (канг):

traceroute 192.168.150.1
traceroute to 192.168.150.1 (192.168.150.1), 30 hops max, 40 byte packets using UDP
 1  192.168.150.1 (192.168.150.1)  51.687 ms   50.260 ms   54.513 ms
kang:~ # traceroute 192.168.150.10
traceroute to 192.168.150.10 (192.168.150.10), 30 hops max, 40 byte packets using UDP
 1  192.168.155.1 (192.168.155.1)  48.623 ms   55.955 ms   54.684 ms
 2  192.168.155.1 (192.168.155.1)  57.062 ms   55.816 ms   57.978 ms

Маршруты Канга (Канг также является VPN-сервером для отдельных пользователей. Они могут получить доступ к 192.168.203.0/24 и 192.168.150.1, но только к 192.168.150.0/24). Этот VPN использует подсеть 192.168.137.0/24:

route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.137.2   *               255.255.255.255 UH    0      0        0 tun0
192.168.155.5   *               255.255.255.255 UH    0      0        0 tun1
192.168.155.1   192.168.155.5   255.255.255.255 UGH   0      0        0 tun1
10.42.7.0       *               255.255.255.0   U     0      0        0 eth1
192.168.137.0   192.168.137.2   255.255.255.0   UG    0      0        0 tun0
192.168.203.0   *               255.255.255.0   U     0      0        0 eth0
192.168.150.0   192.168.155.5   255.255.255.0   UG    0      0        0 tun1
link-local      *               255.255.0.0     U     0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
default         10.42.7.1       0.0.0.0         UG    0      0        0 eth1

Что нужно проверить:

  • Удостовериться /proc/sys/net/ipv4/ip_forward является 1 как на сервере OpenVPN, так и на клиентских машинах.

  • Убедитесь, что машины, которые не являются конечными точками OpenVPN, имеют информацию о маршрутизации для использования VPN-туннеля для доступа к другой сети. Если машины являются шлюзами для своих сетей, маршрутизация должна выполняться автоматически. Если нет, то шлюз по умолчанию должен иметь статический маршрут, который будет отправлять трафик для другой сети через конечную точку OpenVPN.