Как стать автором
Обновить

Комментарии 39

Настраивал подобное для себя: на VPS CHR, в домах самые дешёвые микроты. Связь между точками L2TP/IPSec, на всех точках выход в санкционный интернет через mangle+address_list+маршруты для всех локальных юзеров. На телефонах (android/ios) просто добавил конфигурацию L2TP. Итог: на микротах без Hardware IPSec 60Мбит из 100 провайдерских при выходе через Францию.
На телефонах можно и в локалку попасть и санкционочку посмотреть, но было решено сделать отдельно VPN под локалку и под выход на ужасные сайты, так всё-таки быстрее. Робит почти год.
В чём всё-таки киллер-фичи wiregueard?

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

В чём всё-таки киллер-фичи wiregueard?

Сам имею в наличии l2tp/ipsec. В целом WG тупо быстрее. Второй момент который меня толкнул на переход, это блокировка у некоторых провайдеров l2tp и IKE2. SSTP оказался очень медленным в моем варианте.

Блокировка - аргумент, но в зоне работы всех наших клиентов не встречали блокировок, поэтому юзаем L2TP. Ради интереса, есть примеры этих геройских провайдеров?

Например — такие штуки режутся в Узбекистане. IKEv2, OpenVPN, PPTP — даже до авторизации не проходит. SSTP — работает.

Это очень местечковые операторы. Там бывает ситуация, что они это делают не осознано. Но воевать с support и растягивать это на пол года (был опыт) желания нет.

Он быстрее, потому что параллит все сразу на все ядра, доступные системе.
l2tp/ipsec тупо сваливает все на несколько ядер и система захлебывается.

Но, как только стает вопрос более серьезных действий, приходится прокидывать еще gre тунели поверх wireguard

1) в рамках нищебродского VPS с одним ядром - WG работает быстрее StrongSwan. Причина не только в ядрах и их утилизации. 2) Когда нужны сложные вещи, то в бой идут разные средства, но на текущий момент спасибо, что WG есть.

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

60Мбит - это как раз Hardware IPSec, имхо.

hAP AC lite за 60 баксов.

В чём всё-таки киллер-фичи wiregueard?

Как в чем, простота настройки и аппаратное ускорение, как бы все. Конфиг wg несколько строчек, конфиг ikev2 это уже совсем другая история со своим УЦ... Конечно можно использовать letsencrypt серт сервера и psk, но как по мне это менее безопасный путь, а на ваш l2tp+ipsec начал уже ругаться android даже, мол не безопасный протокол обновитесь на ikev2...
Однако что ipsec что ikev2 что wg равны перед DPI, и одинаково определяются, а тут уже как говориться добро пожаловать в мир SSL VPN, SSTP, OpenConnect, SoftEtherVPN, Outline и другие.

Держу два VPS один вне и внутри страны, так вот, который вне обеспечивает доступ к разным сайтам через целую кучу протоколов (wg "основной", sstp, openvpn '+wstunnel', outline, ikev2 и openconnect - все сразу они вряд-ли смогут закрыть), а который внутри отвечает за dns (dot/doh - ходит через туннель на dns вне страны), доступ к локальным серверам(и виртуалкам), облаку, ну и к обычным машинам, хостит сайт и другие не названные сервисы, часть которых доступна только через vpn. И все это без CHR

Мне кажется плохой практикой пихать "PostUp = iptables -A..", потому что на недорогих VPS, с фаерволом и самим дистрибутивом линукс может твориться полный бедлам, а например в Debian 11 после установки нету iptables, поэтому давайте будем исходить из практики, VPN отдельно, firewall отдельно, route отдельно. Для iptables, хорошей практикой будет

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A FORWARD -m state --state INVALID -j DROP

iptables -A FORWARD -j DROP

многие "сеньёры", часто со вздохом, придерживаются только последней, строчки "всё в Drop", соответственно и взаимодействие с VPN уже стоит рассматривать отдельно, а не copy & paste

Во-вторых, Persistent keepalive это не интервал опроса живости, а указание таймаута по которому пир будет отправлять пакет в сторону другого пира в тунеле, и пофигу что живо соединение, интерфейс или нет.

В-третьих, и у Кинетика, и у Микротика, есть свои проблемы работы с wireguard. У последнего, это прямо напоминает мем ".. на фоне горящего дома".

И небольшая опечаточка с sudo, наверное лучше вообще убрать всякое упоминание.

А за статью спасибо! Минималистично, информативно, "контент в копилочку".

а что с тиками не так ? Просто пока не очень замечаю проблемы, но если есть - хотелось бы знать.

Целью данной статьи было описать именно WG, я исходил из предположения, что потребитель имеет минимальные познания в Unix и способен справиться с apt-get :)

Спасибо за оценку статьи, про sudo принято, хотел уточнить - какие именно проблемы с WG у Микротика и Кинетика? Я не припомню, чтобы на какие-то грабли наступил при настройке, возможно, память подводит.

На текущий момент, 7.6 stable, у микротика есть три больных места с WG.

1 - Отсутствие, или общая не информативность о состоянии интерфейса. Микротик умеет сообщать о неудачных рукопожатиях, но не об удачных, состоянии. Грубо говоря, узнать жив ли интерфейс, можно лишь через пинг и нетвотч. Нельзя сказать, что это специфическая проблема микротика, т.к. и в линуксе отслеживание клиентов, состояния wireguard не тривиальная задача, но там возможностей больше.

2 - При неожиданном разрыве соединения(падении интерфейса) поверх, которого установлен туннель wireguard, при восстановлении связи, соединение wireguard не восстанавливается, микротик циклично получает ошибку рукопожатия, а сервер считает, что рукопожатие уже установлено, исправить можно лишь перезапустив интерфейс на сервере. Это уже вызвало и вызывает жаркие дискуссии на форуме микротика, но пока решения не видно. Сторонники "микротик - рука..пы, лентяи" апеллируют к "а вот клиент на телефоне, пк, холодильнике,.. работает без проблем!".

3 - Глюки и баги. Например, после создания wireguard интерфейса, можно поменять приватный ключ, он отобразится, даже создаться новая пара, публичный ключ, но рукопожатие не пройдёт. При создании двух интерфейсов wireguard, порой, то один, то второй не работают, пока не удалить и не создать заново, с теми же данными, перезагрузив микротик.

Из готового:

pivpn, wg-easy (gui), firezone (gui)

Способ не универсален. Если обход РКН, то сойдет, а если заходить на сайты, которые не хотят видеть посетителей из РФ, то через утечку DNS они поймут, что вы из РФ. Например канва или сайты иностранных бирж (Лондон к примеру). Для этого на VPS еще DNS-proxy надо сделать.

Скорее всего, Вы правы. У меня таких кейсов не было, пока всё устраивает.

Приветствую.

А про утечку DNS можно подробнее? Насколько я понимаю WG при указанном в wg0.conf dns - все запросы шлёт в него и через WG. Я не понимаю принцип работы механизма определения пользователей из РФ на сайте.

Расскажите пжл.

Просьба не пинать за упрощения в примере, подробно можно поискать про DNS Leak. Или проверить свой VPN тут - https://dnsleak.com . При утечке dns ваш провайдер может видеть куда вы ходите, а посещаемые ресурсы видят откуда пришел DNS-запрос. Если кратко и упрощенно: сайт закрывает доступ для российских IP. Вы используете VPN, трафик идет через тоннель и сайт видит IP vpn-сервера. Но для сопоставления ip-домен нужно отправить DNS-запрос. Если VPN сервер его не обработал (или не так настроено что-то), то запрос пойдет вне тоннеля и раскроет вашего провайдера -> понятно откуда вы пришли. Чтобы этого не было, надо использовать DNS-резолвер на стороне VPN сервера, а клиент использовать его в качестве сервера DNS, чтобы запросы шли от его имени, тогда будет совпадать. Самый готовый и простой – в докере поднять Wireguard вместе с Unbound и Pi Hole.

+1, прикольная штука, у самого поднят VPN на ломашнем микроте, цепляюсь с телефонов. А до другого микрота на работе прокинут OVPN, причем через TCP - WG тупо не пробивается, от слова "вообще". Притом дома белый адрес. Но на работе у меня двойной NAT и мощный файрвол - интернет микрот получает от халявного хотспота в местной корпоративной сети. В целом и общем настраивается весьма удобно.

Автоматический прогон через VPN трафика только исключительно для определенных доменных имен, на уровне роутера, да чтоб имена удобно задвать в webgui админки роутера - вот это секси. По крайней мере на Keenetic такого пока нет, только по IP (которые есесно могут динамически меняться со временем)

Микротик такое умеет, но считается ли это удобным — не знаю. Имена ресолвятся при загрузке и потом по истечению их TTL в кэше.

не совсем так.
1)вам потребуется скрипт для добавления поддоменов.
2)имена ресолвятся при обращении к DNS серверу микротика. Это может быть проблемой, если DNS сервер на микротике не используется (к примеру на компе вы поднимаете VPN до рабочей сети и DNS запросы летят туда)

1) Для поддоменов — или скрипт, или добавить нужные имена вручную.
2) Нет, ресолвятся они сами из этого списка, дополнительные обращения от устройств в сети не нужны.

1)Вручную задолбаетесь
2)Если вы посмотрите адрес лист, то там к каждому добавленному домену будут добавлены динамические записи с IP адресами.

Откуда по вашему берутся эти IP адреса? Они берутся из DNS записей на самом микротике. Но их не будет, если к микротику никто не будет обращаться за этими записями и он не запросит вышестоящий DNS сервер.


2) Перезапустите роутер, не открывайте этот сайт, проверьте динамические записи и кеш dns — они там уже будут. Роутер сам за ними сходит. Ну или без перезапуска — очистите кеш, удалите динамические записи и подождите.

C:\Users\User>tracert pravda.com.ua

Трассировка маршрута к pravda.com.ua [107.178.251.122]
с максимальным числом прыжков 30:

1 <1 мс <1 мс <1 мс 192.168.66.1
2 55 ms 49 ms 49 ms 10.21.96.0
3 ^C
C:\Users\User>tracert pravda.com.ua

Трафик идёт в VPN.
Теперь удаляю динамическую запись и запускаю трассировку заново.

Трассировка маршрута к pravda.com.ua [107.178.251.122]
с максимальным числом прыжков 30:

1 <1 мс <1 мс <1 мс 192.168.66.1
2 <1 мс <1 мс <1 мс host-*deleted*.real.mrnext.net
3 <1 мс <1 мс <1 мс ^C
C:\Users\User>

Трафик идёт в интернет напрямую.

Минут 5 подождал, динамическая запись не появилась, трассировка идёт в интернет напрямую.
ROS 7.6 stable

7.6, hex s.
Динамические записи после удаления появляются снова через некоторое время, даже штуки типа download.lenovo.com, к которым точно нет никаких обращений из сети (добавлялась, чтобы скачать драйвер ещё в прошлом году).

Официальной документации вроде нет.
вот тут https://forum.mikrotik.com/viewtopic.php?t=170979
пишут что скорее я прав с дополнением, что после истечения TTL запись обновляется сама.
к даунлоаду мог обращаться сам драйвер... точнее дополнение к нему.

у меня hap ac2

к даунлоаду мог обращаться сам драйвер… точнее дополнение к нему.

У меня в сети нет устройств леново. Я потому и назвал его в качестве однозначного маркера.
После истечения TTL запись обновляется сама. Но и удалённая динамическая запись при этом восстанавливается. Либо можно указать, как часто обновляется эта запись вручную.

Либо можно указать, как часто обновляется эта запись вручную

Это где такая функция?

посыпает голову пеплом
А вот тут — моя вина. По вашей ссылке её последним сообщением придумали, увы.
Так что — только TTL.

Если я правильно понял ТЗ - выражение "нельзя настроить на одном интерфейсе выход в интернет клиентских устройств и связь между сетями" не совсем корректно. Если прописать пиру нужные сети в wg0.conf
AllowedIPs = 10.1.1.4/32,192.168.2.0/24,192.168.3.0/24,192.168.4.0/24
То прекрасно работает маршрутизация между двух сетей.

Лично проверял. При этом нормально работают остальные клиенты которые ходят по в интернет.

А зачем делать столько телодвижений руками, когда есть рабочий скрипт Nyr WireGuard road warrior installer, который делает ровно то же самое, но в одну команду?

Потому что настраивается не просто VPN, а еще и бридж между двумя сетями. Моя статья была бы короче в четыре раза, если бы я не объяснял, что и почему. Но для этого, как Вы правильно подметили, есть GitHub.

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

 Хорошо, добавим в настройки серверного пира для телефона 0.0.0.0/0, все пакеты будут уходить на телефон - профит. После рестарта интерфейса wg0 мы с удивлением обнаружим, что наш VPS сервер больше недоступен - не пингуется, не коннектится по ssh и текущий терминал вообще завис, потому что теперь весь трафик уходит в пир, даже тот, который для него не предназначен.

Если у вас на VPS роутер ос, то можно использовать роутинг марк.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.