Клиент OpenVPN для всей LAN на OpenWrt: рабочий порядок
Владение интерфейсом, политика зоны, masquerade и таблицы по SSID — это четыре отдельные задачи. Выполните их по порядку, и туннель на весь роутер перестанет с вами воевать.
Четыре независимые задачи ставят всю LAN роутера за один туннель. Устройству туннеля нужен владелец, зона файрвола, цель трансляции в сторону аплинка и, если часть клиентов должна остаться вне VPN, маршрутизация по адресу источника. У туннеля, который подключается, но через который ничего не проходит, обычно отсутствует одно из этих четырёх. Работа в порядке зависимостей означает, что сбой в конце принадлежит шагу, который вы только что изменили. Каждый шаг ниже заканчивается чем-то, что можно увидеть, и это не даёт следующему стать догадкой.
Решите, что делит туннель
Роутер, который раздаёт Wi-Fi и DHCP, может запускать клиент сам. Это ставит каждое подключённое устройство за туннель без настройки на каждом устройстве, и именно такой вариант нужен большинству небольших площадок. У него же самая широкая зона поражения при падении туннеля, потому что каждое устройство теряет путь одновременно. На LAN не остаётся работающего выхода наружу.
Второй роутер за первым, запускающий клиент со своей подсетью, ограничивает туннель своими устройствами. Его проще убрать и проще объяснить тому, кто его унаследует. Цена — доступность между сторонами без маршрута или проброса порта.
Так или иначе, сделайте подсети LAN разными. Одинаковые диапазоны заставляют одну сторону выглядеть подключённой напрямую, и возникающая из-за этого чёрная дыра читается как сбой VPN на часы.
Дайте туннелю владельца
Объявите туннель сетевым интерфейсом с именем, устройством и без собственного протокола. Тогда сетевая система создаёт и обслуживает устройство, и всё дальше ссылается на интерфейс по имени, а не по устройству. Именно это позволяет зоне найти его.
Не создавайте одно и то же устройство в двух местах. Туннель, сделанный вручную рядом с объявленным интерфейсом, даёт устройство, которое существует, но не входит ни в одну зону, либо исчезает при перезагрузке. Оба выглядят как отказ клиента, и ни один не выдаёт ошибку с настоящей причиной. Выберите декларативный путь и удалите ручной.
Держите имя одинаковым в конфигурации сети, файрвола и VPN. Зона перечисляет сети по имени, поэтому опечатка оставляет туннель вне всех зон, пока сам интерфейс выглядит здоровым. Здоровый интерфейс без политики — самое трудное для обнаружения состояние.
Поместите его в зону, затем разрешите пересылку в неё
Зона файрвола — это место, где живёт политика: вход, выход, пересылка и masquerade. Туннель вне зоны управляется значениями по умолчанию, которые вы не выбирали, и клиенту роутера это редко подходит. Блоки ниже объявляют интерфейс, помещают его в зону и разрешают трафику LAN входить в эту зону.
config interface 'vpn'
option device 'tun0'
option proto 'none'
config zone
option name 'vpn'
list network 'vpn'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
config forwarding
option src 'lan'
option dest 'vpn'
В выпусках старше 21.02 та же строка интерфейса пишется как option ifname, поэтому проверьте, какую форму понимает установленная прошивка, прежде чем вставлять. Блок пересылки — это разрешение, которое вообще позволяет трафику LAN пользоваться туннелем. Без него устройство поднято, клиент подключён, и ни один узел LAN не достигает туннеля. Это самая частая жалоба «подключено, но интернета нет» у клиентов роутера.
Masquerade в зоне VPN сворачивает каждый адрес LAN в адрес туннеля роутера до того, как пакет уйдёт. Это снимает необходимость в обратном маршруте к вашей подсети на дальней стороне.
Если дальняя сторона уже маршрутизирует вашу LAN, отключение masquerade сохраняет адреса источника видимыми и делает журналы по клиентам осмысленными. Выберите один вариант и запишите какой, потому что эти два выбора позже дают разные вопросы в поддержку. Удаление пересылки LAN-to-WAN по умолчанию — отдельное решение со своим следствием. Уберите её, и собственный доступ роутера в интернет уйдёт вместе с ней.
Назовите настоящий аплинк в NAT
В прошивке, где правило трансляции написано вручную, именно исходящий интерфейс — это поле, которое ломается. Правило, называющее vlan2 ничего не делает, когда сессия завершается на ppp0. Правило вообще без интерфейса может транслировать трафик, который должен был остаться закрытым. Ни одна из ошибок не объявляет о себе, потому что туннель продолжает работать.
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Замените ppp0 в этом правиле на интерфейс из ip route или из списка работающих интерфейсов, затем смотрите на счётчик, пока узел LAN загружает страницу. На роутере с одним провайдером одного правила masquerade для аплинка обычно достаточно. Второе правило для интерфейса туннеля не заменяет первое.
Затем добавьте параметры клиента, которые решают, что входит в туннель. Директива redirect-gateway отправляет интернет-трафик клиента через VPN, а без неё туннель несёт только маршруты, которые продавливает сервер. Проверьте получившуюся таблицу маршрутов, прежде чем трогать DNS.
Разделите Wi-Fi второй таблицей
Одна таблица маршрутов не может держать два маршрута по умолчанию. Поэтому второй SSID, который должен обходить туннель, нуждается в своей подсети и своей таблице. Дайте туннелируемому SSID свой диапазон, затем направьте только этот диапазон в туннель правилом, которое выбирает таблицу.
Пакеты policy routing в OpenWrt выражают ровно такую комбинацию. Можно и вручную, с правилом по источнику и таблицей, чей маршрут по умолчанию указывает на устройство туннеля.
Проверьте разделение из обеих сетей. Клиент на туннелируемом SSID должен показывать выходной адрес VPN, а клиент на обычном SSID — адрес провайдера. Когда оба выглядят одинаково, правило совпадает с неверным источником или таблица вообще не используется. Проверьте и после переподключения, потому что правило, зависящее от имени интерфейса, ломается, когда устройство получает новый номер.
Подозревайте часы и флаг устройства
Флаг persist-tun оставляет устройство туннеля на месте между перезапусками. Это подходит серверу и путает клиента, состояние которого должно собираться заново. Уберите его при разборе проблем с клиентом роутера, потому что устройство, пережившее неудачные переговоры, скрывает, какой шаг на самом деле сломался. Верните его после того, как клиент стабильно подключается, и не раньше.
Часы — это второй тихий отказ. Роутер без батарейных часов стартует от эпохи, а значит проверки сертификатов падают, пока NTP не догонит. Сравните отметки времени в журнале с реальным временем, прежде чем трогать сертификат, потому что клиент, подключающийся через минуту после загрузки, обычно ждёт синхронизации времени.