3

Мой провайдер не предоставляет IPv6-адреса клиентам (только один IPv4). У меня есть выделенный сервер со статическим IPv4-адресом и /64-блочным IPv6, поэтому я решил стать моим собственным туннельным брокером (6in4). Да, я могу использовать tunnerbroker.net, но я хочу научиться делать это самостоятельно.

Цель: предоставить туннель 6in4 от сервера с собственным подключением IPv4+IPv6(eth0) клиентам за домашним маршрутизатором только с IPv4.

Что я сделал:

Сторона сервера:

ip tunnel add sit5 mode sit ttl 255 remote [home_router_ipv4] local [server_ipv4]
ip link set dev sit5 up
ip -6 addr add [ipv6]::1/64 dev sit5
ip -6 route add [ipv6]::/64 via [ipv6]::2 dev sit5 metric 1
ip -6 neigh add proxy [ipv6]::2 dev eth0

Sysctl:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.proxy_ndp=1
net.ipv4.conf.all.accept_redirects=0
net.ipv6.conf.all.accept_redirects=0
net.ipv4.conf.all.send_redirects=0

Сторона клиента:

Маршрутизатор работает под управлением DD-WRT с собственной поддержкой туннелей 6in4 с radvd для передачи адресов клиентам (с успехом протестирован для tunnelbroker.net).

Radvd config:

interface br0
{
 IgnoreIfMissing on;
 AdvSendAdvert on;
 MinRtrAdvInterval 3;
 MaxRtrAdvInterval 10;
 AdvHomeAgentFlag off;
 AdvManagedFlag off;
 AdvOtherConfigFlag on;
 AdvLinkMTU 1480;
 prefix [ipv6]::/64
 {
  AdvOnLink on;
  AdvAutonomous on;
 };
 RDNSS [ipv6]::1 2620:0:ccd::2 {};
};

Проблема: Маршрутизатор правильно подключен через туннель к сети IPv6 (он может просматривать сеть ipv6), но клиенты этого не делают (они получают правильный адрес ipv6, но не могут ничего пропинговать, включая маршрутизатор и сервер).

Когда я делаю traceroute6 от сервера к клиенту, у меня есть цикл маршрутизации:

# traceroute6 [ipv6]:4d34:1981:aba6:620c
traceroute to [ipv6]:4d34:1981:aba6:620c ([ipv6]:4d34:1981:aba6:620c) from [ipv6]::1, 30 hops max, 24 byte packets
 1  [ipv6]::2 ([ipv6]::2)  43.446 ms  44.439 ms  39.687 ms
 2  [ipv6]::1 ([ipv6]::1)  41.955 ms  41.391 ms  43.225 ms
 3  [ipv6]::2 ([ipv6]::2)  80.456 ms  80.515 ms  81.893 ms
 4  [ipv6]::1 ([ipv6]::1)  81.966 ms  83.338 ms  92.166 ms
    ...

1 ответ1

1

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

(Обратите внимание, как Tunnelbroker также выделяет вам две подсети: одну /64 исключительно для связи точка-точка, плюс «маршрутизируемую» подсеть для локальной сети.)

Так что, если у вас есть только один /64, используйте его только для локальной сети. Туннель p2p будет отлично работать с локальной адресацией канала (или вообще без адресации, поскольку он является ссылкой p2p).

Так что вместо этих команд ...

ip -6 addr add [ipv6]::1/64 dev sit5
ip -6 route add [ipv6]::/64 via [ipv6]::2 dev sit5 metric 1

используйте что-то вроде этого:

ip -6 addr add fe80::1/64 dev sit5
ip -6 route add [ipv6]::/64 via fe80::2 dev sit5

или даже полностью ненумерованная ссылка:

# <no 'addr add' necessary>
ip -6 route add [ipv6]::/64 dev sit5

Конечно, настройте домашний маршрутизатор соответствующим образом - в этом примере он будет иметь адрес fe80::2/64 и использовать fe80::1 в качестве шлюза.

Примечание: вышеупомянутое не обязательно полное решение. У меня есть подозрение, что вы можете использовать один и тот же /64 на трех каналах одновременно (LAN, p2p и собственный eth0 сервера), что, вероятно, потребует еще большего количества бандитов, чем обычно.


Вторая проблема заключается в том, что, как я понял, ваш серверный провайдер настраивает /64 как подсеть по соединению , а не направляет ее к серверу.

Это довольно раздражающая (если, к сожалению, распространенная) проблема - соединение по ссылке означает, что вашему серверу потребуется прокси-сервер Neighbor Discovery для каждого отдельного адреса , используемого вашими устройствами локальной сети;

Таким образом, сам маршрутизатор имеет доступ к Интернету, потому что вы использовали эту команду:

ip -6 neigh add proxy [ipv6]::2 dev eth0

Но вам придется повторить это для каждого устройства, не говоря уже о временно сгенерированных адресах конфиденциальности, которые могут использовать ваши ПК.

Было бы лучше, если бы ваш провайдер сервера мог перенастроить /64 для перенаправления на ваш сервер (спросите их по электронной почте или, возможно, через билет) - это сделало бы прокси ND совершенно ненужным.

Если это невозможно, вам, возможно, придется запустить ndppd для ND-прокси всего /64.


В конце концов, может быть проще просто положиться на Tunnelbroker или NetAssist.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .