есть дом, в нем стоит keenetic с серым адресом, но провайдер предоставляет мне DDNS имя через свой сервер.

на keenetic поднят Open VPN сервер (правда пока выключен, но включить дело плевое)

вот тут описание https://help.keenetic.com/hc/ru/articles/360000880359-Сервер-OpenVPN

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

а теперь вопрос - как настроить с android ?

https://play.google.com/store/apps/details?id=de.blinkt.openvpn

(0) А у кинетика же свой какой-то DDNS есть.

(2) я не хочу свой трафик через них пускать, так сказать лишнее звено, тем более у них написано, что скорость может падать в зависимости от количества активных клиентов

(0) что за серый адрес ?

Ну не знаю зарегался на кинетик, подлучил доменное имя хххххххххх.keenetic.pro
На кинете устанавливаешь VPN-сервер SSTP, туда прописываешь пользаков, ставишь любой клиет на андрюшу VPN SSTP, к примеру MS-SSTP прописываешь там доменное имя, Имя пользователя и пароль, и все ты в домашней сети, далее у меня на компе открыт удаленный раб стол, свободно на него захожу

(5) у официального клиента android нет настроек, там файлик надо подсунуть.

(6) а есть ссылка на официальный клиент?

https://play.google.com/store/apps/details?id=net.openvpn.openvpn

(3) Так ты и не будешь. Нафиг им твой трафик - DDNS только днс записи обслуживает, что бы ты узнал какой у тебя апишник текущий. Но это не будет работать, если ты через НАТ к провайдеру подключен.

(7) Попробуй лучше wireguard. Кинетиками и андрюшами поддерживается. Настроек кот наплакал. То что надо для простого ВПН.

https://help.keenetic.com/hc/ru/articles/360010304780

угу l2tp или wg

а openvpn тормозная хрень

(12) l2tp, как и все прочие протоколы основанные на ppp, убоги по определению, ибо выросли из диалапа. А ipsec придуман какими-то ..ипсеками. К сожалению, они сумели пропихнуть его в стандарт, при том что кривее и неудобнее протокола для vpn вряд ли найти. Куча привязанных сбоку сущностей, заставляющих вставать раком все протоколы маршрутизации и трансляции адресов. Разве что какие-нибудь отечественные поделки типа ФПСУ-IP с этим могут сравниться.

У OpenVPN же есть уникальная фича - туннель 2 уровня. То есть через него можно соединять разные сети как будто они в одном бридже. По поводу тормознутости - ну, наверное всё зависит от того, что в ядре линукса поддержки этого протокола нет и он реализован в юзерспейсе.

(10) я вот что-то с первого раза не скумекал, как wg-соединение с VPN-сервером использовать в кинетике для доступа к инету. С OpenVPN все относительно понятно - копируешь конфиг, ставишь галки "Получать маршруты от удаленной стороны" и "Использовать для выхода в Интернет", и вуаля - подключение можно использовать. В wg-подключениях нет галки "Получать маршруты от удаленной стороны". Данные проимпортировал, все выглядит как живое, соединение устанавливается и даже какие-то байты через него проскакивают. Но - при попытке посадить на это подключение клиента у него нет соединения с инетом.

(14) На клиенте укажи какой трафик будешь в впн тунелировать (AllowedIPs). Если весь то должно быть примерно вот так.
[Peer]
PublicKey = ключ
AllowedIPs = 0.0.0.0/1, 128.0.0.0/1
Endpoint = адрес сервера
PersistentKeepalive = 30

(15) Вот же статья даже есть https://help.keenetic.com/hc/ru/articles/360010551419
Еще на кинетике нужно НАТ на wg интерфейсе включить. ВСе в статье

(0) У кинетика своя служба переброса трафика по http/s есть и работает более менее норм. Ещё sttp тунель есть. Для 10 терминалов в fhd хватает экспериментально.

(16) статейку находил и пытался делать то что там написано. Не помогло, хотя, возможно, я не вполне понял содержимое. Когда там написано про Wireguard сервер - это имеется в виду настройка серверной части подключения на кинетике или реально удаленный сервер, к которому мы подсоединяемся?

(18) В данной статье под серевером подразумевается кинетик с реальным ip.
Ты объясни что тебе нужно. Настройки разные.
Вариант 1. Андроид - Кинетик - Большой интернет
Вариант 2. Андроид - Кинетик - свой сервер

(19) ни то и ни другое. У меня на кинетике клиентское wireguard подключение, которое подключено через российского интернет-провайдера к удаленному серверу в другой стране.
И нужно весь или часть трафика домашней сети маршрутизировать в это подключение. Для начала хотя бы весь. Дальше я VLANами разделю, какие узлы у меня пойдут через российского провайдера, а какие через VPN.
С OpenVPN у меня сразу получилось это сделать.
С Wireguard - нет.

(20) Ну тогда у тебя кинетик WG клиентом будет.
В нем нужно AllowedIPs = 0.0.0.0/1, 128.0.0.0/1 указать. Тогда весь трафик туда завернется. Ну и проверить что бы в маршрутизации кинетика эти диапазоны из wg соединения автоматом прописывались.

(21) в выходные поковыряю еще. Так-то с OpenVPN все работает, но я рассчитываю, что с wg скорость побольше будет...

(21) не танцует. В случае с OpenVPN подключением кинетик автоматически прописывает маршруты (там есть галка "Получать маршруты от удаленной стороны", может, она влияет, для wg подключений такой галки нет), и при этом при установке соединения создается связанная с ним новая сеть и новый шлюз, он и прописывается в маршрутах. А вот для wg все это непонятно, также как и непонятно, как прописывать вручную маршрут, потому что непонятно в какой сети шлюз.

(21) разобрался где посмотреть шлюз и добавил маршрут. Получилось. Скорость работы через wg существенно выше чем через ovpn, на загрузку выходит 60 мбит против 20.

дело действительно в этой галке, для wg кинетик автоматом не прописывает маршруты, как для ovpn.

да для wg надо вручную маршруты прописывать или конкретные или весь трафик разрешить транслировать

Ipsec это не совсем vpn,это шифрование трафика и гарантия от подмены,соответсвенно ни nat ни другие способы трансляции для него не подходят,однако,роутер может его расшифровывать и зашифровывать заново,что,обычно,и делается.

(27) А какой смысл в таком шифровании трафика, если этот трафик через маршрутизаторы не способен проползти без костылей типа nat-t? Сначала придумаем сферическое шифрование трафика в вакууме, которое никому нафиг не нужно, а потом придумаем инкапсуляцию этого в udp, чтобы хоть как-то можно было с этим работать... Совершенно не понимаю логику авторов этой технологии.

(28) просто нужно понимать, что протокол этот из конца девяностых. Тогда даже для домашних пользователей использовался dialup и ISDN, где на конечное устройство выдавали белый IP, а про компании и говорить нечего. Все эти ваши NATы массово появились ближе к середине нулевых, тогда же появилась и затычка в виде NAT-T для IKE. Дата у соответствующего RFC 3947 - 2005 год. И даже сейчас, я думаю, большинство IPSec туннелей настроено в основном между корпоративными шлюзами с белыми IP.

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

(30) Если внезапно провайдер не пустит трафик через NAT)

(29) Ну да, многие старые протоколы грешат плохой поддержкой NAT. Тот же ftp или h.323 вспомнить можно. А вообще, в конце 90-х NAT уже использовался. Были всякие wingate, winroute и общий доступ к подключению средствами винды. Не говоря уж о линуксах. И уже тогда хотелось через диалап подключить более одного компа. Так что разработчики ipsec проявили удивительную недальновидность, как будто они находились в 70-е, а не в 90-е)

(32) в шлюзах обработка IPSec-туннелей идет до того, как трафик проходит через NAT. Так делается до сих пор.
Если провайдер пустит трафик через NAT, то да, спасает только NAT-T, и то не всегда. Через некоторых провов IPSec не ходит нормально.

впрочем, не только он. GRE у PPTP тоже, бывало, резали...