У меня есть сеть, которая подключена к сети и доступна через туннель tun0. Этот tun0 запускается со скриптом Python следующим образом:
tun_name = 'tun0'.encode()
ifs = ioctl(self.virtualIf, TUNSETIFF, struct.pack("16sH", tun_name, IFF_TUN))
self.ifname = tun_name.decode()
print('[NetworkSideThread] Created virtual interface '+self.ifname+'.')
# configure IPv6 addresses of virtual interface
subprocess.check_call(CMD_IFCONFIG + ' ' + self.ifname + ' up', shell=True)
subprocess.check_call(CMD_IFCONFIG + ' ' + self.ifname + ' inet6 add ' + self.prefix + '::1/64', shell=True)
subprocess.check_call(CMD_IFCONFIG + ' ' + self.ifname + ' inet6 add fe80::1/64', shell=True)
print('[NetworkSideThread] Configured IPv6 address')
# set static route
subprocess.check_call(CMD_ROUTE+' -A inet6 add ' + self.prefix + '::/64 dev ' + self.ifname, shell=True)
Все устройства в сети имеют адрес bbbb:: (например, bbbb:: 17: d00: 30: 6fb6 и bbbb:: 17: d00: 30: 76f6). Цель состоит в том, чтобы трафик, отправляемый с 76f6 на 6fb6, поступал в туннель и затем корректно отправлялся на 6fb6.
Странная вещь: с вышеупомянутой конфигурацией это работает только время от времени!
Выполнение «маршрута -А инет6» раскрывает:
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2a02:2c40:500:a006::/64 [::] Ue 256 0 0 ens33
bbbb::/64 [::] U 1 3 290 tun0
bbbb::/64 [::] U 256 0 0 tun0
fe80::/64 [::] U 256 1 38 ens33
fe80::/64 [::] U 256 0 0 tun0
[::]/0 gateway UG 100 1 1 ens33
[::]/0 [::] !n -1 1 16599 lo
ip6-localhost/128 [::] Un 0 5882117 lo
2a02:2c40:500:a006::/128 [::] Un 0 4 3 lo
ubuntu/128 [::] Un 0 1 0 lo
ubuntu/128 [::] Un 0 3 82 lo
bbbb::/128 [::] Un 0 3 5 lo
ubuntu/128 [::] Un 0 4 57 lo
fe80::/128 [::] Un 0 3 6 lo
fe80::/128 [::] Un 0 1 0 lo
ubuntu/128 [::] Un 0 1 0 lo
ubuntu/128 [::] Un 0 1 0 lo
ubuntu/128 [::] Un 0 3 33 lo
ip6-mcastprefix/8 [::] U 256 4 610 ens33
ip6-mcastprefix/8 [::] U 256 0 0 tun0
[::]/0 [::] !n -1 1 16600 lo
Я полагаю, что иногда трафик, отправляемый с 76f6 на 6fb6, идет по маршруту "2a02:2c40:500:a006::/64 [::] Ue 256 0 0 ens33", а иногда - "bbbb::/64 [::] U 1 3 290 tun0 "маршрут.
Во всех случаях, когда устройство отправляет на адрес bbbb, пакет должен быть введен через туннель в сеть bbbb.
Любой ключ к решению этой проблемы? Это странно, так как это не происходит последовательно.
Редактировать:
Запрашиваемая информация:
ip -6 route get bbbb::17:d00:30:6fb6
дает
bbbb:: 17: d00: 30: 6fb6 из :: dev tun0 src bbbb :: 1 метрика 1 привилегированная среда
а также
ip route show match bbbb::17:d00:30:6fb6
ничего не дает
Хм, ваш первый комментарий имеет смысл, поэтому моя первоначальная гипотеза неверна. Для дополнительной информации я добавил экранный снимок Wireshark в туннеле, который показывает идентичные пакеты в обоих случаях, когда он получен на 6fb6, а где нет (пакеты
Это, кажется, указывает на то, что я был неправ. Не сразу понять, в чем проблема - приемное устройство в некоторых случаях может быть сброшено, а в других - нет, но это будет странно.
Wireshark также дает те же результаты. Первые 3 пакета являются первой передачей и прибывают в пункт назначения, последние 3 пакета (хотя и идентичные) являются второй передачей и не приходят!
