Имеется OpenVPN (на Ubuntu 14.04) сервер и некоторое количество клиентов (на Windows, Linux, Android).
Задача, вроде бы, простая: направить трафик от всех клиентов через другого клиента.
Т.е., допустим, сервер 10.15.1.1, клиенты 10.15.1.0/24. Направить запросы на 8.8.8.8 через 10.15.1.10.
На клиенте Linux средствами ОС добавляю маршрут: route add -host 8.8.8.8 gw 10.15.1.10 (знаю, что можно со стороны сервера клиенту маршрут пихать - сейчас вопрос не в том каким образом маршрут на клиенте появляется). Запросы приходят на 10.15.1.10 только если это tap-интерфейс. Всё бы хорошо, но Android-клиент tap не поддерживает, только tun (Android не рутованный, приложения: "OpenVPN" и "OpenVPN Connect").
Если на клиентах и сервере использовать tun (dev-type tun) - запросы на 10.15.1.10 не приходят. Через tcpdump я их вижу на 10.15.1.1.
Т.е. происходит вот что. Клиент пингует 8.8.8.8 и в ответ получает сообщение от сервера:
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 10.15.1.1: icmp_seq=2 Redirect Host(New nexthop: 10.15.1.10)
From 10.15.1.1: icmp_seq=3 Redirect Host(New nexthop: 10.15.1.10)
При этом на сервере:
14:21:56.417458 IP 10.15.1.1 > 10.15.1.12: ICMP redirect 8.8.8.8 to host 10.15.1.10, length 92
14:21:56.417460 IP 10.15.1.12 > 8.8.8.8: ICMP echo request, id 13221, seq 6, length 64
Т.е. сообщение по итогу приходят на сервер, сервер говорит клиенту отправлять запросы на 10.15.1.10, сам он их туда не отправляет.
Тогда я попробовал на сервере создать маршрутизацию для пакетов клиента:
ip route add default via 10.15.1.10 table 9999
ip rule add from 10.15.1.0/24 table 9999 priority 2
Опять та же картина: клиенту прилетает
Redirect Host(New nexthop: 10.15.1.10), а сервер сам не желает перенаправлять пакеты от клиента на 10.15.1.10.
При этом на стороне 10.15.1.10 пакетов не видно (пусто в tcpdump). Хотя пинги между клиентами и 10.15.1.10 проходят замечательно. Как только везде меняю на режим tap (который мне не подходит) - всё работает.
У меня сначала картина в голове была такая: в режиме tap клиенту прилетает
Redirect Host(New nexthop: 10.15.1.10), он делает ARP-резолвинг 10.15.1.10, получает его MAC и шлёт данные ему. В режиме tun нету ARP. И клиент, получая
Redirect Host(New nexthop: 10.15.1.10), не может направлять напрямую на 10.15.1.10 и вынужден делать это через сервер. Но когда пинги между клиентами успешно ходят - их не видно на сервере через tcpdump.
Дополнительно неясно почему сервер, получив пакет от клиента, шлёт ему
Redirect Host(New nexthop: 10.15.1.10), а не пересылает самостоятельно на 10.15.1.10.
Маршрут по-умолчанию через 10.15.1.1 удалять пробовал - не помогает (это маршрут, который сервер клиентам сообщает).
На сервере выполнено:
sysctl -w net.ipv4.ip_forward=1
iptables -P FORWARD ACCEPT
Может, какие-то настройки в sysctl ещё нужны?
Конфиг сервера:
port 1194
proto udp
dev tun0
user openvpn
group openvpn
cd /etc/openvpn
persist-key
persist-tun
tls-server
tls-timeout 120
dh /etc/openvpn/dh.pem
ca /etc/openvpn/ca.crt
cert /etc/openvpn/myopenvpnserver.crt
key /etc/openvpn/myopenvpnserver.key
crl-verify /etc/openvpn/crl.pem
tls-auth /etc/openvpn/ta.key 0
server 10.15.1.0 255.255.255.0
client-config-dir /etc/openvpn/ccd
client-to-client
topology subnet
push "dhcp-option DNS 8.8.4.4"
route 10.15.1.0 255.255.255.0
comp-lzo
keepalive 10 120
status /etc/openvpn/log/openvpn-status.log 1
status-version 3
log-append /etc/openvpn/log/openvpn-server.log
verb 3
mute 20
push "redirect-gateway def1"
ifconfig-pool-persist /etc/openvpn/ipp.txt
management localhost 8000
Конфиг клиента:
dev tun1
proto udp
nobind
remote 1.1.1.1 1194
client
tls-client
resolv-retry infinite
remote-cert-tls server
persist-key
persist-tun
comp-lzo
verb 3
tun-mtu 1280
status-version 3
script-security 2
key-direction 1
Средний
Средний
