Почти 4 года назад я опубликовал обучающую статью-мануал о том, как на роутере с OpenWrt можно организовать роутинг для определенных подсетей. Всё это время мне много писали с просьбой помочь: не у всех всё заводилось с первого раза. Поэтому я решил написать материал, как самостоятельно искать, в чём именно проблема на роутере. В этой части разберёмся, что именно не работает, и как это исправить.
Первая часть. Установка и настройка
Написав тот материал, я рассчитывал что им будут пользоваться люди, связанные с ИТ. Но материал так разлетелся, что я до сих пор встречаю упоминания на форумах и в блогах. Если вы не привыкли страдать, то, возможно, это не для вас. Надо понимать, что у вас может ничего не заработать с полпинка.
Так же я рекомендую в идеале купить для этих целей отдельный роутер. Если у вас будет отдельный роутер для этого, в случае неудачи, вы вернёте старый роутер на место, и всё будет ок. Более бюджетный вариант - это поставить OpenWrt на вируталку и там попробовать всё настроить.
У многих возникают проблемы из-за неподдерживаемых роутеров:
- Если ваш роутер официально не поддерживается OpenWrt, вполне вероятно, что у вас возникнут проблемы (про это есть в конце).
- Если у вас стоит выбор, какое устройство купить, то не покупайте устройства, которые официально не поддерживаются сообществом OpenWrt. Сейчас можно купить недорогой роутер, на который можно поставить стабильную версию. Лучше брать роутер как минимум с 128МБ ROM и 256MB RAM. Нормальные объёмы чипов и стабильная версия очень облегчают жизнь.
Если у вас не работает роутер со свежеустановленной OpenWrt и нет доступа к интернету, то сначала разберитесь с этим и только потом приступайте к выборочному роутингу.
Итак, вы всё сделали по инструкции или с помощью ansible, но роутинг не работает. Давайте разбираться.
Видеоверсия
Как понять, что трафик к ресурсам в списке идёт через туннель на роутере
Ну самое очевидное - это открыть сайт какого-нибудь ресурса из вашего списка. Чтобы точно убедиться, что трафик перенаправляет в туннель именно роутер, а не ваш vpn на устройстве или какое-нибудь расширение браузера, используйте утилиты traceroute
Для Linux и MacOS это traceroute\mtr
mtr graylog.org
Для windows tracert
tracert graylog.org
Эти утилиты показывают маршрут пакета, который идёт к указанному хосту. Например, ваш wg сервер имеет адрес 10.7.0.1. Может быть несколько сценариев:
- Первой строкой идёт адрес вашего роутера, например 192.168.1.1 (или имя OpenWrt.lan), и второй строчкой ваш wg шлюз, и дальше доходит до конечного ip адреса, в который резолвится этот домен
Это значит, что пакет идёт через туннель на роутере, и всё хорошо. Можно ещё посмотреть, что дальше идут имена шлюзов содержащих название ДЦ, где вы купили виртуалку.
Если первой же строкой у вас идёт не ваш роутер, а, например, адрес вашего wg сервера, то значит, что трафик в туннель сразу заворачивается на устройстве. Скорее всего, у вас включен vpn.
Первой строкой идёт ваш роутер, потом шлюз провайдера и потом либо ничего, либо перенаправление на какой-то местный сервер. Это значит, что трафик не перенаправляется в туннель на роутере, а идёт по маршруту, который придумал ваш провайдер.
Как выключить настраиваемый роутинг
Это может потребоваться для troubleshooting’a, в том числе. Проще всего выключить маршрутизацию.
Два варианта: один временный - до первого рестарта сети, второй постоянный.
Временный и быстрый
Удаляем маршрут
ip route del table vpn default dev wg0
Чтоб включить обратно, либо
ip route add table vpn default dev wg0
либо
/etc/init.d/network restart
Постоянный
Идём в файл /etc/hotplug.d/iface/30-vpnroute и комментируем единственную строку
#ip route add table vpn default dev wg0
рестартуем сеть
/etc/init.d/network restart
Всё, теперь таблица маршрутизации vpn не отправляет часть трафика на wg интерфейс, а он весь идёт через дефолтный шлюз.
Но помните, что трафик ресурсов из списка всё также маркируется, и всё остальное никуда не девается.
Проблемы с DNS. У вас не открываются любые сайты, но проходит пинг до ip адресов
~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=111 time=51.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=111 time=178 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=111 time=51.7 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 51.680/93.695/177.655/59.368 ms
Скорее всего, проблема с DNS. В моей инструкции сломать доступ в интернет может только DNSCrypt. На роутере проверяем резолвится ли домен, для примера я возьму свой домен
nslookup itdog.info
Если домен резолвится, мы получаем такой ответ:
root@OpenWrt:~# nslookup itdog.info
Server: 127.0.0.1
Address: 127.0.0.1:53
Non-authoritative answer:
Name: itdog.info
Address: 95.217.5.75
Это означает, что с DNS на роутере у вас всё ок.
Если ответ nslookup выглядит следующим образом
root@OpenWrt:~# nslookup itdog.info 127.0.0.1
;; connection timed out; no servers could be reached
А запросы к сторонним DNS серверам выполняются
root@OpenWrt:~# nslookup itdog.info 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8:53
Non-authoritative answer:
Non-authoritative answer:
Name: itdog.info
Address: 95.217.5.75
Это значит, что у вас не работает локальный (на роутере) DNS сервер.
Дело, скорее всего, в DNSCrypt. Убедимся в этом, он висит на 127.0.0.53
root@OpenWrt:~# nslookup itdog.info 127.0.0.53
nslookup: write to '127.0.0.53': Connection refused
;; connection timed out; no servers could be reached
Вам сразу выдаст refused и timeout, потому что служба не запущена, и, соответственно, никто не слушает этот порт.
Нужно смотреть логи, в официальной документации есть раздел по этой теме.
Смотрим логи
logread -f -e dnscrypt-proxy
Флаг -f, как и в любых других tail подобных утилитах означает, что все свежие логи будут показываться в вашей консоли на лету.
Например, видим ошибку конфигурации
Sun Oct 16 19:28:19 2022 daemon.err dnscrypt-proxy[26781]: [2022-10-16 19:28:19] [FATAL] toml: line 869 (last key "static.server_names"): type mismatch for main.StaticConfig: expected table but found []interface {}
Это означает, что в 869 строке у нас заданы server_names в разделе statics. У меня такое было, когда не было проверки и криво отработал ansible.
Идём в конфиг /etc/dnscrypt-proxy2/dnscrypt-proxy.toml и удаляем лишнюю строку.
Перезапускаем dnscrypt
/etc/init.d/dnscrypt-proxy restart
Проверяем
root@OpenWrt:~# nslookup itdog.info 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1:53
Non-authoritative answer:
Name: itdog.info
Address: 95.217.5.75
Починили
А если nsoolkup у вас выдаёт такую ошибку
root@OpenWrt:~# nslookup itdog.info 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1:53
** server can't find itdog.info: REFUSED
** server can't find itdog.info: REFUSED
то у вас криво настроен dnsmasq для работы с DNSCrypt, правьте /etc/config/dhcp
Вторая версия DNSCrypt намного стабильнее и живучее первой, ещё и работает из коробки. Если у вас совсем всё плохо с конфигом, и уже не понятно, что наделали там, просто переустановите пакет.
Разбираемся с WireGuard
Сервер - вируталка с wg, клиент - роутер с OpenWrt.
Если у вас работает всё, кроме ресурсов из спискаы, самой вероятной причиной этого будет не поднявшийся wg туннель. Давайте проверим, заходим на роутер и проверим, что интерфейс существует в прицнипе
ip a
Если интерфейса wg0 вообще нет, то он у вас просто не настроен, проверяйте /etc/config/network
Если интерфейс в статусе DOWN, то у вас что-то с WAN интерфейсом (нет доступа в интернет), DNS (если сервер указан по url) или есть ошибки в конфигурации. Это подробно разобрано ниже.
290: wg0: <POINTOPOINT,NOARP> mtu 1420 qdisc noop state DOWN qlen 1000
link/[65534]
Если интерфейс есть, и он в статусе UP или UNKNOWN, давайте проверим, ходит ли через него трафик с помощью ping. Укажем через какой интерфейс пинг должен идти
ping -I wg0 itdog.info
Если трафик идёт
root@OpenWrt:~# ping -I wg0 itdog.info
PING itdog.info (95.217.5.75): 56 data bytes
64 bytes from 95.217.5.75: seq=0 ttl=57 time=106.460 ms
64 bytes from 95.217.5.75: seq=1 ttl=57 time=120.917 ms
64 bytes from 95.217.5.75: seq=2 ttl=57 time=121.437 ms
^C
--- itdog.info ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 106.460/116.271/121.437 ms
то проблема не с Wireguard.
Если трафик не идёт, значит у вас что-то не то с сервером, либо конфигурацией на роутере.
Пойдём от простого к сложному. Внимательно проверьте, что:
- Не перепутали ключи, и они верные
- Указали верно url\ip адрес сервера и внутренний ip клиента
- Сервер настроен в качестве шлюза
- Если на сервере Wireguard включен preshared_key, то он должен быть задан и на клиенте
После исправления ошибки, нужно рестартовать сеть /etc/init.d/network restart
Так же можно по-старинке опускать и поднимать интерфейс
ifdown wg0
ifup wg0
Относительно простой вариант проверить, что на сервере всё ок - поставить wg на ваше устройство и попробовать конфиг для openwrt там. Обязательно на время проверки выключите wg на роутере (ifdown wg0), иначе будет коллизия. Если на клиенте у вас трафик пойдёт через wireguard, значит вы неправильно настраиваете wireguard на OpenWrt. А если не пойдёт, то либо у вас сервер неправильно настроен, либо конфигурация на клиенте тоже неверная.
Если всё перепроверили, и всё равно не работает, покажу, как копать глубже. У wireguard, помимо его неоспоримых плюсов, есть один очень жирный минус - это логирование. У того же OpenVPN в большинстве случаев несложно разобраться, в чём дело, по ошибкам в логе. У Wireguard другая логика работы, и поэтому таких удобных логов у него нет.
Команда wg show покажет статус соединения более подробно. Самая важная информация в этих двух строках:
latest handshake: 28 seconds ago
transfer: 404 B received, 1.03 KiB sent
Первая показывает, когда было последнее рукопожатие. По умолчанию каждые две минуты должно совершаться рукопожатие. Если у вас пошла третья минута или вообще нет такой строки, то явно что-то не так с конфигурацией wireguard или с доступом к серверу (firewall, блокировка провайдером ит.д.), об этом ниже. Вторая строка показывает сколько трафика было отправлено и принято. Если sent есть, а received 0, то это значит, что трафик отправляется через wg интерфейс, но ничего не приходит обратно - соединение не установлено. Здесь, скорее всего, тоже проблема с конфигурацией или доступом.
Копнём поглубже
Смотрим логи на openwrt
logread -f -e wg0
Для удобства, можно открыть ещё одну консоль рядом, и сразу будет видно, что пишет wg
Также можно смотреть логи на сервере. Для этого нужно включить debug режим (под root)
modprobe wireguard
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control
Для выключения дебаг лога нужна такая же команда, только с -p
echo module wireguard -p > /sys/kernel/debug/dynamic_debug/control
После этого смотрим логи из dmesg на сервере
dmesg -wT | grep wireguard
Либо можно смотреть файл syslog
tail -f /var/log/syslog
Если клиентов у сервера много, грепните по внешнему ip адресу вашего роутера
tail -f /var/log/syslog | grep $IP
dmesg -wT | grep wireguard | grep $IP
Внешний IP можно получить прям с роутера
curl ifconfig.co
Рассмотрим несколько ошибок, которые могут возникнуть
Ошибка в имени сервера
Отобразится в логе OpenWrt
Sun Oct 30 06:51:32 2022 daemon.notice netifd: wg0 (23972): Name does not resolve: `test.tech-domain.club:51820'
Тут всё очевидно: домен не резолвится, допущена ошибка в endpoint_host
Нет доступа до сервера с wireguard, неверный порт ит.д.
Sun Oct 30 07:25:01 2022 daemon.notice netifd: wg0 (7558): Try again: `tech-domain.club:51820'. Trying again in 1.00 seconds...
Эту ошибку вы получите всего один раз в логе после смены endpoint_host. И если у вас закрыт порт, неверно указан адрес сервера, то постоянной ошибки в логе не будет. Узнать, что что-то не так, можно из wg show
peer: $KEY
preshared key: (hidden)
endpoint: $IP:51820
allowed ips: 0.0.0.0/0
transfer: 0 B received, 296 B sent
persistent keepalive: every 25 seconds
Он будет отображать адрес сервера, куда вы пытаетесь подключиться, на косяк указывает лишь отсутствие handshake и 0 B в received.
Ну а тестировать открыт или закрыт UDP порт (wireguard использует UDP) - это дело неблагодарное и не даст вам точных данных.
Поэтому тут проще всего будет глянуть tcpdump на сервере
tcpdump -i eth0 host $IP and not port 22
С флагом -i передаёте внешний интерфейс, после host пишите внешний ip адрес вашего роутера, and not port 22 - чтоб не выводил ваш ssh трафик
Если соединение установлено, то должны быть сообщения такого типа с ответами от сервера для них
16:35:03.142648 IP $IP_ROUTER.51820 > $IP_VPN.51820: UDP, length 128
16:35:03.144987 IP $IP_VPN.51820 > $IP_ROUTER.51820: UDP, length 128
Если сообщение остаётся без ответа
16:35:03.142648 IP $IP_ROUTER.51820 > $IP_VPN.51820: UDP, length 128
смотрите firewall на сервере и что wg вообще включен.
А если всё пусто, значит проблема в доступе к серверу. Причины могут быть:
- Неверно указан сервер или неправильно резолвится
- Неверно указан порт
- Wireguard на уровне протокола блокируется провайдером
- Закрыт порт на стороне провайдера. Например, у cloud firewall, который примененый к виртуалке, не открыт wg порт
Неверный private_key
В логах на openwrt получите такое сообщение
Sun Oct 30 08:16:43 2022 daemon.notice netifd: wg0 (27536): Key is not the correct length or format: `$KEY='
Либо не получите никакого сообщения. Всё зависит от ошибки, которую вы допустили в ключах
На сервере
[Sun Oct 30 09:22:09 2022] wireguard: wg0: Invalid handshake initiation from $IP:51820
Неверный public_key
На клиенте так же может быть сообщение
Key is not the correct length or format:
А может и не быть, всё так же зависисит от типа ошибки.
На сервере будет ошибка
[Sun Oct 30 10:24:22 2022] wireguard: wg0: Invalid MAC of handshake, dropping packet from $IP:51820
Ошибка в preshared_key
На сервере будет повторятся такая строка
Oct 30 10:50:55 vpn kernel: [67880632.804341] wireguard: wg0: Keypair 350937 destroyed for peer 181
Строка говорит о том, что wg пытается пересоздать пары ключей и у него всё-равно не получается. Виной как раз может быть кривой preshared_key.
На клиенте, как и в двух других ошибках в ключах, может быть сообщение
Key is not the correct length or format
Неверный IP в сети wireguard
Ошибок не будет в логах на клиенте. Более того, wg show вам покажет трафик.
В логах на сервере
А если запустим пинг на роутере ping -I wg0 itdog.info, то получим ошибку, которая уже прямо скажет что у нас не так
[Tue Nov 15 17:59:10 2022] wireguard: wg0: Packet has unallowed src IP (10.7.0.3) from peer 3 ($IP:51820)
Не указан или ограничен allowed_ips
root@OpenWrt:~# ping -I wg0 itdog.info
PING itdog.info (95.217.5.75): 56 data bytes
ping: sendto: Required key not available
Таким образом трафик через wg0 просто не пойдёт, но wg соединение при этом будет.
Что-то не отработало в скрипте
Скрипт выгружает списки и рестартует сеть. Проверьте, что списки загрузились
root@OpenWrt:~# ls -lh /tmp/lst/
-rw-r--r-- 1 root root 11.4K Oct 30 11:30 community.lst
-rw-r--r-- 1 root root 1.0M Oct 30 11:30 ip.lst
-rw-r--r-- 1 root root 1.8K Oct 30 11:30 subnet.lst
Если не загрузились, то надо вручную запускать скрипт и смотреть на вывод ошибок. Например, может быть ошибка с сертификатом у antifilter.download
Downloading 'https://antifilter.download/list/ip.lst'
Connecting to 45.154.73.71:443
Connection error: Invalid SSL certificate
В первую очередь проверьте дату на роутере
date
Если время кривое, чекните конфигурацию
root@OpenWrt:~# uci show system.ntp
system.ntp=timeserver
system.ntp.enabled='1'
system.ntp.enable_server='0'
system.ntp.server='0.openwrt.pool.ntp.org' '1.openwrt.pool.ntp.org' '2.openwrt.pool.ntp.org' '3.openwrt.pool.ntp.org'
Так она должна выглядеть. Проверьте что ntp сервер отдаёт данные
root@OpenWrt:~# ntpd -n -w -p 0.openwrt.pool.ntp.org
ntpd: reply from 188.93.90.21: offset:+0.004344 delay:0.005661 status:0x24 strat:3 refid:0x361df9ad rootdelay:0.103670 reach:0x01
Зафорсить синхронизацию времени
ntpd -d -p pool.ntp.org
Для более глубокого копания в документации есть пункт по troubleshooting.
Проверка сертификата
Чекнем, что на стороне antifilter.download всё ок, и сертификат не протух
curl -vI https://antifilter.download/list/ip.lst --stderr - | grep "expire date"
Накрайняк, со своей стороны, вы можете отключить проверку сертификатов у curl\wget
wget –no-check-certificate
wget --no-check-certificate -P $dir $SUBNET
curl –insecure
curl --insecure -z $dir/subnet.lst $SUBNET --output $dir/subnet.lst
Списки не успевают загрузится
Ещё списки могут не загружаться при старте роутера. Такое может быть, когда скрипт запускается быстрее, чем поднимется сеть и появляется доступ в интернет. Я добавил недавно в скрипт if, которые даблчекают, загрузились ли списки. Это решило лично мою проблему, но если вашу нет, можно воткнуть цикл.
Раз говорим о списках, сразу проверим, что они загружены в sets. Посмотреть, что списки созданы
root@OpenWrt:~# nft list sets
table inet fw4 {
set vpn_subnets {
type ipv4_addr
flags interval
auto-merge
}
set vpn_ip {
type ipv4_addr
flags interval
auto-merge
}
set vpn_community {
type ipv4_addr
flags interval
auto-merge
}
}
Глянуть содержимое списков
nft list ruleset | grep -A 10 vpn_ip
nft list ruleset | grep -A 10 vpn_subnet
nft list ruleset | grep -A 10 vpn_community
Теперь вы точно знаете, что списки загружены в firewall.
Так же, при выполнении скрипта, могут возникать ошибки, связанные с настройкой сети и firewall. Там обычно сразу понятно, в чём дело, а если не понятно, то просто погуглите.
Не хватает памяти на роутере
Да, это можно реализовать на слабом устройстве. Но если точно хотите, чтобы всё было ок, берите роутер как минимум с 128MB ROM и 256MB RAM. Сейчас такие роутеры не стоят космических денег. Если средств немного, лучше смотрите в сторону БУ, чем греть голову лишний раз. За 4 года я купил 4 роутера с такими характеристиками за 1500-2000р с рук.
Nftables отъедает примерно 50MB во время загрузки списков из файлов. Речь про списки ip, subnet и community. Ещё выгруженные списки складываются в оперативку - /tmp.
Если памяти не хватает:
- Попробуйте ip.lst заменить на ipsum.lst. Либо вообще не используйте ip/ipsum, возможно лично вам хватит чисто community.lst.
- Можно не хранить списки в /tmp: загружать их, применять и сразу удалять с помощью скрипта.
- Откатититься на iptables или вообще на 21 версию.
- Попробовать vpn-policy-routing + ipset (не пробовал, но говорят рабочий вариант)
Проблема c firewall на версии 22.03.2
При запуске скрипта и рестарте firewall получаем ошибку
Firewall restart
Killed
/dev/stdin:112:19-19: Error: syntax error, unexpected end of file, expecting comma or '}'
185.60.216.0/22
^
The rendered ruleset contains errors, not doing firewall restart.
Syntax: /etc/init.d/hivpn [command]
Это был косяк в пакете firewall4, либо обновите его
opkg update && opkg install firewall4
Либо все пакеты сразу
opkg update
opkg list-upgradable | cut -f 1 -d ' ' | xargs -r opkg upgrade
Проблемы на роутерах, которые официально не поддерживаются OpenWRT
На форумах вы можете встретить высказывания, что моя инструкция не работает на 22ой версии OpenWrt. Дело в том, что люди покупали устройства, которые официально не поддерживались сообществом OpenWrt. Для этих устройств была доступна только dev версия или сборки на её основе.
Openwrt 22 стала стабильной только в сентябре 2022 года. До этого она была в разработке, и поддержку nftables sets, которые являются ключевым элементом в роутинге и пришли на замену ipset, туда завезли не сразу. Люди устанавливали dev версию, где не было поддержки sets, и, соответственно, роутинг не работал. К стабильной версии разработчики это поправили. Но есть ещё большой пласт устройств, которые официально не поддерживаются OpenWrt. Например, я знаю роутер Xioami AX3600. Под него есть неофициальная сборка, основная на ранней dev версии OpenWrt 22, и в ней не поддерживаются sets.
Какие в этом случае варианты:
- Откатиться на iptables+ipset
- Попросить разработчика сборки взять реализацию sets из стабильной ветки
- Использовать пакет vpn-policy-routing . Я сам не пробовал его, но с ним есть прям инструкции, например, для AX3600. И у людей в такой ситуации это было выходом
- Поменять роутер на официально поддерживаемый (лучший вариант)
Заключение
Я не разобрал только маркировку пакетов и пару правил firewall’a. Это стандартные вещи внутри OpenWRT, которые работают стабильно и проблем с ними не наблюдалось. Поэтому их траблшутинг рассматривать не буду.
Знаете как можно лучше или я что-то упустил? Пишите в ЛС или комментарии.
Обучающие материалы про VPN и роутинг, не дотягивающий до полноценной статьи, публикую в моём телеграм-канале .
Обсудить и задать вопросы можно в чате https://t.me/itdogchat