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

Шлюз OpenVPN не отвечает на пинг IPv6, но пересылает пакет

Я пытаюсь отладить свою сеть IPv6 и столкнулся с проблемой, которую не могу понять.

Я использую OpenVPN в качестве своего VPN-сервера, и вот краткая схема настройки:

Все пакеты сбрасываются, когда я пытаюсь выполнить пинг от VPN-клиента (2001:470:7875:1::2) на VPN-сервер (2001:470:7875:1::1), но вот что любопытно:

Я могу пинговать любой Другой хост через IPv6 (например, Google) или любой другой клиент VPN, подключающийся к тому же серверу VPN через IPv6.

Я также могу пинговать свой VPN-сервер через его собственный интерфейс IPv6 (ens3). Это только интерфейс VPN-сервера (tun0), который не отвечает при прямом пинге.

Поэтому мне интересно, что происходит?

Поскольку у меня есть две ссылки IPv6 на версию Интернета IPv6, мне нужно выполнить маршрутизацию на основе политик. Правила довольно простые.

Это приводит меня к следующей таблице маршрутизации на сервере VPN:

Команда ip -6 rule show имеет следующую настройку:

0:      from all lookup local
32000:  from 2001:470:7875::/48 lookup openvpn
32766:  from all lookup main

Стол local:

local ::1 dev lo proto kernel metric 0 pref medium
anycast 2001:470:1f14:2c7:: dev he-ipv6 proto kernel metric 0 pref medium
local 2001:470:1f14:2c7::2 dev he-ipv6 proto kernel metric 0 pref medium
anycast 2001:470:7875:1:: dev tun0 proto kernel metric 0 pref medium
local 2001:470:7875:1::1 dev tun0 proto kernel metric 0 pref medium
anycast 2a01:xxx:xxxx:: dev ens3 proto kernel metric 0 pref medium
local 2a01:xxx:xxxx:xxx::1 dev ens3 proto kernel metric 0 pref medium
anycast fe80:: dev ens3 proto kernel metric 0 pref medium
anycast fe80:: dev tun0 proto kernel metric 0 pref medium
anycast fe80:: dev he-ipv6 proto kernel metric 0 pref medium
local fe80::95d2:9e6b dev he-ipv6 proto kernel metric 0 pref medium
local fe80::5054:ff:fe66:f97f dev ens3 proto kernel metric 0 pref medium
local fe80::af96:f1e3:dbf3:96a7 dev tun0 proto kernel metric 0 pref medium
ff00::/8 dev ens3 metric 256 pref medium
ff00::/8 dev tun0 metric 256 pref medium
ff00::/8 dev he-ipv6 metric 256 pref medium

Стол main:

local ::1 dev lo proto kernel metric 256 pref medium
2001:470:1f14:2c7::/64 dev he-ipv6 proto kernel metric 256 pref medium
2001:470:7875:1::/64 dev tun0 proto kernel metric 256 pref medium
unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium
2xxx:xxx:xxxx::/48 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
fe80::/64 dev he-ipv6 proto kernel metric 256 pref medium
default via 2a01:xxx:xxxx::1 dev ens3 metric 1024 pref medium

Стол openvpn:

unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium
default via 2001:470:1f14:2c7::1 dev he-ipv6 metric 1024 pref medium

Есть ли кто-нибудь, кто может меня подсказать? :-)

Краткий обзор недостижимых линий в таблице маршрутизации

2001:470:1f14:2c7::/64 dev he-ipv6 proto kernel metric 256 pref medium
2001:470:7875:1::/64 dev tun0 proto kernel metric 256 pref medium
unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium

Диапазон 2001:470:7875::/48 из 2001:470:7875:0:0:0:0:0 к 2001:470:7875:ffff:ffff:ffff:ffff:ffff.

Я назначил подсеть 2001:470:7875:1::/64 в туннель VPN.

Никакой другой диапазон IP-адресов не используется, но будет указан позднее.

Принимая во внимание выигрыш по самому длинному префиксу, мы получаем следующее поведение:

Так...

После дополнительных поисков я обнаружил, что мои настройки можно немного улучшить, хотя я не совсем уверен, что я охватил все свои основы.

Тем не мение ip -6 rule show можно немного подправить.

линия:

32000:  from 2001:470:7875::/48 lookup openvpn

Был сгенерирован следующей командой:

ip -6 rule add priority 32000 from 2001:470:7875::/48 table openvpn

Это можно упростить до:

ip -6 rule add priority 32000 iif tun0 to 2000::/3 table openvpn

Это означает, что в основном весь трафик на основе IPv6 должен искать в таблице. openvpn тогда и только тогда, когда трафик исходит от канала VPN и адрес назначения принадлежит 2003::/3, который представляет собой в основном весь официальный IPv6 Интернет, за исключением локальных адресов, таких как fe80 :: / 10 и fc :: / 7.

Конечным результатом является то, что трафик IPv6 из моего канала VPN всегда пересылается по каналу Hurricane Electric.

То, что нужно запомнить. Каждый раз, когда я добавляю новую подсеть из пула доступных адресов в 2001:470:7875::/48 диапазон я должен сделать две записи.

  • Один в таблице main, в котором рассказывается, как пересылать пакет с VPN-сервера в новую подсеть.
  • В таблице openvpn, который сообщает, как клиенты VPN могут попасть в новую подсеть. Обычно это происходит при межсайтовом трафике от одного клиента к другому по каналу VPN.

В любом случае: пинг теперь работает, и я все еще могу пинговать Google по IPv6.

Команда ip -6 rule show теперь дает следующий результат:

0:      from all lookup local
32000:  from all to 2000::/3 iif tun0 lookup openvpn
32766:  from all lookup main

Все остальное как есть из первоначального вопроса.

Traceroute был немного сложнее, но он работает до тех пор, пока выполняется с пакетами ICMP Echo.

Запуск команды traceroute -6 -I google.com на моем VPN-клиенте дал следующий след:

traceroute to google.com (2a00:1450:400e:80b::200e), 30 hops max, 80 byte packets
 1  2001:470:7875:1::1 (2001:470:7875:1::1)  16.868 ms  37.912 ms  37.847 ms
 2  tunnel547738.tunnel.tserv11.ams1.ipv6.he.net (2001:470:1f14:2c7::1)  37.777 ms  37.710 ms  37.647 ms
 3  10ge11-20.core1.ams1.he.net (2001:470:0:7d::1)  37.575 ms  37.509 ms  37.443 ms
 4  amsix-router.google.com (2001:7f8:1::a501:5169:1)  37.453 ms  52.425 ms  52.392 ms
 5  2001:4860:0:f8d::1 (2001:4860:0:f8d::1)  52.323 ms  52.259 ms  52.189 ms
 6  2001:4860:0:1::219f (2001:4860:0:1::219f)  36.456 ms  25.560 ms  18.169 ms
 7  ams17s01-in-x0e.1e100.net (2a00:1450:400e:80b::200e)  34.566 ms  34.502 ms  34.435 ms