Ура! Все получилось. Как и думал, что-то я не учел.
Проблема заключалась в том, что если в конфиге сервера /etc/wireguard/wg0.conf
не прописать параметр: SaveConfig = false , то настройки для пиров стираются после поднятия интерфейса. В результате чего AllowedIPs = 10.0.0.2/32, 192.168.0.0/24 превращается в AllowedIPs = 10.0.0.2/32 и , как следствие, исходящий трафик блокируется .
Помогла вот эта статья https://jrs-s.net/2018/08/05/routing-between-wg-in...
Теперь все получилось, я спокойно могу получить доступ к локальной подсети любого пира, подключенного к тому же серверу WineGuard.
Собственно для успешной реализации моей задачи понадобилось следующее:
2). На сервере в /etc/wireguard/wg0.conf делаем следующие изменения: SaveConfig = false (чтобы не сбивались настройка доступов)
Для каждого пира пописываем подсеть, к которой мы хотим получить доступ, например
AllowedIPs = 10.0.0.2/32, 192.168.0.0/24 ,
перезагружаем конфиг
wg-quick down wg0
wg-quick up wg0
3). на клиенте с интерфейсом 192.168.0.1 в файле /etc/network/interfaces я добавил 2 строчки для интерфейса wg-p2p
pre-up iptables -t nat -A POSTROUTING -o enp0s3 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -o enp0s3 -j MASQUERADE
или просто можно прописать в перманентные правила
iptables -t nat -A POSTROUTING -o [ваш интерфейс] -j MASQUERADE
4). на том клиенте, с которого мы хотим получить доступ к локальной подсети, добавляем маршрут
route add -net 192.168.0.0/24 gw 10.0.0.2
<code>
P.S. не знаю, правда, чей ответ пометить решением, ибо помогли оба, спасибо.
Спасибо, в принципе так и делал. Упростил себе задачу , пробую получить доступ к подсети 192.168.0.1 с сервера WireGuard. Вроде делаю все верно, но где-то видно туплю, ибо все равно не работает.
Т.е. на сервере прописал следующее:
route add -net 192.168.0.0/24 gw 10.0.0.2
вывод route
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default х.х.х.1 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
х.х.х.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0
192.168.0.0 10.0.0.2 255.255.255.0 UG 0 0 0 wg0
на клиенте с интерфейсом 192.168.0.1 такое:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o enp0s3 -j MASQUERADE
вывод ping 192.168.0.1 с сервера
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
ping: sendmsg: Required key not available
tcpdump на клиентской тачке на интерфейсе wg молчит, т.е. ни каких пакетов к нему не прилетает
вывод iptables на серверной машине С которой пытаюсь достучаться до 192..
Многие камеры стоят за NATом в разных местах. Делать пробросы не очень хочется, да и особого смысла в этом нету. А настроить исходящий поток со всех камер в одно место , чтобы там уже просматривать события со всех камер было бы удобно. Собственно оно так сейчас и работает, просто хочется какой-то красивой и удобной админки.
xmoonlight, тут вопрос не в том, что непривычно, а в опыте решения подобных задач.
Ну и в задаче не хватает кучи условий, например откуда забирать почту, по какому протоколу ...
Пример решения https://www.toptal.com/php/building-an-imap-email-... но повторюсь, это дикие костыли и так не делается!
Есть же языки, где -то делается в пару строк, при чем с интеграцией в любой вэб сервер ...
АртемЪ, собственно а в чем проблема? Я в первом же ответе написал:
"xmoonlight, нужно ГОТОВОЕ решение, у меня нету месяца жизни на это. Понятно , что все написать можно, но зачем изобретать велосипед. Меня устроит и платное решение. Главное чтобы свое облако."
дальше человек начал троллить и угрожать банами - браво ребята! Была бы кнопка игнор, я бы ее нажал сразу.
Ладно, объясняться больше не собираюсь тут. Не нравится мои ответы - игнорируйте. Модератора прошу удалить первый бессмысленный комментарий к вопросу и все остальные ответы. Тэги поправил , считаю все по делу. Сейчас вопрос немного уточню.
xmoonlight, ну дак обычные же скрипты на PHP нужны . Можно на фрилансе заказать ...
А вообще решать эту задачу на PHP - вообще неразумная затея. И прямой путь отгрести кучу проблем. Задача решается штатными средствами системы, которые будут принимать почту и аккуратно складировать ее куда-то, например, если уж так хочется, в базу, откуда уже вытаскивать php скриптом ... в крайнем случае дергать какой-то питоновский скрипт , но это все какие-то дикие костыли.
Тут в постановке вопроса архитектурная проблема и заходить надо со стороны, а зачем это понадобилось и нельзя ли это решить иначе.
xmoonlight, "на PHP" - это подразумевается использованным интерпретатором PHP , а про то, на чем он должен быть написан не слова ...
Зачем изобретать велосипед, если есть куча готовых решений.
АртемЪ, и? Ответ на вопрос заключается в ссылке не фриланс - браво!
Я спрашиваю про ГОТОВЫЕ решения при достаточно четкой постановке вопроса. Меня устроят и платные ГОТОВЫЕ решения.
Тут можно на каждый вопрос отвечать мол пиши сам или или иди на фриланс. А мне нужно конкретно решить задачу использую готовые решения.
Моя задача достаточно типовая, потому и не сомневаюсь, что куча подобных решений и писать свое или заказывать на фрилансе - бред.
xmoonlight, нужно готовое решение, у меня нету месяца жизни на это. Понятно , что все написать можно, но зачем изобретать велосипед. Меня устроит и платное решение. Главное чтобы свое облако.
И что странного в задаче. Если вы пользуетесь данными инструментами, это не значит, что ми ограничивается вся область применения Linux.
Тот же VB прекрасно работает с MS . Я пробрасывал RDP внутрь контейнеров, работало это идеально при пинге > 60ms .
От винды хотелось уйти не по финансовым соображениям.
KVM\LXC\Docker - Как раз добиться хотя бы минимальной плавности работы не удавалось.
x2go вообще хочется забыть как страшный сон. Может сейчас что-то изменилось, на когда я его пытался использовать, ничего кроме мук это не принесло.
Спасибо! Но пока у меня самый длинный сегмент I2C меньше 20 метров. Работает по витой паре SFTP Cat.5E без лишних заморочек. Будем надеяться , что так везде будет.
На данный момент частично уже сделана проводка по некоторым комнатам. Использовать все же решил SFTP Cat.5E, на всякий случай протянутый в металлорукаве.
Тестовый образец собрал банально. Обжал коннекторы, взял RJ45 розетки, к выводам припаял XH 2.54 коннекторы, на которые уже цеплял датчички. На пары пока вообще не обращал внимания. Тупо распаял как было удобно, т.е. , допустим тот же i2c bme280 датчик тупо распаян прямо в RJ45
розетке. По одной витухе идет питание, по другой данные. Работает на сегменте в 18 метров (самый длинный), чем меня сильно удивил. Был уже готов что-то мудрить, но пока все работает штатно. Такой же кабель завожу к выключателям, буду закорачивать их релюхами, чтобы можно было удаленно включать свет.
В концепте пока все работает в боевых условиях. Буду дальше также делать по всему дому.
Виктор Таран: remmina , если я не ошибаюсь, запускает его же (или использует код) просто в окошке и с параметрами. При правильной настройке нет совершенно ни каких проблем, постоянно работаем с ним , подключаясь к виндовым rdp. Плюс из коробки работа с многомониторными системами ...
Да вообще работать, повторюсь, там даже банально полистать главную хабры с картинками, идет прорисовка часятми, очень неприятно. В остальном также, начать работать в виртуалке, те же проблемы. Ладно бы все свалить на канал и успокоится, но не дает покоя то, что RDP виндовый летает, вот что обидно.
Проблема заключалась в том, что если в конфиге сервера /etc/wireguard/wg0.conf
не прописать параметр:
SaveConfig = false , то настройки для пиров стираются после поднятия интерфейса. В результате чего AllowedIPs = 10.0.0.2/32, 192.168.0.0/24 превращается в AllowedIPs = 10.0.0.2/32 и , как следствие, исходящий трафик блокируется .
Помогла вот эта статья https://jrs-s.net/2018/08/05/routing-between-wg-in...
Теперь все получилось, я спокойно могу получить доступ к локальной подсети любого пира, подключенного к тому же серверу WineGuard.
Собственно для успешной реализации моей задачи понадобилось следующее:
1). Устанавливаем WireGuard , я делал вот по этому мануалу https://habr.com/ru/post/474250/ прям там же на DigitalOcean.
2). На сервере в /etc/wireguard/wg0.conf делаем следующие изменения:
SaveConfig = false (чтобы не сбивались настройка доступов)
Для каждого пира пописываем подсеть, к которой мы хотим получить доступ, например
AllowedIPs = 10.0.0.2/32, 192.168.0.0/24 ,
перезагружаем конфиг
3). на клиенте с интерфейсом 192.168.0.1 в файле /etc/network/interfaces я добавил 2 строчки для интерфейса wg-p2p
pre-up iptables -t nat -A POSTROUTING -o enp0s3 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -o enp0s3 -j MASQUERADE
или просто можно прописать в перманентные правила
iptables -t nat -A POSTROUTING -o [ваш интерфейс] -j MASQUERADE
4). на том клиенте, с которого мы хотим получить доступ к локальной подсети, добавляем маршрут