Цель
Я пытаюсь настроить WireGuard VPN только с IPv6, через который я (a) хочу направлять весь трафик и (b) с сервером, доступным из интернета. Поскольку я даже не смог заставить работать (a), я просто попробую заставить работать это, (b) просто для контекста.
У меня есть VPS с глобально маршрутизируемым IPv6, 2a03:4000:xx:xx:18d7:b1ef:fe48:7d35/64
(это то, что ip a
мне говорит) на eth0
. Я буду ссылаться на него с именем хоста vps
. Для целей тестирования на сервере нет брандмауэра, и net.ipv6.conf.all.forwarding=1
и
net.ipv6.conf.all.accept_ra=2
.
2001:1715:yy:yy:db2d:ab24:ed3f:39d4/64
Затем у меня также есть мое устройство, которое также имеет адрес IPv6 wlan0
(это не должно быть важной информацией, так как этот адрес изменится, когда я буду в другой беспроводной локальной сети). Оно несет имя хоста laptop
.
Я хочу получить что-то вроде этого:
Internet <-> vps <-> laptop
С IPv4 я бы использовал NAT, однако в мире IPv6 NAT не рекомендуется. Трудно понять, что делать вместо этого, но если я правильно прочитал, то мне следует дать другой IP-адрес из блока, который 2a03:4000:xx:xx::/64
получил VPS, ноутбуку.
Настраивать
Итак, я пишу эти две конфигурации Wireguard:
ВПС:
[Interface]
Address = fc01::1/128 # Shouldn't really matter?
ListenPort = 1935 # This port is open to UDP on most networks
PrivateKey = uLxxxxxxxxxxxxxxxxxxxxxxxxEQ=
[Peer]
# laptop
PublicKey = swxxxxxxxxxxxxxxxxxxxxxxxxxmQ=
AllowedIPs = 2a03:4000:xx:xx:ffff::3/128 # Is inside the vps' /64 block
Ноутбук:
[Interface]
Address = 2a03:4000:xx:xx:ffff::3/128 # The globally routable IP addr of my laptop via the vps
ListenPort = 1935
PrivateKey = yMxxxxxxxxxxxxxxxxxxxxxxxxxxxxm8=
[Peer]
PublicKey = pCxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzs=
AllowedIPs = ::/0 # Route all traffic through this peer
Endpoint = [2a03:4000:xx:xx:18d7:b1ef:fe48:7d35]:1935
Я их поднимаю:
[root@vps ~]# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -6 address add fc01::1/128 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -6 route add 2a03:4000:xx:xx:ffff::3/128 dev wg0
[root@laptop ~]# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -6 address add 2a03:4000:xx:xx:ffff::3/128 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] wg set wg0 fwmark 51820
[#] ip -6 route add ::/0 dev wg0 table 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip6tables-restore -n
... иииии это не работает.
WireGuard, похоже, не подключается успешно. Ноутбук показывает подключение и считает отправленный трафик (но полученный 0B), но VPS не показывает подключение.
Как правильно настроить WireGuard VPN только для IPv6? И если это правильно, почему трафик, отправленный на один конец, не доходит до другого конца туннеля?
Если дополнительная информация (PCAP, ip
выходные данные и т. д.) будет полезна, я с радостью изменю вопрос.
решение1
Это не работает, потому что шлюз вашего сервера предполагает,весь /64 находится «на связи», то есть каждый адрес напрямую доступен в одном и том же сегменте Ethernet, поэтому шлюз отправляет запросы Neighbor Discovery на MAC-адрес вашего ноутбука, но не получает никакого ответа, поскольку ноутбук вообще не находится на том же соединении.
(Обычно сервер не отвечает от имени адресов, которые маршрутизируются куда-то еще — он отвечает только от адресов, которые напрямую назначены его собственному интерфейсу eth0.)
Чтобы это работало с адресами on-link, вам нужно будет использовать «прокси NDP», т.е. фактически сделать серверпредоставить ответы NDP от имени ноутбука(и любой другой адрес, который вы пытаетесь маршрутизировать через туннель).
Самый надежный способ сделать это для IPv6 — запустить ndpresponder
демон на eth0. Он будет прослушивать пакеты Neighbor Solicitation и отправлять правильные Neighbor Advertisements.
(Аналогично вы можете использовать ndppd
или даже встроенную proxy_ndp
функцию ядра, но они ведут себянемного(Отличаются от настоящих ответов NDP и иногда не проходят проверки на предмет подделки, которые проводят некоторые операторы хостинга VPS.)
В идеале, однако, хостинговая компаниядолжен предоставить вамразосланныйпрефикс– тот, где шлюз центра обработки данных явно настроен на маршрутизацию всего «через» основной адрес вашего сервера. Это также будет немного выгодно для них, поскольку один статический маршрут будет эффективнее, чем множество динамических записей кэша соседей.
(К сожалению, многие компании, предоставляющие услуги хостинга серверов, используют внутри компании определенную платформу управления VPS, которая не позволяет им предлагать маршрутизируемые префиксы. Я слышал, что это вина SolusVM, которая настаивает на модели «flat on-link /48».)
Примечание: Это никоим образом не относится к IPv6 — такое же различие между «on-link» и «routed» существует в IPv4, с той лишь разницей, что IPv4 использует ARP вместо NDP. (Например, если ваш сервер находится в 192.168.1.0/24 на eth0, и вы хотите направить 192.168.1.7 к VPN-клиенту, у вас будет точно такая же проблема, и вам понадобится proxy-ARP, чтобы обойти ее.)