Несколько дней назад в маршрутизаторе моего провайдера после отключения электричества поломался IPv4. К счастью, подключение по IPv6 продолжало работать, но доступна была только малая часть веб-сайтов.

В этом посте я расскажу, как на помощь мне пришли Linux, WireGuard и Hetzner, благодаря которым я смог получить доступ ко всему Интернету через одно лишь соединение IPv6.

Предыстория

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

Обратившись в поддержку провайдера, я осознал, что проблема возникла только у серверов с IPv4. Я мог подключаться к серверам IPv6 (благодаря чему Google и Meta* работали нормально), но большинство веб-сайтов не работало. Я запустил ping -6 и traceroute на своей машине и на странице диагностики маршрутизатора, и убедился, что это действительно так. Похоже было, что проблема была связана с Carrier Grade NAT (CG-NAT), поэтому она затронула лишь IPv4.

К сожалению, провайдер сообщил, что, возможно, ему придётся отправить техников и это займёт несколько дней, к тому же заняться этим он сможет после выходных. Мне же тем временем нужно было продолжать работать, а моей жене — дописать диссертацию, поэтому Интернет нам был необходим.

К счастью, я вспомнил, что у меня есть VPS-сервер Hetzner со статическими адресами IPv4 и IPv6. Повезло, что веб-сайт Hetzner поддерживает IPv6, поэтому я мог добраться до консоли и всё настроить.

Но для начала нужно было разобраться, что же такое Network Address Translation (NAT).

Network Address Translation (NAT)

Адреса Internet Protocol (IP) используются для указания источника и получателя IP-трафика. Это можно сравнить с отправкой письма с обратным адресом: мы передаём на сервер пакет с его IP-адресом (возможно, полученным ресолвингом из имени домена), а он возвращает ответ из адреса получателя для полученного пакета.

Однако адреса IPv4 имеют длину всего 32 бита, поэтому, если вычесть различные зарезервированные блоки, останется всего около 3,7 миллиарда вариантов публичных адресов IPv4. Сегодня почти у каждого человека есть мобильный телефон с подключением к Интернету, а также, возможно, несколько компьютеров, умных часов, телевизоров и так далее. Все они подключены одновременно, поэтому нам просто не хватит адресов для прямой адресации всех устройств в Интернете.

NAT частично решает эту проблему, давая множеству устройств один IP-адрес. Например, домашнему маршрутизатору может быть назначен лишь один публичный адрес IPv4, общий для всех устройств. Когда маршрутизатор получает пакет от одного из устройств, он заменяет исходный IP-адрес (то есть локальный IP-адрес устройства вида 192.168.1.xxx) публичным.

Система отслеживания соединений маршрутизатора (conntrack) записывает исходный IP и порт. При передаче пакета он заменяет исходный адрес собственным публичным IP и уникальным портом, сохраняя эту привязку. Когда на этот уникальный порт поступает ответ, conntrack заменяет адрес получателя внутренним IP и портом исходного устройства. В Linux сохранённые привязки можно просмотреть при помощи команды conntrack -L из conntrack-tools.

Это похоже на отправку письма в офис с указанием лишь фамилии получателя и номера офисного здания. При получении письма секретарь (NAT) передаёт письмо сотруднику и получает его ответ, не зная конкретного номера стола и местоположения источника. Снаружи мы всегда будем видеть лишь адрес офисного здания (маршрутизатора, выполняющего NAT).

Также эта система косвенно используется в качестве файрвола, потому что все сервисы в локальных устройствах за маршрутизатором должны явным образом выполнять переадресацию портов, то есть маршрутизатор перенаправляет весь трафик, полученный на конкретный порт, конкретному устройству и порту (и наоборот), модифицируя пакеты, как это было описано в примере выше.

Но одного лишь уровня домашних маршрутизаторов недостаточно для решения проблемы дефицита адресов IPv4. Поэтому многие Интернет-провайдеры поддерживают эту технологию и внутри своих систем; это называется Carrier Grade NAT (CG-NAT). Её концепция аналогична, только вместо домашнего маршрутизатора, выполняющего NAT для множества локальных устройств, маршрутизатор Интернет-провайдера выполняет NAT множества домашних маршрутизаторов (которые продолжают выполнять свой NAT локальных устройств).

В зависимости от того, каким количеством адресов IPv4 владеет провайдер и какую его часть он готов выделить, этот процесс может повторяться на нескольких уровнях иерархии, например, для разных регионов, в которых действует провайдер.

Именно из-за этого процесса авария затронула только IPv4 — где-то внутри иерархии Carrier Grade NAT перестал происходить корректный NAT пакетов, приводя к утере пакетов и полному прекращению трафика IPv4.

Стоит отметить, что это может стать проблемой и в том случае, если вы хотите переадресовывать сервисы с локальных устройств (например, игровых серверов) в Интернет — возможно, вам потребуется попросить провайдера распространить вашу переадресацию портов на CG-NAT, а многие провайдеры полностью это ограничивают. Крайне рекомендую прочитать статью Tailscale How NAT Traversal Works о различных способах обхода этой проблемы — это лучшая из прочитанных мной статья о сетевых технологиях.

IPv6

У IPv6 так много доступных адресов, что использование NAT не требуется (но при желании его всё равно можно применять; например, для упрощения правил файрвола, хотя это используется не так часто, учитывая, что прямая маршрутизация гораздо производительнее).

Адреса IPv6 имеют длину 128 бит, поэтому даже с учётом зарезервированных блоков остаётся примерно 3,4 ⋅ 10³⁸ адресов.

Из-за такого избытка адресов домашнему маршрутизатору часто выделяют подсети /64. Это даёт нам 1,84 ⋅ 10¹⁹ адресов — больше, чем достаточно для всех умных часов, телевизоров, холодильников, зеркал и лампочек.

Поэтому при использовании IPv6 в домашнем маршрутизаторе даже не требуется NAT, а все устройства можно напрямую адресовать из Интернета без проблемы с переадресацией портов. Однако это также означает, что у маршрутизатора и/или самих устройств должны быть настроены правила файрвола, чтобы к их открытым портам не могли выполняться произвольные новые подключения из любой точки Интернета.

Именно поэтому к IPv6 не применяется CG-NAT, из-за чего на него и не повлияла авария.

К сожалению, многие веб-сервисы всё равно недоступны через IPv6 (на момент написания статьи самым важным из таких ресурсов для меня был GitHub!). Это значило, что для восстановления функциональности IPv4 необходимо туннелировать трафик через IPv6: если у нас есть только адрес IPv6, то и общаться мы можем только с серверами, тоже имеющими адреса IPv6.

WireGuard-туннель

Мой план был простым: настроить WireGuard в VPS (установив wireguard-tools), а затем использовать адрес IPv6 в качестве конечной точки на клиентской стороне моей машины. После создания туннеля трафик IPv4 должен работать обычным образом (хоть и с повышенными задержками из-за VPS) — что-то типа создания собственного Dual-Stack Lite (DS Lite, не путать с консолью Nintendo!).

Раньше я использовал vps2arch на своём сервере для установки Arch Linux, который работал очень хорошо; я был рад, что сделал это, потому что теперь мог работать в знакомой среде. В качестве базы я использовал самый свежий образ Debian оператора Hetzner. Стоит отметить, что, вероятно, можно затем установить вручную Arch Linux при помощи монтирования образа ISO Hetzner (у него есть и ISO Arch Linux, вам не придётся настраивать собственный).

Поначалу у меня возникли сложности с работой трафика IPv6 в туннеле, но в конечном итоге я всё настроил. Ниже приведу пример моей полной конфигурации (адаптированной из примера в ArchWiki, но с добавлением трафика IPv6):

На стороне сервера

Конфигурация стороны сервера (демонстрирующая работу и через NAT, и напрямую через IPv6):

# Это конфигурация сервера
# Поместите её в /etc/wireguard/wg0.conf
# Установите wireguard-tools
# А затем запустите следующей командой:
# sudo wg-quick up wg0
# Также можно настроить сервис с помощью systemd
# systemctl enable wg-quick@wg0.service
# systemctl start wg-quick@wg0.service

# Сгенерируйте пары ключей WireGuard:
# wg genkey | (umask 0077 && tee peer_A.key) | wg pubkey > peer_A.pub
# Сделайте это один раз для пары сервера и по разу для каждой пары клиентов

[Interface]
Address = 10.200.200.1/24, fd42:42:42::1/64, 2001:db8:abcd:1234::1/128
ListenPort = 51820
PrivateKey = serverprivatekey # ИЗМЕНИТЬ: указать здесь приватный ключ сервера

# Здесь мы подразумеваем, что устройство использует сетевой интерфейс eth0 - не забудьте это проверить!
# Переадресация IPv4 при помощи NAT - стоит отметить, что здесь лучше использовать SNAT,
# если публичный IPv4 статичен, но я оставил это в качестве примера MASQUERADE
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# IPv6 NAT только для ULA (не GUA)
# Здесь мы используем для примера SNAT вместо MASQUERADE (предполагаем, что IPv6 GUA сервера статичен)
PostUp = ip6tables -t nat -A POSTROUTING -s fd42:42:42::/64 -o eth0 -j SNAT --to-source 2001:db8:abcd:1234::1
# Переадресация IPv6 (также для ULA и GUA с NAT)
PostUp = ip6tables -A FORWARD -i %i -j ACCEPT; ip6tables -A FORWARD -o %i -j ACCEPT
PostUp = echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
PostUp = echo 1 > /proc/sys/net/ipv4/conf/all/forwarding

PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PostDown = ip6tables -t nat -D POSTROUTING -s fd42:42:42::/64 -o eth0 -j SNAT --to-source 2001:db8:abcd:1234::1
PostDown = ip6tables -D FORWARD -i %i -j ACCEPT; ip6tables -D FORWARD -o %i -j ACCEPT

# Этот пир имеет непосредственный адрес IPv6 Global Unicast Address (без IPv6 NAT)
[Peer]
# foo
PublicKey = clientpublickey # ИЗМЕНИТЬ: указать публичный ключ клиента
AllowedIPs = 10.200.200.2/32, 2001:db8:abcd:1234::2/128


# Этот пир использует IPv6 с NAT и ему присвоен Unique Local Address
[Peer]
# bar
PublicKey = client2publickey # ИЗМЕНИТЬ: указать публичный ключ клиента 2
AllowedIPs = 10.200.200.3/32, fd42:42:42::3/128

Здесь стоит сказать, что в отличие от файлов конфигурации в стиле .ini, wg-quick позволяет многократно указывать PostUp и PostDown, и он будет выполнять каждую команду по порядку. См. исходники bash-скрипта.

IPv6 NAT через MASQUERADE

Также стоит отметить, что я изначально использовал NAT с IPv6 (не только с IPv4, где он необходим) с показанной выше конфигурацией bar. Но если у вас есть блок адресов для VPS (например, Hetzner выделил вам блок /64 под IPv6), то можно отказаться от NAT и сделать пиры WireGuard адресуемыми через IPv6 Global Unicast Address (GUA), как сказано выше в разделе, посвящённом NAT — это показано в конфигурации foo.

Мы просто заменим Unique Local Address (ULA) пиров и интерфейса непосредственно на публичные адреса IPv6, а затем удалим правило ip6tables MASQUERADE. Теперь каждый из пиров можно будет адресовать напрямую из Интернета по выделенным им адресам IPv6.

Если вы хотите переадресовывать множество устройств с их собственными сервисами, то определённо стоит делать так (кроме того, придётся проверить, корректно ли правила файрвола в VPS обрабатывают входящий трафик).

Правило SNAT

Так же стоит отметить, что можно использовать SNAT вместо MASQUERADE, если у вас есть в VPS статический IP-адрес и вы уверены, что он не поменяется. Это будет чуть более эффективно, потому что при правиле MASQUERADE IP-адрес интерфейса необходимо искать в среде выполнения, а в правиле SNAT его можно задать напрямую.

Это продемонстрировано в конфигурации для IPv6 NAT, где вместо MASQUERADE используется SNAT с --to-source.

На стороне клиента

Клиентская конфигурация:

Пир foo с прямым IPv6:

# Это клиентская конфигурация, выполняемая на клиентской машине следующим образом:
# sudo wg-quick up ./foo.conf
# from wireguard-tools
[Interface]
Address = 10.200.200.2/32, 2001:db8:abcd:1234::2/128
PrivateKey = clientprivatekey # ИЗМЕНИТЬ: указать приватный ключ клиента
# Google DNS
DNS = 8.8.8.8
DNS = 2001:4860:4860::8888
MTU = 1280 # Этого не было в исходной конфигурации, см. ниже

[Peer]
PublicKey = serverpublickey # ИЗМЕНИТЬ: указать публичный ключ сервера
# Имейте в виду, что для IPv6 нужны квадратные скобки
Endpoint = [2001:db8:abcd:1234::1]:51820 # ИЗМЕНИТЬ: здесь измените serveripv6! Если используется IPv4, то квадратные скобки не нужны
AllowedIPs = 0.0.0.0/0, ::/0

Пир bar с IPv6 NAT:

# Это клиентская конфигурация, запускаемая на клиентской машине следующим образом:
# sudo wg-quick up ./bar.conf
# from wireguard-tools
[Interface]
Address = 10.200.200.3/32, fd42:42:42::3/128
PrivateKey = clientprivatekey # ИЗМЕНИТЬ: указать приватный ключ клиента
# Google DNS
DNS = 8.8.8.8
DNS = 2001:4860:4860::8888
MTU = 1280 # Этого не было в исходной конфигурации - см. ниже

[Peer]
PublicKey = serverpublickey # ИЗМЕНИТЬ: указать публичный ключ сервера
# Имейте в виду, что для IPv6 нужны квадратные скобки
Endpoint = [2001:db8:abcd:1234::1]:51820 # ИЗМЕНИТЬ: здесь измените serveripv6! Если используется IPv4, то квадратные скобки не нужны
AllowedIPs = 0.0.0.0/0, ::/0

При запуске с обеих сторон всё работает без проблем. Я даже могу напрямую подключаться через SSH к локальным для туннеля адресам IPv4 и IPv6 для доступа к серверу.

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

Однако я всё равно не мог подключиться таким образом к рабочему VPN, потому что это бы помешало подключению WireGuard.

Сетевые пространства имён

Я разрабатываю vopono, поэтому мой план был таким: запустить рабочий VPN и все необходимые приложения в сетевом пространстве имён. Сложность заключалась в том, чтобы создать правило MASQUERADE для переадресации трафика на интерфейс WireGuard (см. выше foo или bar), а не напрямую на реальный сетевой интерфейс (enpXsY).

Благодаря этому трафик внутри сетевого пространства имён будет безразличен к правилам nftables WireGuard-туннеля (из wg-quick) снаружи хоста, но трафик будет маршрутизироваться через WireGuard-туннель.

Стоит также отметить следующее: несмотря на то, что wg-quick по возможности предпочитает использовать nftables вместо iptables, ему удаётся избегать конфликтов со стандартными правилами iptables Docker.

Вот диаграмма случая с NAT (конфигурация bar) с сетевым пространством имён (vo_none_none): 

Мы можем реализовать это при помощи vopono, указав работающий интерфейс WireGuard (в этом примере — bar) аргументом -i. Всё вместе это будет выглядеть так:

$ vopono -v exec --create-netns-only --provider None --protocol None -i bar bash
$ sudo ip netns exec vo_none_none bash
$ (inside netns) ./vpn.sh  # Скрипт для запуска рабочего VPN

Обратите внимание, что /etc/netns/vo_none_none/ будет примонтирован к /etc в пространстве монтирования командой ip netns exec. Это значит, что мы можем указать в этом resolv.conf конкретные серверы DNS. Учтите, что можно сделать то же самое, изменив gai.conf, если, например, хотите отдать предпочтение ресолвингу IPv4 DNS в сетевом пространстве имён.

Когда мне не удавалось заставить работать трафик IPv6 через туннель, я выбрал последний вариант. Ниже приведён для справки мой gai.conf (адаптированный из ответа на AskUbuntu):

precedence ::ffff:0:0/96 100
#    В случае сайтов, использующих локальные для сайта адреса IPv4 за NAT,
#    существует проблема: даже если предпочтительны адреса IPv4, у них разный
#    scope, а потому они сортируются не первыми. Это можно исправить,
#    если использовать только эти правила:
#
scopev4 ::ffff:169.254.0.0/112  2
scopev4 ::ffff:127.0.0.0/104    2
scopev4 ::ffff:0.0.0.0/96       14

Итак, после подключения к VPN, как это показано выше, мы можем указать внутренние серверы DNS в /etc/netns/vo_none_none/resolv.conf, чтобы всё работало для следующих приложений, запущенных в сетевом пространстве имён. Немного неприятно, что нам приходится делать это после подключения (потому что до него мы не можем получить доступ к этим серверам), но поскольку пространство имён монтирования ограничено каждым вызовом ip netns exec, это невозможно сделать в скрипте (если только мы не будем выполнять всё внутри одной bash-сессии и не будем повторно использовать ip netns exec).

После этого мы сможем запускать приложения, как обычный пользователь в сетевом пространстве имён (теперь через рабочий VPN, с запущенным в другой сессии скриптом vpn.sh):

$ vopono -v exec -i bar --provider None --protocol None google-chrome-stable

Но есть ещё одна проблема, не позволяющая выполнять всё необходимое через VPN — Docker.

Docker

Наивный запуск Docker аналогично другим приложениям не сработает — сокет Docker создан снаружи сетевого пространства имён (при помощи systemd), поэтому никакого внутреннего соединения у нас нет.

Однако если мы остановим Docker снаружи, а потом попробуем просто запустить демона Docker и создать сокет в сетевом пространстве имён, то это тоже не сработает, потому что ip netns exec создаёт пространство имён монтирования и перемонтирует /sys, а значит, /sys/fs/cgroup нашего хоста будет невидима.

Мы получим ошибку такого вида:

Error: OCI runtime error: runc: runc create failed: no cgroup mount found in mountinfo

(Примечание: на самом деле, я думаю, что эта ошибка происходит при тестировании с podman-docker)

Мы можем обойти эту проблему при помощи следующих команд:

$ (on host) sudo systemctl stop docker && sudo systemctl stop docker.socket
$ (on host) sudo -E unshare -m sh -c 'mount --bind /sys /sys; exec ip netns exec vo_none_none sudo --user youruser --preserve-env bash'
$ (in netns) sudo umount /sys
$ (in netns) sudo dockerd --host=unix:///var/run/docker-netns.sock --data-root=/var/lib/docker-netns
$ (in netns) DOCKER_OPTS="--dns=YOURDNSHERE" DOCKER_HOST=unix:///var/run/docker-netns.sock sudo --user youruser --preserve-env docker ... # здесь ваша команда docker

Эти команды были адаптированы из поста Unix StackExchange. Хитрость заключается в применении unshare для принудительного bind mount /sys в пространстве имён монтирования, созданном ip netns exec, с последующим демонтированием внутреннего монтирования /sys, созданного ip netns exec; благодаря этому /sys внутри пространства имён монтирования становится bind mount /sys хоста.

Команды затронут только этот вызов ip netns exec. Но затем мы можем запустить dockerd и команду Docker в той же сессии внутри сетевого пространства имён, чтобы для них обоих пространство имён монтирования было одинаковым.

Помните, что можно также настроить параметры DNS Docker в /etc/netns/vo_none_none/docker/daemon.json.

Стоит также отметить, что это сработало у меня (в том числе и для контейнера, использующего сеть Docker для подключения к вспомогательному контейнеру), но может не сработать в более сложных системах Docker, которым нужны bridge и тому подобное (однако я уверен, что технически это возможно).

Проблемы MTU WireGuard

После перезапуска моей машины у меня возникли проблемы с соединением WireGuard: загружалось лишь несколько страниц, а некоторые, например, GitHub, вообще не работали, хотя ping и ping -6 выполнялись идеально.

Эту проблему было очень сложно отладить — даже wg show показывала, что соединение WireGuard работает нормально. В конечном итоге, я нашёл причину, выполнив пинги разного размера:

$ ping6 -s 1400 fd42:42:42::1
$ ping6 -s 1200 fd42:42:42::1
$ ping6 -s 800 fd42:42:42::1

В этом случае первый был неудачным, а остальные сработали. Это дало мне понять, что проблемы с соединением вызваны параметром MTU WireGuard — большие пакеты отбрасывались. Я уменьшил MTU, и проблема полностью пропала (это отражено в показанной выше конфигурации).

Maximum Transmission Unit (MTU) — это наибольший размер пакета, который может обрабатывать интерфейс. Задав MTU меньшего размера в локальном интерфейсе WireGuard, мы приказываем IP-стеку ядра не создавать пакеты больше указанной величины. Благодаря этому после того, как WireGuard добавит свой оверхед инкапсуляции, конечный пакет UDP, отправляемый по Интернету, будет достаточно мал, чтобы не быть отброшенным ни на одном из участков пути с малым MTU.

При отправке пакета на удалённый сервер он перемещается через множество маршрутизаторов (и подводных кабелей). У каждого из этих маршрутизаторов есть собственный MTU, и они отбрасывают пакеты большего размера.

Можно сказать, что это аналог ограничения по весу у почтовой службы. Если вы хотите отправить посылку весом двадцать килограмм в другую страну, недостаточно того, чтобы почтовая служба вашей страны принимала такие тяжёлые посылки, их должна принимать и международная авиапочтовая служба, и почтовая служба страны, в которой живёт друг. Иначе посылка просто не дойдёт.

Поэтому если задать слишком высокое значение MTU, то при превышении MTU на маршруте (то есть наименьшего MTU среди всех переходов) наши пакеты будут отбрасываться. Это приводит к непонятному поведению: некоторые пакеты, например, пинг, достаточно малы, чтобы на них не влиял MTU, однако отбрасывание больших пакетов приводит к сбоям подключения, например, при попытке связи через HTTPS.

Стоит отметить, что эта проблема актуальнее при туннелировании трафика, например, через WireGuard, потому что мы добавляем примерно 32 байт оверхеда от дополнительной инкапсуляции; к тому же мы вряд ли будем получать от промежуточных маршрутизаторов сообщения Path MTU Discovery (PMTUD), которые бы информировали о проблемах с MTU и позволили бы настроить его автоматически, поскольку эти сообщения Internet Control Message Protocol (ICMP) часто отсекаются файрволами.

Минимальный MTU по спецификации IPv6 — это 1280, поэтому это значение всегда подойдёт для туннеля через IPv6.

В заключение

В этой статье мы раскрыли следующие темы:

• Создание VPN-сервера WireGuard на VPS с трафиком IPv4 и IPv6 (прямым и через NAT).

• Использование сетевого пространства имён для запуска другого VPN через этот интерфейс WireGuard.

• Применение трюков с unshare для запуска Docker внутри этого сетевого пространства имён.

• Отладка проблем MTU при использовании WireGuard.

При удалённой работе проблемы подключения к Интернету всегда представляют риск; к счастью, в моём случае на выручку пришёл Linux. Благодаря нему мне не пришлось ждать, пока провайдер починит свою конфигурацию.

Надеюсь, эта статья окажется полезной другим людям (а может быть, и мне в будущем!). Она наглядно продемонстрировала преимущества подхода Linux «почини сам». Компьютеры Mac привлекательны своими мощными процессорами M4, но я понятия не имею, как провернуть всё это в macOS (а мой последний опыт работы с macOS был неидеальным!).

Эта ситуация заставила меня задуматься о приобретении маршрутизатора с OpenWRT. Раньше я думал, что возня с собственным маршрутизатором — это лишняя работа (забавно, что многие люди, вероятно, думают так же о GNU/Linux), но возможность расширенной отладки на стороне маршрутизатора окажется очень полезной при возникновении подобных проблем; да и в целом удобен простой запуск WireGuard непосредственно в маршрутизаторе без необходимости настраивать его отдельно на каждом устройстве.

*Meta запрещена в России как экстремистская.