Единственное что я не понял, это будет работать в белые списки или нет?
Если ответить развернуто, то будет зависеть от способов которым обеспечиваются тотальные блокировки (мне этот термин кажется более корректным, чем "белые списки"), от расположения вашего сервера, от того будет ли он доступен при тотальных блокировках, если будет, то по каким протоколам к нему можно будет подключиться и т.д.
Если ответить коротко, то, скорее всего нет. И даже наличие сервера внутри России при тотальных блокировках вам вряд-ли поможет, т.к. маловероятно что ваш сервер окажется среди тех ресурсов которые будут доступны в таких условиях.
Автор, вообще, что-то темнит. В пределах РФ к VPN относятся вполне лояльно.
У вас свой опыт - у меня свой. И в моём опыте есть масса примеров когда усилиями Роскомнадзора переставали работать VPN-ы соединяющие офисы даже внутри одного региона России, после чего приходилось им писать, просить и требовать.
Я так понимаю, интерфейс на Keenetic, на который все это дело вешается, имеет статус Public у Вас, верно?
Объясните, пожалуйста, что это значит? Я не понимаю вопроса в такой формулировке.
Даже в этом случае, как по мне, давать доступ извне на все хосты домашней сети все-таки не самое лучшее решение.
Мне удобно что у меня есть доступ к моей домашней инфраструктуре через то-же самое подключение, через которое доступен нормальный Интернет. И я считаю это объяснение вполне достаточным.
Ну, есть у Вас ftp-сервер, сервер-стенд ... еще что-то - нет вопросов, можно дать, но ко всем-то зачем? Не знаю, может, у Вас есть какие-то веские основания на иное видение, но, по-моему, так!
На данный момент у меня гипервизоре крутятся 19 виртуальных машин, с разными ролями. И их количество может изменяться, при необходимости. Плюс есть некоторое количество физических рабочих станций. Некоторые из них используются для обычной работы, некоторые - для экспериментов. Создание для каждого компьютера отдельных сетевых правил я посчитал слишком затруднительным. А в рамках написания этой статьи - еще и не целесообразным.
Эта статья писалась, в том числе, как пример не совсем стандартного использования Amnezia VPN. Например если вы захотите связать между собой два территориально удалённых офиса, то некоторые приёмы из этой статьи могут оказаться вам полезными.
И да, конечно, вы можете проявить кретивность и что-то сделать по-другому или не делать совсем.
Плюс не забывайте вот про это предложение:
При создании правил вам придётся немного подумать о том с каких именно адресов / подсетей на какие адреса / подсети вы хотите разрешить доступ.
меня очень смущает один немаловажный момент: установка идет через root доступ к серваку из их приложения
В самом конце статьи я дал рекомендацию - отключить доступ по логину/паролю к вашему серверу после окончания настройки и ходить к нему только по ssh-ключу. Что также отключит доступ по логину/паролю сохранённому в приложении Amnezia VPN. Это, конечно, не гарантирует полной безопасности вашего сервера, но шанс на несанкционированный доступ всё-таки уменьшает.
если я таким способом в домашнюю сеть попаду, то и во внешний интернет тоже?
Если ваш вопрос касался опубликованной статьи - то да. При подключении извне к вашему VPN-серверу вы будете ходить через него и в Интернет и в вашу домашнюю сеть.
Я, в своё время, разворачивал AmneziaWG без Docker вот по этой инструкции. Сразу скажу что надо использовать Ubuntu 22.04. На Ubuntu 24.04 у меня не заработало. И, помимо команды pip install qrcode надо еще выполнить pip install pillow.
Небольшое замечание по-поводу настройки демона keepalived на трёх master-нодах. Автор пишет что на всех трёх узлах необходимо указать:
state BACKUP
priority 100
Это не совсем верно. При такой конфигурации при "холодном старте" kubernetes-кластера (полное выключение всех нод кластера и последующий запуск) - регулярно будут возникать ситуации, когда виртуальный IP-адрес кластера отвечает на ping, но вот подключение к управляющему интерфейсу кластера с внешнего компьютера (не входящего в кластер) будет невозможно, с получением ошибок TLS-соединения.
Более правильным будет на одной из нод указать state MASTER и дать ей больший приоритет, например priority 101, после чего нодам кластера будет понятно что в первую очередь кластерный IP необходимо назначать на эту ноду, и только в случае её недоступности - на одну из BACKUP-нод.
Подробнее можно прочитать в документации по High Availability Considerations.
К слову, из этого также стаёт понятно, почему в связке с keeplived рекомендуется использовать haproxy. Т.к. без него все соединения будет обрабатывать только та нода, которая в данный момент держит IP-адрес кластера и чаще всего это будет нода отмеченая как MASTER, а остальные ноды будут простаивать. Haproxy решает эту проблему за счёт банального round-robin, пересылая каждый следующий запрос на следующую ноду, вне зависимости от того какая из нод сейчас обслуживает кластерный IP-адрес.
Ну и напоследок, в той-же Ubuntu 22.04 вместо интерфейса ens33 будет eth0 (но это уже просто маленькое дополнение).
Если ответить развернуто, то будет зависеть от способов которым обеспечиваются тотальные блокировки (мне этот термин кажется более корректным, чем "белые списки"), от расположения вашего сервера, от того будет ли он доступен при тотальных блокировках, если будет, то по каким протоколам к нему можно будет подключиться и т.д.
Если ответить коротко, то, скорее всего нет. И даже наличие сервера внутри России при тотальных блокировках вам вряд-ли поможет, т.к. маловероятно что ваш сервер окажется среди тех ресурсов которые будут доступны в таких условиях.
У вас свой опыт - у меня свой. И в моём опыте есть масса примеров когда усилиями Роскомнадзора переставали работать VPN-ы соединяющие офисы даже внутри одного региона России, после чего приходилось им писать, просить и требовать.
Объясните, пожалуйста, что это значит? Я не понимаю вопроса в такой формулировке.
Мне удобно что у меня есть доступ к моей домашней инфраструктуре через то-же самое подключение, через которое доступен нормальный Интернет. И я считаю это объяснение вполне достаточным.
На данный момент у меня гипервизоре крутятся 19 виртуальных машин, с разными ролями. И их количество может изменяться, при необходимости. Плюс есть некоторое количество физических рабочих станций. Некоторые из них используются для обычной работы, некоторые - для экспериментов. Создание для каждого компьютера отдельных сетевых правил я посчитал слишком затруднительным. А в рамках написания этой статьи - еще и не целесообразным.
Эта статья писалась, в том числе, как пример не совсем стандартного использования Amnezia VPN. Например если вы захотите связать между собой два территориально удалённых офиса, то некоторые приёмы из этой статьи могут оказаться вам полезными.
И да, конечно, вы можете проявить кретивность и что-то сделать по-другому или не делать совсем.
Плюс не забывайте вот про это предложение:
В статье нет указания конкретных городов, стран и хостинг-провайдеров. Выбор где размещать ваш VPS остаётся за вами.
В самом конце статьи я дал рекомендацию - отключить доступ по логину/паролю к вашему серверу после окончания настройки и ходить к нему только по ssh-ключу. Что также отключит доступ по логину/паролю сохранённому в приложении Amnezia VPN. Это, конечно, не гарантирует полной безопасности вашего сервера, но шанс на несанкционированный доступ всё-таки уменьшает.
Если ваш вопрос касался опубликованной статьи - то да. При подключении извне к вашему VPN-серверу вы будете ходить через него и в Интернет и в вашу домашнюю сеть.
Я, в своё время, разворачивал AmneziaWG без Docker вот по этой инструкции. Сразу скажу что надо использовать Ubuntu 22.04. На Ubuntu 24.04 у меня не заработало. И, помимо команды pip install qrcode надо еще выполнить pip install pillow.
Ну и для общего ознакомления можете почитать про различные сценарии использования Wiregard.
Небольшое замечание по-поводу настройки демона keepalived на трёх master-нодах. Автор пишет что на всех трёх узлах необходимо указать:
Это не совсем верно. При такой конфигурации при "холодном старте" kubernetes-кластера (полное выключение всех нод кластера и последующий запуск) - регулярно будут возникать ситуации, когда виртуальный IP-адрес кластера отвечает на ping, но вот подключение к управляющему интерфейсу кластера с внешнего компьютера (не входящего в кластер) будет невозможно, с получением ошибок TLS-соединения.
Более правильным будет на одной из нод указать state MASTER и дать ей больший приоритет, например priority 101, после чего нодам кластера будет понятно что в первую очередь кластерный IP необходимо назначать на эту ноду, и только в случае её недоступности - на одну из BACKUP-нод.
Подробнее можно прочитать в документации по High Availability Considerations.
К слову, из этого также стаёт понятно, почему в связке с keeplived рекомендуется использовать haproxy. Т.к. без него все соединения будет обрабатывать только та нода, которая в данный момент держит IP-адрес кластера и чаще всего это будет нода отмеченая как MASTER, а остальные ноды будут простаивать. Haproxy решает эту проблему за счёт банального round-robin, пересылая каждый следующий запрос на следующую ноду, вне зависимости от того какая из нод сейчас обслуживает кластерный IP-адрес.
Ну и напоследок, в той-же Ubuntu 22.04 вместо интерфейса ens33 будет eth0 (но это уже просто маленькое дополнение).