Проброс портов через VPN WireGuard до удаленной локальной сети

[WorldFace]

Добрый день!

Помогите пожалуйста разобраться, пошагово как настроить доступ к серверу.

Суть задачи отображена на схеме, т.е. подключаясь к белому IP иметь доступ к серверу в удаленной локальной сети.

Что имеем:

1. Keenetic Ultra (KN-1810) с белым IP адресом (WireGuard Server)

2. Keenetic Giga (KN-1011) с серым IP адресом (WireGuard Client)

3. Настроенный между ними WireGuard VPN по данной статье: https://help.keenetic.com/hc/ru/articles/360012075879

 

[stefbarinov]

1. Есть ли связь (ping) от  192.168.2.2 до 192.168.2.1?

2. Есть ли связь от 192.168.1.39 до 192.168.2.2?

3. На клиенте в настройках пира уберите 192.168.2.1/32, добавьте 192.168.2.0/24

[vasek00]

Не встречал такую как 0.0.0.0/24 ---- есть 0.0.0.0/0

[WorldFace]

10 минут назад, vasek00 сказал:

Не встречал такую как 0.0.0.0/24 ---- есть 0.0.0.0/0

Действительно, что то не то прописано

[WorldFace]

2 часа назад, stefbarinov сказал:

1. Есть ли связь (ping) от  192.168.2.2 до 192.168.2.1?

2. Есть ли связь от 192.168.1.39 до 192.168.2.2?

3. На клиенте в настройках пира уберите 192.168.2.1/32, добавьте 192.168.2.0/24

1. Да

2. Да

3. Поменял, не помогло, вернул в исходное.

[vasek00]

1 час назад, WorldFace сказал:

не помогло

Выключите все - другие подключения, правила, мрашрутизацию удалите на обоих роутерах.

1. На тот который сервер включить другие подключения потом правило потом прописать маршрут заново

2. На тот который клиент включить другие подключения потом правило потом прописать маршрут заново

Работает, если нет то перегруз роутера например тот который клиент.

Такое поведение бывает когда делаете очень много настроек в WEB (то один параметр меняете, то другой) при правильных настройках не работает.

Edited April 5, 2022 by vasek00

[Tendersea]

У меня похожая задача. WG server и клиент настроены и маршрутизация работает. То есть из сети клиента я вижу адреса на сервере и наоборот.

Но сделать переадресацию портов извне по принципу белый.айпи.адрес.сервера:порт на устройства в сети клиента у меня не получается.

Похожая конфигурация, когда кинетик клиент подключается к овпн серверу асус у меня работала. Я просто переадресовывал диапазон портов на адрес выданный ВПН клиенту, а уже в роутере клиента каждый адрес переадресовывал к устройству.

С вайргард между двумя кинетиками у меня так не получается. Настраивал переадресацию от входа провайдера до:

- интерфейса вайргард

- айпи адрес ВПН клиента-роутера

- локальный айпи клиента роутера

настраивал на входе в клиенте-роутере:

- со входа интерфейса вайргард

- с айпи адреса ВПН сервера

- с локального адреса ВПН сервера.

 

Ничего не работает. Что я неправильно делаю?

 

[writingeraser]

такая же проблема, один с белым ip второй с серым, между ними вг туннель, из обеих подсетей могу пинговать хосты из любой подсети, но вот настроить перенаправление порта с белого на хост в подсети серого не получается

[Frew]

Та же самая проблема.

[Dzmitry]

В результате получилось пробросить? У меня похожая проблема: есть гига (192.168.2.1) с белым ip и раннер (192.168.4.1) с серым.

Соединены через wireguard по инструкции, отлично видят друг друга и все устройства в объединенной домашней сети. На раннере поднят веб-сервер 192.168.4.2 на стандартном 80м порту. Будучи подключенным к wi-fi гига открываю в веб-браузере веб-страничку по адресу http://192.168.4.2:80 без проблем.

Но очень хочется чтобы этот же веб-сервер открывался по адресу белый-айпи:8881. Настроил порт форвардинг на гиге с wan интерфейса 8881 на "другое устройство" 192.168.4.2:80 - не помогло. Перепробовал все что только можно, кончились идеи

Отзовитесь плиз, кто знает в чем дело.

[v01d]

Схожая проблемам:

Есть KN-1011 со статическим ip, 192.168.1.0 

и tl-link на openwrt с серым ip, 192.168.2.0

между собой подключаются по wireguard, настроил по инструкции, все отлично видно.

из 192.168.1.0 нормальный доступ до 192.168.2.0

если пробрасывать порт клиента из 192.168.1.0 то работает

если поменять на другой из 192.168.2.0 то при подключении по внешнему адресу из сети 192.168.1.0 - адрес открывается, если отключиться и попробовать другое соединение то нет доступа.

 

[savizor]

Keenetic AIR KN-1613

Тот же самый вопрос - решить удалось кому?

Обе сети, связанные через WG,  прекрасно видят друг друга, но сделать проброс из интернета через "белый ip" в "серую сеть" не получается...

 

[v01d]

37 минут назад, savizor сказал:

Keenetic AIR KN-1613

Тот же самый вопрос - решить удалось кому?

Обе сети, связанные через WG,  прекрасно видят друг друга, но сделать проброс из интернета через "белый ip" в "серую сеть" не получается...

 

Я в итоге через keendns пробросил, напрямую не получается 

[savizor]

Есть подозрение (я не проф в линуксах) что при такой схеме вещей не маскарадятся правильно адреса - то есть запрос приходит из внешнего интернета в "серую" сеть с внешним же адресом, и соответственно роутер в "серой" отвечает совсем не туда куда нужно. 

Вариантов видится два:

1. Настроить NAT через WG - "серую" сеть пускать в интернет через роутер "белой" сети. Со всеми очевидными минусами этого решения

2. Запустить проксирование портов на сервере в сети с "белым" роутером - есть такая замечательная програма rinetd, у меня получилось через неё все сделать.

2a. Реквестировать у разработчиков встроить rinetd в keeentic 😃

 

Через облако keendns rtsp поток не пройдет к сожалению =(

 

[makerus]

В 22.12.2023 в 14:31, savizor сказал:

Есть подозрение (я не проф в линуксах) что при такой схеме вещей не маскарадятся правильно адреса - то есть запрос приходит из внешнего интернета в "серую" сеть с внешним же адресом, и соответственно роутер в "серой" отвечает совсем не туда куда нужно. 

Если верить захвату пакетов, то никакие пакеты в таком случае не дойдут до локальной сети из-вне. Если интересно почему - причина NAT. Если пытаться пробрасывать порты, то они пробрасываются через NAT по-сути. Если это внутренняя сеть - все ок. Если внешняя - то у этих портов будет изоляция, они не будут видеть другие подсети с этих портов, в том числе и подсеть wg. То есть проблема изначально в механизме NAT преобразований, который изолирует устройства от других соединений, определенным способом, для безопасности сети.

В 22.12.2023 в 14:31, savizor сказал:

1. Настроить NAT через WG - "серую" сеть пускать в интернет через роутер "белой" сети. Со всеми очевидными минусами этого решения

Чтобы ее туда пустить - нужен NAT, соответственно какой-нибудь DMZ, а DMZ сделает так, что изолирует уже не порт, а целый IP от других сетей. Поэтому в данном случае NAT можно настраивать до посинения, сам механизм NAT не даст такую возможность. На внешнем придется отрубать как раз NAT целиком, что как бы делает одну "большую дыру" и не факт, что даже такой метод заработает.
 

Единственным адекватным методом для проброски порта наружу из внутренней сети вижу - поднятие прокси. Как это сделать? Вот несколько вариантов.
1. Создать виртуальную машину - на ней, через iptables, настроить DNAT на порты, которые нужны (не забудьте добавить маскарадинг).

2. Установить на отдельном устройстве Fedora Server и Cockpit, включить дополнение Podman, загрузить образ: docker.io/jc21/nginx-proxy-manager:latest, запустить контейнер с этим образом (https://nginxproxymanager.com/guide/#features), открыть дополнительно порты в докер-контейнере, через которые будете прокидывать прокси. В самом приложении, которое запустится использовать раздел stream, который будет проксировать запросы tcp/udp.

3. Установить на отдельном устройстве чистый linux дистрибутив и настроить его в соответствии с п.1

4. Использовать свой ПК, с ПО позволяющее проксировать запросы.

5. Как советовал savizor

В 22.12.2023 в 14:31, savizor сказал:

есть такая замечательная програма rinetd, у меня получилось через неё все сделать

ps. Прокси ДОЛЖЕН находится в подсети БЕЛОГО IP. То есть ПО, которое будет куда-то проксировать в локальную сеть должно иметь ту-же подсеть, что и белый IP. Если белый IP находится в подсети 192.168.35.0/24, как в примере автора, то и прокси должен подниматься в этой же подсети и соответственно иметь адрес из этой подсети, например: 192.168.35.15. Если это отдельное устройство, которое используется для прокси (мини-пк, raspberry pi итд), то оно должно быть физически подключено к маршрутизатору у которого белый IP, чтобы физически находится в той же подсети и иметь к ней прямой доступ.

Других вариантов, кроме проксирования, к сожалению, к такой конфигурации сети - нет.

[Eugene A]

Странно. Работает. Keenetic 4.0.7 роутере с белым ip. 4.1.2 на домашнем. Но не думаю, что это принципиально.

[Fedro]

Есть частное решение такой задачи. По крайней мере я бы ее решал так, если серверов в  сети за роутером с серыми адресами не очень много. Я бы сделал отдельное подключение WG на роутере с белым IP, чтобы разделить задачи сетевого взаимодействия между локальными сетями и публикацией портов,  и напрямую подключил бы в него серверы, установив прямо на них клиентов WG. Потом, настроил бы этот интерфейс WG  согласно статье https://help.keenetic.com/hc/ru/articles/360010551419-Доступ-в-Интернет-через-WireGuard-туннель (назначаете интерфейс куда вы подключаете серверы приватным, включаете на нем NAT, разрешаете весь трафик). И весь трафик во внешний мир с этих серверов завернул бы через это подключение WG (мало, чтобы пакеты с проброшенных портов приходили на серверы, хорошо бы,  чтобы они еще туда же и уходили, откуда пришли). При этом ,если в качестве доступных сетей на клиентах указывать не 0.0.0.0/0 а указать AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 224.0.0.0/3 то все фейковые сети будут по прежнему маршрутизироваться через локальные интерфейсы серверов, а не через wireguard туннель, что позволит вам взаимодействовать с этими серверами из локальных сетей беспрепятственно. Не забывайте на клиентах указывать в настройках WG параметр DNS = 8.8.8.8 (или какой вы считаете нужным) Потом на вашем роутере с белыми IP вы просто пробрасываете порты на IP адреса, которые вы выдали в пуле WG и все работает.  Только что интереса ради на стенде решил такую (с некоторыми ограничениями) задачу - в общем то работает.

[Schwab Eugen]

В 29.03.2024 в 16:30, Fedro сказал:

Есть частное решение такой задачи. По крайней мере я бы ее решал так, если серверов в  сети за роутером с серыми адресами не очень много. Я бы сделал отдельное подключение WG на роутере с белым IP, чтобы разделить задачи сетевого взаимодействия между локальными сетями и публикацией портов,  и напрямую подключил бы в него серверы, установив прямо на них клиентов WG. Потом, настроил бы этот интерфейс WG  согласно статье https://help.keenetic.com/hc/ru/articles/360010551419-Доступ-в-Интернет-через-WireGuard-туннель (назначаете интерфейс куда вы подключаете серверы приватным, включаете на нем NAT, разрешаете весь трафик). И весь трафик во внешний мир с этих серверов завернул бы через это подключение WG (мало, чтобы пакеты с проброшенных портов приходили на серверы, хорошо бы,  чтобы они еще туда же и уходили, откуда пришли). При этом ,если в качестве доступных сетей на клиентах указывать не 0.0.0.0/0 а указать AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 224.0.0.0/3 то все фейковые сети будут по прежнему маршрутизироваться через локальные интерфейсы серверов, а не через wireguard туннель, что позволит вам взаимодействовать с этими серверами из локальных сетей беспрепятственно. Не забывайте на клиентах указывать в настройках WG параметр DNS = 8.8.8.8 (или какой вы считаете нужным) Потом на вашем роутере с белыми IP вы просто пробрасываете порты на IP адреса, которые вы выдали в пуле WG и все работает.  Только что интереса ради на стенде решил такую (с некоторыми ограничениями) задачу - в общем то работает.

Бьюсь несколько дней, прошу о помощи. Если не сложно, подробнее, можно в картинках, что и куда прописать в настройках, чтобы кинетик клиент вышел в инет через кинетик сервер.

Сейчас у меня получилось подключиться с телефона на WG сервера, зайти к нему на CLI и написать эти три команды, которые в статье указаны. Дальше не пускает. Точно так же кинетик клиент подключается и никуда не выходит дальше. 

Вроде бы и маршруты на сервере указал, разрешил всё и везде по протоколу IP, и 0.0.0.0/0 + 8.8.8.8 на клиенте, ничего не выходит. 

Заранее благодарен

Edited April 2, 2024 by Schwab Eugen

[Scatman_John]

В 31.03.2022 в 17:52, WorldFace сказал:

Добрый день!

Помогите пожалуйста разобраться, пошагово как настроить доступ к серверу.

Суть задачи отображена на схеме, т.е. подключаясь к белому IP иметь доступ к серверу в удаленной локальной сети.

 

Доброго времени суток! Задачу решили? Если ответ "да", то каким образом?

[dlnk-spb]

Стоит аналогичная задача. Долго бился, абсолютно так же через wireguard не получалось пробросить. Единственный сработавший у меня вариант - соединять сети через PPTP. Все остальные испробованные мною варианты туннелей (OpenVPN, IPSec, Wireguard) не позволили пробросить порт.

[Vladislav23]

Здравствуйте. Работала такая схема у меня, уже лет десять,  с начала на Asys по PPTP, затем сменил его на SynoLogy где эта связка работала совместно с Ultra (KN-1810) по протоколу OpenVPN. Тут решил перейти с Synology на Ultra (KN-1811), все настроил и вот бьюсь уже с этой проблемой несколько дней, дома все работает, даже удаленные адреса спокойно пробрасываюся, Но из другого места ни в какую, хотя в локальную сеть порты пробрасываются и все работает отлично. Да, забавная история, это явный косяк, поскольку на других моделях других производителей это работает как часы. Видимо надо возвращать старый роутер и ждать решения этого бага.  Интересно разработчики в курсе этого?

 

[Vladislav23]

В поддержке мне ответили 

-"

Пример корректной настройки проброса для туннеля выглядит так:

1. На стороне WG-сервера необходимо включить NAT в CLI Интерфейс командной строки (CLI) интернет-центра

ip nat Wireguard0
system configuration save

2. На стороне клиента роутера включаем приорити - Использовать для выхода в Интернет для подключения Wireguard:

Далее делаете настройку проброса, как описано в статье - Проброс портов через интернет-канал VPN-сервера в удаленную локальную сеть за VPN-клиентом:"

Я все сделал, но все равно это не заработало. Причем я написал, что не в восторге что после этого весь трафик пойдет по VPN каналу. 

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

все это работало без этого, имею ввиду галочку в настройках "использовать для выхода в интернет".   

 

[sluggard]

Всем привет.

Возможно у меня данный функционал реализован не корректно, но я не нашел другого решения так как я не системный администратор и много не понимаю в сетях, но оно работает

1. Потребуется поддержка OPKG, так как нам потребуется установить iptables.

2. После установки поддержки OPKG и iptables в папку /ваша флешка/etc/ndm/netfilter.d/ положил iptables.sh следующего содержания:

#!/bin/sh

[ "$table" != filter ] && exit 0
iptables -I INPUT -i lo -j ACCEPT
iptables -I FORWARD -i br0 -o nwg0 -j ACCEPT
iptables -I FORWARD -i nwg0 -o br0 -j ACCEPT
iptables -I FORWARD -i nwg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o nwg0 -j MASQUERADE

#открываем порт 9200
iptables -I INPUT -p udp --dport 9200 -j ACCEPT
iptables -I OUTPUT -p udp --sport 9200 -j ACCEPT

#пробрасываем порт на сервис в удаленной сети
iptables -t nat -A PREROUTING -p tcp -d "белый ip адрес" --dport 9200 -j DNAT --to-destination 192.168.1.200:80
iptables -t nat -A POSTROUTING -p tcp -d 192.168.1.200 --sport 80 -j SNAT --to-source "белый ip адрес":9200

Сеть 192.168.1.1 - сеть на даче объеденная с городской сетью 192.168.4.1 по WGuard и белым ip адресом:

В итоге после всех манипуляций я имею доступ к удаленным сервиса в обедненных сетях по адресу "белый ip адрес":9200

 

Если кто то посоветует иное, более корректное решение или укажет на явные проблемы в безопасности, с удовольствием послушаю и поправлю

Edited October 22, 2024 by sluggard