Настройка доступа к локальной сети через WireGuard

Почему ваша домашняя локальная сеть не отвечает через WireGuard

Чтобы маршрутизация в домашнюю локальную сеть через WireGuard работала, должны быть согласованы четыре отдельных параметра. Если настроены три из четырех, туннель выглядит полностью работоспособным, что и делает эту проблему такой запутанной. wg show сообщает о недавнем рукопожатии, ping 10.8.0.1 отвечает за несколько миллисекунд, а ping 192.168.20.10 не возвращает ничего.

Ниже приведен полный список в порядке прохождения пакета. LAN означает локальную сеть (local area network) — частную сеть за вашим домашним маршрутизатором.

1. AllowedIPs на клиенте должна охватывать удаленную подсеть, иначе пакет никогда не попадет в туннель.
2. AllowedIPs на сервере должна охватывать адрес туннеля клиента, иначе пакет будет отброшен сразу после расшифровки.
3. net.ipv4.ip_forward должна быть 1 на сервере, так как Linux отбрасывает любой пакет, который не адресован самому узлу.
4. Локальная сеть должна знать маршрут обратно к 10.8.0.0/24 через правило маскарадинга (masquerade) на сервере или статический маршрут на домашнем маршрутизаторе.

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

Используемая в руководстве сеть

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

• Домашняя локальная сеть — 192.168.20.0/24. Домашний маршрутизатор — 192.168.20.1.
• Сервер WireGuard — это Linux-машина в данной локальной сети. Её интерфейс локальной сети enp1s0 имеет адрес 192.168.20.5, а туннельный интерфейс wg0 — адрес 10.8.0.1.
• Хост, к которому требуется получить доступ, — это NAS (сетевое хранилище) с адресом 192.168.20.10.
• Клиент — это ноутбук, находящийся в другом месте, с адресом 10.8.0.2 внутри туннеля.

Сервер является машиной в локальной сети, а не самим маршрутизатором. Это стандартный случай: Raspberry Pi или старый мини-ПК. Это важно для правила 4: ваш маршрутизатор не знает о существовании туннеля, пока вы его об этом не уведомите, а каждый хост в локальной сети отправляет трафик за пределы подсети на этот маршрутизатор.

Если у вашего домашнего подключения нет публичного IP-адреса, этот метод не будет работать самостоятельно, так как никто из интернета не сможет инициировать рукопожатие с вашим домом. Раздел об использовании VPS в качестве промежуточного узла описывает этот случай. Там действуют те же четыре правила, с одним дополнительным узлом, который нужно учитывать.

AllowedIPs означает две разные вещи

Один параметр выполняет две задачи, и попытка интерпретировать его одинаково с обеих сторон — причина большинства подобных обращений в поддержку. WireGuard называет этот механизм криптографической маршрутизацией (cryptokey routing), подробнее об этом написано в том, как WireGuard привязывает публичные ключи к диапазонам IP.

При исходящем соединении AllowedIPs — это таблица маршрутизации. wg-quick превращает каждую запись в маршрут, указывающий на wg0. Пакет для 192.168.20.10 шифруется и отправляется узлу (peer) только в том случае, если какой-либо узел заявляет диапазон, содержащий этот адрес. Укажите только 10.8.0.0/24, и ваш ноутбук отправит трафик локальной сети через Wi-Fi, где он либо будет отброшен, либо достигнет совершенно другого 192.168.20.10.

При входящем соединении AllowedIPs — это список контроля доступа (ACL). После того как WireGuard расшифровывает пакет от узла, он сверяет внутренний адрес источника с AllowedIPs этого узла и отбрасывает пакет, если они не совпадают. Никакие записи в лог не добавляются, если не включена отладка ядра. Единственный след — счетчик ошибок приема в wg0, который выводит ip -s link show wg0, а сам пакет просто исчезает.

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

Соответствующая пара конфигурационных файлов

Клиент, /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <laptop private key>
Address = 10.8.0.2/32

[Peer]
PublicKey = <server public key>
Endpoint = home.example.com:51820
AllowedIPs = 10.8.0.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Сервер, /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <server private key>
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <laptop public key>
AllowedIPs = 10.8.0.2/32

На домашнем роутере также необходимо настроить проброс портов: UDP 51820 на 192.168.20.5, иначе рукопожатие (handshake) не начнётся, а в логах клиента появится Handshake for peer 1 did not complete after 5 seconds, retrying. Данное руководство предполагает, что этот этап вы уже прошли.

Четыре строки отличаются от стандартной настройки полного туннеля (full-tunnel), и каждое изменение внесено намеренно.

• AllowedIPs = 10.8.0.0/24, 192.168.20.0/24 на клиенте вместо 0.0.0.0/0, ::/0. Это раздельное туннелирование (split tunnel): подсеть туннеля и домашняя локальная сеть проходят через wg0, а весь остальной трафик использует локальный маршрут. Ваш веб-трафик не пойдёт через домашнее соединение, что обычно и требуется, если вам нужен только доступ к NAS.
• AllowedIPs = 10.8.0.2/32 на сервере: указан один адрес вместо диапазона. Если написать там 10.8.0.0/24, этот единственный клиент сможет присвоить себе любой адрес внутри туннеля. Если позже добавить второго пира с пересекающимся диапазоном, трафик будет перенаправляться на того пира, который был настроен последним, при этом никаких ошибок в логах не появится.
• PersistentKeepalive = 25 только на клиенте. Клиент находится за NAT (network address translation), и его роутер забывает UDP-маппинг после минуты или двух бездействия, из-за чего сервер теряет возможность связаться с ним. У сервера есть публичный адрес, поэтому keepalive ему не требуется.
• Пока отсутствует строка DNS =. Её добавление меняет разрешение имён для всей клиентской машины. В разделе DNS ниже объясняется, что именно она делает, прежде чем вы её активируете.

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

Почему одинаковые подсети на обоих концах нарушают работу

Выберите для домашней подсети диапазон, который почти никто больше не использует, например 192.168.20.0/24 или 10.44.7.0/24. 192.168.1.0/24 и 192.168.0.0/24 являются заводскими настройками по умолчанию для большинства потребительских маршрутизаторов, поэтому рано или поздно ваш ноутбук подключится к сети в кафе или отеле, использующей именно этот диапазон.

Конфликт полностью блокирует работу и в этих двух случаях проявляется по-разному. При split tunnel wg-quick пытается добавить маршрут к префиксу, который уже существует на интерфейсе Wi-Fi. Если у существующего маршрута такая же метрика, ip route add отклоняет добавление, и интерфейс не запускается:

RTNETLINK answers: File exists

На ноутбуке под управлением NetworkManager маршрут Wi-Fi обычно имеет метрику, например 600, поэтому добавление выполняется успешно, а маршрут туннеля с метрикой 0 получает приоритет. NAS отвечает, но теперь через туннель проходит каждый хост в сети кафе из этого диапазона, включая часто и ее DNS-сервер.

При full tunnel wg-quick устанавливает правила policy routing, которые намеренно исключают более специфичные маршруты из основной таблицы. Локальный маршрут 192.168.1.0/24 имеет приоритет над туннелем, поэтому каждый пакет к удаленной LAN выходит через локальное соединение. Туннель работает, рукопожатие выполняется, но NAS недоступен. Единственное реальное решение — перенумеровать домашнюю LAN.

Превращение сервера в маршрутизатор

ip route show default
printf 'net.ipv4.ip_forward = 1\n' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

Первая команда выводит фактическое имя интерфейса локальной сети. В современных образах используются имена вроде enp1s0 или ens3, реже eth0, а правило маскарадинга с неверным именем интерфейса не будет работать. Последняя команда должна выводить net.ipv4.ip_forward = 1. Простая команда sudo sysctl -w устанавливает то же значение, но оно сбрасывается после перезагрузки, что является классической причиной жалоб в духе «всё работало до вторника».

Пересылка пакетов также должна быть разрешена в межсетевом экране. В Ubuntu при активном ufw пересылаемые пакеты отбрасываются, если в /etc/default/ufw не задано значение DEFAULT_FORWARD_POLICY="ACCEPT". Docker с бэкендом iptables по умолчанию устанавливает эту политику самостоятельно при включении пересылки во время запуска, если в /etc/docker/daemon.json не задано ip-forward-no-drop. Поэтому, если sudo iptables -S FORWARD | head -1 выводит -P FORWARD DROP на сервере, где вы не настраивали межсетевой экран вручную, это обычно означает, что настройки изменил Docker, хотя это также может быть результатом работы скрипта развертывания или другого менеджера межсетевого экрана. В любом случае для туннельного трафика необходимо явное правило разрешения (accept).

Почему ответы не возвращаются

Если правильно настроить правила 1–3, запрос действительно доходит до NAS. Но вы по-прежнему ничего не видите, потому что ответу некуда возвращаться. NAS отвечает на 10.8.0.2 — адрес за пределами собственной подсети, поэтому передаёт пакет своему шлюзу по умолчанию — домашнему маршрутизатору по адресу 192.168.20.1. Этот маршрутизатор ничего не знает о 10.8.0.0/24, поэтому передаёт ответ своему шлюзу по умолчанию — в Интернет, где пакет отбрасывается. Запрос доходит, а ответ теряется.

Вариант A: masquerade на сервере WireGuard. Сервер заменяет исходный адрес каждого пакета туннеля, который пересылается через enp1s0, на 192.168.20.5 — собственный LAN-адрес этого интерфейса. Теперь NAS видит запрос от соседнего узла в своей подсети, отправляет ответ непосредственно серверу, а сервер отменяет замену адреса и передаёт ответ обратно через туннель. На других узлах LAN ничего менять не нужно.

Добавьте правило в блок [Interface] сервера, чтобы оно появлялось и исчезало вместе с интерфейсом:

PostUp = iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE

На сервере, которым уже управляет nftables, вместо этого добавьте правило в /etc/nftables.conf:

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.8.0.0/24 oifname "enp1s0" counter masquerade
  }
}

Сохраните ключевое слово counter. Без него sudo nft list ruleset выводит правило без счётчика пакетов, а именно этот счётчик показывает, используется ли правило.

Masquerade даёт ещё одно преимущество, которое легко не заметить. Многие узлы используют firewall, который принимает соединения только из собственной подсети. Общий доступ к файлам в Windows по умолчанию работает именно так. Так же работают несколько панелей управления NAS. На таком узле пакет от 10.8.0.2 будет отброшен даже при правильной маршрутизации. После masquerade источником становится LAN-адрес, поэтому такие правила начинают совпадать. Недостаток в том, что в журналах каждого узла LAN все клиенты туннеля выглядят как 192.168.20.5. Поэтому отличить клиентов друг от друга нельзя, и правила для отдельных клиентов на узлах LAN работать не смогут.

Вариант B: статический маршрут на домашнем маршрутизаторе. Укажите маршрутизатору, что 10.8.0.0/24 находится за 192.168.20.5. На маршрутизаторе Linux это одна команда:

sudo ip route add 10.8.0.0/24 via 192.168.20.5

В потребительских маршрутизаторах обычно есть страница Static Routes или Routing в расширенных настройках: назначение 10.8.0.0, маска 255.255.255.0, шлюз 192.168.20.5. Сохраните маршрут в конфигурации маршрутизатора, потому что ip route add, введённый на узле Linux, исчезнет после следующей перезагрузки.

Так сохраняется реальный адрес клиента, поэтому журналы и правила для отдельных клиентов в LAN остаются информативными. Для этого нужен маршрутизатор с поддержкой статических маршрутов. Кроме того, этот вариант помогает только узлам, использующим данный маршрутизатор в качестве шлюза по умолчанию. Для любого узла с локальным firewall, ограниченным подсетью, по-прежнему нужно отдельное правило для 10.8.0.0/24. Начните с masquerade: для него не требуется ничего за пределами уже контролируемого вами узла. Перейдите к статическому маршруту, если нужно сохранять реальные адреса клиентов.

Как определить, какой из четырех компонентов неисправен

Двигайтесь от клиента к серверу. Каждый шаг показывает, доходит ли пакет до конкретной точки.

Попадает ли пакет в туннель? На клиенте выполните:

ip route get 192.168.20.10

В ответе должно быть указано dev wg0. Если там указан ваш Wi-Fi интерфейс, значит, либо правило 1 настроено неверно и AllowedIPs клиента не охватывает подсеть локальной сети, либо приоритет имеет локальный маршрут для того же диапазона (конфликт подсетей, описанный выше). ping: connect: Network is unreachable указывает на ту же строку.

Доходят ли пакеты до сервера? Запустите эту команду на сервере, а затем пропингуйте NAS с клиента:

sudo tcpdump -ni wg0 icmp

Рабочий путь отображает IP 10.8.0.2 > 192.168.20.10: ICMP echo request, где ICMP — это протокол межсетевых управляющих сообщений, который использует ping. Если здесь пусто, но «рукопожатие» (handshake) проходит успешно, почти всегда нарушено правило 2: AllowedIPs сервера для этого узла не включает 10.8.0.2, поэтому пакет отбрасывается при дешифровке, не доходя до wg0. Рост счетчика ошибок RX в ip -s link show wg0 на сервере при каждом пинге подтверждает это. Если счетчик не растет, проверьте файрвол на клиенте: возможно, он блокирует исходящий трафик в туннель.

Уходят ли пакеты в локальную сеть? На сервере отслеживайте трафик на интерфейсе локальной сети:

sudo tcpdump -ni enp1s0 icmp

Если запросы видны на wg0, но здесь их нет, значит, нарушено правило 3: пересылка (forwarding) отключена или пакет отброшен правилом FORWARD. Реже пакеты отбрасываются из-за строгой фильтрации обратного пути (rp_filter), что случается, если маршрут сервера обратно к источнику указывает на другой интерфейс. Если запросы здесь есть, источник — 10.8.0.2, а ответов нет, значит, нарушено правило 4: у целевого узла нет обратного маршрута (хотя хост, который игнорирует пинг или отвечает только своей подсети, выглядит точно так же). Если запросы здесь есть, источник — 192.168.20.5, а ответов нет, значит, правило маскарадинга работает, но сам целевой хост не отвечает. Проверьте файрвол на NAS, а если это Linux-хост — параметр net.ipv4.icmp_echo_ignore_all, который может быть настроен на игнорирование пингов. Тот же алгоритм применим к любому другому трафику, если заменить icmp на port 445 или любой другой нужный вам порт.

Я могу подключиться по IP, но не по доменному имени

ssh 192.168.20.10 работает, а ssh nas.home.arpa выдает ошибку:

ssh: Could not resolve hostname nas.home.arpa: Name or service not known

С туннелем все в порядке. Разрешение имен — это отдельный процесс, и ваш ноутбук по-прежнему отправляет запросы тому DNS-резолверу, который он получил от локальной сети Wi-Fi. Этот резолвер ничего не знает об именах в вашей домашней сети.

Чтобы работали домашние имена, должны выполняться два условия. Адрес резолвера должен находиться внутри AllowedIPs на клиенте, иначе DNS-запрос (domain name system) никогда не попадет в туннель. Кроме того, резолвер должен быть готов отвечать на запросы, чей исходный адрес — 10.8.0.2. Многие домашние резолверы по умолчанию отказывают в этом: dnsmasq, запущенный с local-service, отвечает только на запросы из напрямую подключенной подсети, а Pi-hole поставляется с режимом прослушивания, который разрешает только локальные запросы. Правило маскарадинга скрывает эту проблему, так как после перезаписи адрес источника запроса меняется на 192.168.20.5.

На стороне клиента настройка состоит из одной строки:

DNS = 192.168.20.1

На Linux-клиенте требуется openresolv или аналогичный инструмент, иначе wg-quick завершится с ошибкой resolvconf: command not found. Убедитесь, что вы понимаете последствия для системы с systemd-resolved: wg-quick регистрирует эти серверы как единственные, поэтому, пока туннель активен, запросы с ноутбука будут уходить на ваш домашний резолвер, а не только запросы домашних имен. Только имена в специфических доменах, закрепленных за другим интерфейсом, будут обрабатываться иначе. Проверьте результат с помощью resolvectl status wg0. Если вы хотите, чтобы домашние имена разрешались дома, а все остальное — локально, это называется split DNS, и в настройке DNS через туннель WireGuard эта конфигурация описана полностью.

Нет публичного IP дома? Используйте VPS в качестве посредника

Если на странице состояния вашего роутера в поле WAN указан адрес из диапазона 100.64.0.0/10, вы находитесь за CGNAT (carrier grade network address translation), и входящие соединения из интернета не дойдут до вашего дома. Частный адрес 192.168.x.x в этом поле обычно означает наличие второго роутера перед вашим (двойной NAT): переведите модем провайдера в режим моста (bridge mode) или настройте на нем проброс UDP 51820. Если вы не можете изменить настройки этого устройства или его собственный WAN-адрес также не является публичным, работайте с ним как с CGNAT. Исходящие соединения работают в обычном режиме, поэтому решение заключается в использовании третьего узла с публичным IP-адресом. Небольшой VPS выступает в роли хаба, к которому подключается домашний сервер.

Четыре правила остаются неизменными. Теперь они применяются к двум сегментам сети, поэтому объем настроек удваивается.

• На VPS в записи пира для домашнего сервера укажите AllowedIPs = 10.8.0.3/32, 192.168.20.0/24: его адрес в туннеле и подсеть, за которую он отвечает.
• На VPS запись пира для ноутбука остается AllowedIPs = 10.8.0.2/32.
• На ноутбуке в записи пира для VPS укажите AllowedIPs = 10.8.0.0/24, 192.168.20.0/24, так как теперь весь трафик идет через хаб.
• На домашнем сервере в записи пира для VPS укажите AllowedIPs = 10.8.0.0/24, а сам домашний сервер должен иметь PersistentKeepalive = 25, так как теперь он находится за NAT.
• На VPS также необходимо включить net.ipv4.ip_forward = 1, а в цепочке forward нужно разрешить передачу трафика с wg0 на wg0, поскольку трафик ноутбука приходит и уходит через один и тот же интерфейс. Межсетевой экран, настроенный для обычного VPS с полным туннелированием, блокирует именно такие действия.

Если вы еще не настроили VPS, в руководстве настройка WireGuard на VPS описаны генерация ключей, настройка межсетевого экрана и systemd-юнита. Более общие принципы доступа к машине, которая не может принимать входящие соединения, описаны в статье открытие обратного туннеля из-за CGNAT. Когда ручное управление адресами пиров станет утомительным, запуск Tailscale subnet router позволит автоматизировать маршрутизацию и учет адресов.

Обеспечение автозапуска после перезагрузки

sudo systemctl enable --now wg-quick@wg0
sudo systemctl enable --now nftables
sudo wg show

enable --now — это этап, который многие пропускают. Запущенный вручную wg-quick up wg0 исчезнет после следующего обновления ядра и перезагрузки. wg show должен отображать пир с недавней строкой latest handshake и ненулевыми счетчиками передачи данных в обоих направлениях.

Добавление второго клиента позже не требует перезапуска, который привел бы к разрыву соединений у всех текущих пользователей:

sudo bash -c 'wg syncconf wg0 <(wg-quick strip wg0)'

wg-quick strip выводит конфигурацию без ключей, которые понимает только wg-quick, а syncconf применяет изменения, пока активные сессии продолжают работать. Эта команда обновляет только пиры. Изменение Address или добавление новой строки PostUp по-прежнему требует полного выполнения команд down и up.

FAQ

Почему я могу отправить ping на сервер WireGuard, но не могу обратиться к другим устройствам в домашней локальной сети?

Проверка связи с 10.8.0.1 подтверждает только то, что туннель работает. Остальная часть локальной сети — это проблема маршрутизации. В клиентском блоке AllowedIPs должен быть указан 192.168.20.0/24, иначе пакет не попадает в туннель. На сервере параметр net.ipv4.ip_forward должен иметь значение 1, иначе сервер отбрасывает пакеты, адресованные не ему. Кроме того, в локальной сети должен быть маршрут обратно к 10.8.0.0/24. Выполните на сервере sudo tcpdump -ni enp1s0 icmp во время проверки связи: если запросы уходят с исходным адресом 10.8.0.2, но ответы не возвращаются, обычно это означает, что отсутствует обратный маршрут.

Нужен ли статический маршрут на домашнем маршрутизаторе?

Только если вы не используете правило masquerade. Правило masquerade на сервере WireGuard заменяет исходный адрес трафика туннеля собственным адресом сервера в локальной сети. Поэтому узлы локальной сети отвечают соседу, маршрут к которому им уже известен, и маршрутизатор не участвует в передаче. Альтернативой является статический маршрут к 10.8.0.0/24 через адрес сервера в локальной сети. Такой вариант оправдан, если в журналах узлов локальной сети нужны реальные адреса клиентов или если на этих узлах должны действовать отдельные правила firewall для разных клиентов.

Почему одинаковая подсеть на обоих концах нарушает работу туннеля?

Ноутбук не может одновременно использовать два маршрута для одного префикса. Если локальная сеть выдаёт адреса из 192.168.1.0/24, а домашняя локальная сеть также использует 192.168.1.0/24, split-tunnel wg-quick up либо не запускается, когда ip route add отклоняет запрос с ошибкой RTNETLINK answers: File exists, либо, если Wi-Fi-маршрут имеет более высокий metric, запускается и скрывает локальные узлы этого диапазона за туннелем. Full tunnel при этом запускается, но wg-quick устанавливает policy rules, из-за которых более специфичные маршруты не используются из основной таблицы. Поэтому приоритет получает локальная сеть, а удалённая локальная сеть остаётся недоступной. Перенумеруйте домашнюю локальную сеть, выбрав редкую подсеть, например 192.168.20.0/24. Исправить это только на стороне клиента нельзя.

Я могу обратиться к NAS по IP-адресу, но не по имени. Чего не хватает?

Разрешение имён само по себе через туннель не проходит. Добавьте DNS = 192.168.20.1, ваш домашний DNS-resolver, в блок клиента [Interface] и убедитесь, что этот адрес входит в AllowedIPs пира. Иначе запрос не попадёт в туннель. Затем проверьте, отвечает ли resolver на запросы из-за пределов собственной подсети. dnsmasq с параметром local-service и режим прослушивания только локальных запросов в Pi-hole оба отклоняют такие запросы. Правило masquerade на сервере WireGuard обходит это ограничение, заменяя исходный адрес DNS-запроса.

У моего домашнего подключения нет публичного IP-адреса. Могу ли я по-прежнему обращаться к своей локальной сети?

Да, с помощью третьего узла. При использовании CGNAT WAN-адрес маршрутизатора не является публичным, поэтому ни один peer из Интернета не может начать с ним handshake, тогда как исходящий handshake работает как обычно. Запустите WireGuard на VPS с публичным адресом, подключите домашний компьютер к нему с помощью PersistentKeepalive = 25 и добавьте в запись пира домашнего компьютера на VPS параметр AllowedIPs, содержащий адрес этого узла в туннеле и 192.168.20.0/24. Затем на VPS нужно включить forwarding и добавить правило forward, разрешающее wg0 передавать трафик в wg0.