У меня есть клиент (который также является шлюзом для сети 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.