![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagner) wrote2022-01-15 05:39 pm
Wireguard и все-все-все
Вот думаю, а не перейти ли мне с openvpn на wiregard для создания приватной сети, объединяющей мои компьютеры.Преимущества wireguard - бо́льшая скорость, более простая ключевая инфраструктура, меньше любителей резать протокол на файволлах.
Недостатки - более простая ключевая инфраструктура, требующая дописывания в конфиг на сервере всех peer-ов. С openvpn-то в этом плане всё просто - предъявил peer при коннекте сертификат, подписанный УЦ, которому сервер доверяет, и сервер его пустил. Еще и в DNS оно само прописывается. Потребности в отзыве сертификатов VPN-клиентов у меня пока не возникало, хотя я знаю как это делается. У wg конечно отлучить клиента от сети проще - никаких crl-ей не надо, выкинул его ключ из конфига сервера и всё. Кроме того, жесткая завязка на протокол. openvpn умеет udp, умеет tcp, умеет делить порт с веб-сервером, умеет ходить через прокси. В общем варианты обхода резки на файрволлах там многообразны.
Кстати, я вот если я вдруг соберусь перейти на wireguard, мне мой личный удостоверяющий центр X.509 совсем перестанет быть нужным. Сейчас у меня все сервисы на wagner.pp.ru (web, jabber, smtp, imap) используют let's encrypt-овские сертификаты. Хотя это и менее секьюрно и подтверждать смену сертификата (вернее двух imap и smtp) в почтовом клиенте на каждой машине, где он у меня стоит, приходится раз в квартал.
Локальные postfix-ы (которые у меня по-прежнему есть на десктопе и на всех ноутбуках) уже давно перешли с авторизации у сервера по сертификатам на парольную. (впрочем, локальные постфиксы надо вообще обязать ходить по smtp внутри VPN и там их пускать без SSL и авторизации). Остается, пожалуй только локальный веб-сервер, который для тестовых целей на десктопе. Но в принципе, и на него можно летсэнкриптовский сертификат получать. Надо только отдавать letsencrypt-у для него AAAA запись и не отдавать A. Дома-то у меня провайдер IPV6 поддерживает.
Вот интересно, реально ли для ноутбуков, которые заметную часть времени проводят в сетях, где ipv6 нет, сделать wireguard-овскую vpn окном в ipv6 мир. в принципе ничто не мешает раздать им адреса из какой-нибудь /112 или даже /80 подсетки той /64 которая у меня на сервере есть. Благо в конфиге wg все равно пишутся конкретные адреса. А роутить ::/0 через wireguard - штатное и рекомендуемое поведение, благо будучи ядерным модулем, он как-то сам разбирается где его пакеты, а где остальное.
Тонкость тут заключается в том, чтобы заметить, выдали ли в локальной сети ноутбуку globally routable ipv6 адрес или нет. И если не выдали сделать wireguard-овский сервер дефолтным route для ipv6. Еще желательно это уметь делать вручную. На случай если вдруг выяснится что в данной сети есть нехорошие ipv6 firewall-ы.
Интересно, правда, как это уживется с dyngo. Не придется ли туда какую-нибудь извращенную логику дописывать, чтобы соображало какой из двух адресов слать на сервер, чтобы тот создал AAAA-запись, соответствующую более подходящему ipv6-адресу? В смысле тому, на который по ssh пустят. Или наплевать, и всегда ходить через wireguard, считая его оверхед пренебрежимо малым?
no subject
no subject
Через wg-quick, наверное, можно. Там PostUp команда, предусмотрена. а так явного способа задания метрики не видно.
no subject
Лет уже пять полёт нормальный.
no subject
Видимо у вас VPN с другими целями применяется, чем у меня.
no subject
Однако всё-же не вижу смысла устраивать пляски с dyngo и роутами, когда оно и так будет отлично работать.
У меня не получилось выделить вклад wg из RTT до пира, то есть никакой измеримой разницы в RTT что с wg что без него не было (гигабит, мск-франкфурт, мск-лондон). Так что я сделал вывод, что на не совсем уж слабом железе оно действительно работает на wire speed.
no subject
Я же говорю - разные задачи. Основное что требуется от VPN мне, это чтобя я мог зайти по ssh на подключившийся к VPN компьютер, независимо от того, сколько там NAT-ов организовал провайдер по дороге. И это актуально даже если я сижу за клавиаатурой этого самого компьютера - вот зашел я на какой-то удаленный компьютер, и хочу с него файл перекинуть по scp. Естественно, удобнее использовать для этого имя компьютера которое я помню, чем помнить адреса.
Далее, я всегда учитываю возможность того что канал во внешний мир может либо лежать, либо быть тормозным. Вот представьте себе, что к одному и тому же wi-fi роутеру подключены два ноутбука. а канал наружу 3G, да с таиким казествоам, что при разговоре по скайпу видео отключать приходится. И мне надо перекинуть с одного ноутбука на другой большой файл. Фильм там в высоком разрешении или образ виртуальной машины, или миррор флибусты синхронизировать.
Если у меня эти ноутбуки видят друг друга напрямую, то файл будет качаться со скоростью вайфая. Если весь траффик завернут в VPN, то со скоростью внешнего канала. Который в случае сотовой сети может еще и лимиты на траффик иметь, измеряемые считанными гигабайтами в месяц. dyngo - это один из вариантов в этом случае видеть друг друга по именам. Возможны еще вариианты устроить локальный DNS на роутере, но это не всегда получается. Потому что наличие встроенного аккумулятора и внешней антенны для роутера - куда более важная фича, чем поддержка OpenWRT. В этих случях, правда. скорее всего придется использовать multicast dns AKA bonjour AKA avahi.
Ну и если роутер раздает полноценные ipv6 адреса, машинка будет доступна по ssh прямо из интернета независимо от работы VPN. Вот в этом случае альтернативы dyndns, чтобы сказать "я сегодня по такому-то адресу" нет.
no subject
Тогда конечно. Я, правда, не видал ещё динамической перестройки wg peers через avahi. Но идея занимательная. Тут надо бы поразмыслить.
Спасибо, извините, что побеспокоил.
no subject
А тут перестраивать wg-peers не надо. Тут надо просто вовремя сообразить, что вот сейчас маршрут до этого ноутбука есть только через VPN (wg - частный случай, от других не сильно отличающийся), сейчас - есть прямой ipv6 маршрут, а сейчас есть и прямой ipv4.
Система метрик протоколов IP это позволяла бы, но у нас ситуация, когда ip-адреса всё время меняются (выдаются роутерами и сотовыми операторами по dhcp), Имена - штука ненадежная. Могут запросто дублироваться. Сочетание имени и host-ключа (хоть ssh, хоть wg) это уже вариант. Так что, возможно что перестаривание wg-peers динамически, в зависимости от того что нам рассказала система разрешения имен - это работоспособная идея.
no subject
по-моему если не перегенерировать приватный ключ, то обновление сертификата проходит для всех клиентов незаметно (я использую acme_tiny вместо Certbot)
no subject
Я тоже пользуюсь acme-tiny, потому что посмотрев на список зависимостей certbot-а сразу понял что защищенность моего компьютера наличие на нем этой хреровины явно не повысит.
А смена сертификата без смены приватного ключа безопасности тоже не добавляет. НАм ведь важно что - как-то ограничить риски возникающие в случае утечки ключа. Ежеквартальная смена ключа существенно ограничивает возможности атакующего успеть устроить подменный сайт, Смена сертификата без смены ключа совершенно в этом плане не отличима от использования сертификата с большим сроком действия.
no subject
У Openvpn всё же обычное TLS соединение, рисков несколько меньше.
no subject
no subject
Ничего сложнее "вот этот порт, вот эта цепочка байт" на скоростях уже в гигабиты нормально работать не может. (Иллюстрацией можно посмотреть про "замедление твиттера", которое пытались сделать по "t.co" и не осилили.
Значит - если протокол хотя бы по начальной сигнатуре похож на TLS/SSL - его не будут фильтровать. А уж если он висит на 443-м порту - тем более. А openvpn такое умеет. при этом умеет и делить порт с веб-сервером - так что активные DPI тоже увидят всё что требуется
no subject
Матчасть изучите. На хабре было несколько статей про то каким образом DPI могут отлавливать OpenVPN.
no subject
openvpn в норме работает по UDP. Причем использует даже не DTLS, а свою собственную реализацию криптования UDP. В случае TCP оно безбожно тормозит. Что, правда, является вполне удобным фоллбэком на случай необходимости работы через невменяемого провайдера.
no subject
Если они не научатся что-то отлавливать в потоке udp2raw, прикидывающегося честным tls трафиком на 443 порту, должно выдержать.
Ну а на самый крайний случай надо морочиться v2ray и там уже просто честный https снаружи.
no subject
Так сказать лучше поздно чем никогда ;)
Может будет удобнее на p2p vpn посмотреть? Как пример - nebula vpn или tinc (возможно ещё zerotier)?
Они весьма аггресивно пробивают прямые соединения между машинами, так что можно просто весь трафик между машинами гонять по vpn. Единственное ограничение - nebula пока совсем не умеет turn если обе стороны совсем уж недоступны.
no subject
Какой смысл? wirequard уже есть в ядре. и этим интересне.
no subject
Если vpn устанавливает прямые соединения вся эта гимнастика не нужна.
no subject
Нужна. Как VPN установит прямые соединения при полном отсутствии связи локальной сети с интернетом?
no subject
В нормальной ситуации он живёт где-то в облаке, на публичном IP.
Но можно поднять второй прямо в локалке - и тогда машины внутри локалки переживут потерю интернета (в смысле nebula будет способна устанавливать прямые соединения между машинами в локальной сети).
no subject
Вот! То есть для того, чтобы эта VPN работала и тратила ресурсы моего процессора на совершенно ненужные мне действия (шифрование траффика в локальной сети) мне нужно научиться настраивать yen another серверный софт - этот самый lighthouse.
Зачем оно мне надо, если DNS-сервер все равно нужен?
Потом что DNS-сервер выполняет в любом случае полезную операцию - преобразует удобозапоминаемые имена компьютеров в адреса. Причем кеширующий DNS в локальной сети все равно нужен. Он очень сильно ускореят работу с удаленными машинами тогда, когда канал есть, но плохой. И настраивать DNS-сервера я умею уже 25 лет.
no subject
В случае nebula роль lighthouse играет она сама по себе (это просто флаг в конфиге любого из узлов сети).
no subject
Вот ту-то и засада - нужен выеделенный узел сети. Который всегда доступен. Поэтому логично что эту роль будет брать на себя VPS, размещенная на хостинге у провайдера - у нее аптайм самый большой. А если вдруг упал внешний канал, то в локальной сети этот узел оказывается недоступным.
В то время как использование разных протоколов в разных случаях обеспечивает graceful degradation. Если в сети есть нормальный роутер с dhcp/dns то работаем через его DNS,. Если вдруг оказалось что возможности радиотраткта роутера или наличие у него встроенного аккумулятора были нам при его выборе важнее возможности поставить на него OpenWRT, то падаем еще ниже - на bonjour/avahi.
А это будет работать даже если в сети вообще никакого роутера нет - стоит тупой свитч. И никакого постоянно включенного сервера тоже нет.
no subject
Но да - нужна какая-то машина или с openWRT или с линуксом/виндой которая более менее стабильно поднята.
no subject
Вообще одно времия я пытался настроить у себя privoxy, чтобы она решала через какую из возможных точек выхода из моего VPN ходил траффик на определенные сайты. Очень быстро понял, что это крайне неуодобно и лучше использовать FoxyProxy, которая торчит прямо в браузере и позволяет парой кликов мыши направить траффик вот на этот конкретный сайт через другую точку выхода.
Потому что в современном интеренте вот на этот сайт пускают с российского адреса. а не пускают с немецкого, это - наоборот, этот при попытке зайти с немечкого начинает разговаривать по-немецки, этот - пытаться доставить покупки вместо Москвы во Франкфурт.
Поэтому пытаться переложить выборо через что куда ходить на автомат приводит к большим неудобстам. Лучше это самому контролировать, доверяя автомату только техническую работу по поддержке принятых решений, а не само принятие решений.
no subject
И заодно позволяет прости использовать внутренние VPN адреса не задумываясь в одной сети мы находимся или нет.
no subject
Ну это просто пример того, что обеспечение связи между машинами - процесс зависящий от многих факторов. Поэтому не надо пытаться реализовать тупой автомат, который сделает это возможным всегда. А лучше иметь гибкое перенастраиваемое решение. Которое позволит легко адаптироваться к независящим от меня изменениям ситуации.
Вообще я счита.ю что "использовать адреса" - это унизительно. Не должен человек иметь дело с длинными последовательностями цифр. Человеку удобно иметь дело с удобнопнятными и легкозапоминаемиыми последователньностями букв - именами (машин, сетей и т.д.). А преобразовыввать эти имена в какие-то техничесие последовательности бит, удобные для автоматов - дело автоматов.
no subject
Более того оно само может работать как DSN сервер для имён вписанных в сертификаты.
no subject
no subject
no subject
Вот по-моему многие современные разработчики не могут понять что такое "мертвый аплинк".
no subject
В оригинале uplink/downling использовался для спутниковой связи.
В моём использовании - линк к провайдеру/интернет.