Приветствую.
Пытаюсь сделать правильно роутинг некоторых маршрутов через vpn, используя железяку на openwrt (ядро 3.18.20). И столкнулся с проблемой, информации по которой не могу найти буквально нигде. Сырцы ядра еще не курил, но близок к тому.
Проблема. Есть стандартный набор правил для rule based routing:
ip rule add priority 103 fwmark 0x10/0x10 lookup vpn
ipset create vpn hash:net
ipset add vpn 8.8.8.8
iptables -t mangle -A OUTPUT -m set --match-set vpn dst -j MARK --set-mark 0x10
iptables -t mangle -A PREROUTING -i br-lan -m set --match-set vpn dst -j MARK --set-mark 0x10
ip route add default via 10.9.0.1 dev tun1 src 10.9.0.2 table vpn
Это — работает. То есть, компы за железякой благополучно ходят через tun1 для некоторых адресов и горя не знают.
Но! Локально сгенерированные пакеты ходить не хотят. Ни icmp, ни udp, ни tcp, ничего.
Смотрю tcpdump -i tun1, пускаю ping 8.8.8.8 и вижу радость:
# tcpdump -i tun1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun1, link-type RAW (Raw IP), capture size 65535 bytes
02:26:25.653753 IP 100.100.100.100 > 8.8.8.8: ICMP echo request, id 4230, seq 0, length 64
02:26:26.655484 IP 100.100.100.100 > 8.8.8.8: ICMP echo request, id 4230, seq 1, length 64
02:26:27.655723 IP 100.100.100.100 > 8.8.8.8: ICMP echo request, id 4230, seq 2, length 64
02:26:28.655963 IP 100.100.100.100 > 8.8.8.8: ICMP echo request, id 4230, seq 3, length 64
02:26:29.656196 IP 100.100.100.100 > 8.8.8.8: ICMP echo request, id 4230, seq 4, length 64
Где 100.100.100.100 — ip, выданный провайдером, висящий на локальном интерфейсе, отмеченном как default в таблице main.
При этом:
# ip route get 8.8.8.8 mark 0x10
8.8.8.8 via 10.9.0.1 dev tun1 src 10.9.0.2 mark 0x10
cache
Позвольте, но зачем тогда поле src в таблице роутинга? При этом, ping -I tun1 8.8.8.8 работает как надо, но объяснить dnsmasq что надо сокет открывать на конкретном интерфейсе, вроде бы, нельзя.
И вот дальше я пока не могу продвинуться. Пакеты с левым src ip даже не долетают до другого конца openvpn-туннеля, тоже не могу понять почему.
На другой железяке, x86, с 3.2.0-105-generic-pae такой проблемы, вроде бы, не наблюдается. Может быть, это известная бага ядра 3.18.20? Или, что скорее, я чего-то не понимаю?
