R0cky

Сталкивались. Это результат работы DPI РКН.

Что примечательно такие проблемы только с samba траффиком. При скачивании файлов по протоколу http видел скорости более 50 мбит/сек.

Присоединяюсь к проблеме. Самба протокол (сервер самбы поднят не на роутере, а в локальной сети) через wireguard туннель, работает очень медленно. Скорость не превышает 200-300 килобайт в сек. На канале 330 мбит. При этом если из внешней сети зайти в локалку по wireguard подключению, используя вместо встроенного в прошивку keenetic`а сервера wireguard отдельную машину в локальной сети с debian на борту и поднятым wireguard сервером, то скорости работы с samba достигают тарифных показателей, обещанных провайдером. Нужны комментарии от производителей прошивки. Это баг или фича? )

Маршрутизация не избирательно направляет весь исходящий трафик до определенного узла через заданный интерфейс Для задачи пустить подключение wireguard через определенный интеренет-интерфейс это не всегда подходит потому что: 1. Ип адрес устройства, на котором поднят wireguard сервер может быть динамическим и тогда придется маршрутизировать целые подсети. Если маршрутизировать подсеть, то в ней могут быть ресурсы, на которые необходимо ходить через wireguard. Возникает противоречие, которое маршрутизацией никак не решить. 2. На самом устройстве, где поднят wireguard сервер могут присутствовать другие сервисы, доступ к которым пойдет мимо wireguard. А в случае если в политике доступа для клиента запрещены любые подключения кроме впн Wireguard (иногда такое требуется например для обхода ограничений опсосов), то доступ до этих сервисов блокируется. Вот такая петрушка с этим костыльным решением путем маршрутизации.

Разрабы до сих пор не могут допилить для Wireguard куда более востребованную функцию - Возможность выбора интернет-подключения, через которое будет осуществляться подключение к впн серверу. А вы тут совсем нестандартные хотелки реализовать предлагаете. Очень вряд ли дождетесь. Ищите костыли

А вот эти настройки на роутере с белым ип делали? WireGuard-интерфейсу должен быть установлен уровень безопасности private. Для этого потребуется в интерфейсе командной строки (CLI) роутера ввести следующую команду (в нашем примере для интерфейса Wireguard0): interface Wireguard0 security-level private Также для интерфейса должна быть включена установка автоматической трансляции адресов (NAT). Для этого потребуется ввести команду: ip nat Wireguard0 Это необходимые и достаточные условия. Настройки на сервере следует сохранить при помощи команды: system configuration save

stefbarinov Я так и сделал изначально.

vasek00 Сервер Wireguard поднят на другом кинетике, этот кинетик подключен к провайдеру, который выдает белый динамический ип. Соответственно частота смена ип рандомная. Пока в качестве временного решения прописал на клиентском роутере статические маршруты до всех подсетей, которые используется провайдером на стороне сервера в качестве выходных белых ип клиентов. Но все таки хотелось бы нормальной реализации данной опиции в прошивке роутера, чтобы без танцев с бубном решать довольно элементарный вопрос. Кстати вот неплохой сервис, который позволяет узнать диапазоны выходных ип прова по заданному ип адресу: https://xseo.in/asn

vasek00 Спасибо. Но ИМХО это костыль. Который не решает ряд проблем. Например как быть, если сервер wireguard имеет динамический ип (доступ идет по доменному имени), и следовательно прописать до него статический маршрут невозможно? Это как раз мой случай.

Добрый день. Такой вопрос. При настройке wireguard vpn в веб интерфейсе в отличие от других видов vpn (например PPTP, OpenVPN) нет возможности выбрать через какое интернет подключение устанавливать соединение с удаленным сервером wireguard. Соответственно коннект идет через то подключение, которое стоит первым в политике доступа в интернет по умолчанию. Это приводит к не оптимальной работе или даже ошибке когда в политике по умолчанию в качестве приоритетного подключения выбрано другое впн подключение. Имеется ли возможность выбрать для wireguard vpn интернет-подключение, отличное от того, которое стоит в политике по умолчанию?

Butyc ipv6 у провайдера, к которому подключен роутер включен? если да, то выключите его

Убедитесь, что ип адрес вашего роутера в локальной сети именно 192.168.1.1

Добавлю, что современные браузеры (в том числе их мобильные версии) все чаще обзаводятся своими днс сервисами якобы для пущей конфиденциальности (по типу dnscrypt). Для корректной работы алгоритма обхода эти сервисы в используемых вами браузерах необходимо отключать.

Безусловно

Перенаправление днс запрсов с подсетей впн сервера или гостевой сети: iptables -w -t nat -A PREROUTING -p udp -d 10.8.3.1 --dport 53 -j DNAT --to 192.168.1.1:53 Где 10.8.3.1 - шлюз (обычно и днс сервер) гостевой сети (или впн сервера, к которому подключаются клиенты извне). 192.168.1.1 - шлюз интерефейса br0 на котором висит dnsmasq. Если dnsmasq слушает порт, отличный от стандартного 53, в адресе после DNAT порт тоже надо скорректировать. Далее разрешаем хождение пакетов из гостевой сети в впн сеть, используемую для обхода (в нашем примере это будет nwg0) iptables -w -t nat -A POSTROUTING -s 10.8.3.0/24 -o nwg0 -j MASQUERADE 10.8.3.0/24 - это как можно догадаться гостевая подсеть или подсеть впн сервера, используемого клиентскими устройствами. Ну и не забыть из правил маркировки траффика убрать условие ! -s "${INFACE_GUEST_GW4}" Пробуйте.

Спасибо, вижу вы включили в проект некоторые мои наработки, это льстит) Только вот смущает этот коммент: Думается Вы не совсем правильно поняли смысл условия ! -s "${INFACE_GUEST_GW4}" Оно наоборот, исключает маркировку всех соединений (а второе правило пакетов), где адресом источника выступает гостевая подсеть. С тем, чтобы не вмешиваться в их работу. Если стоит задача организавать выборочный роутинг в гостевой сети или клиентов впн подключения, развернутого на роутере, то для этого в первую очередь необходимо организовать перенаправление (с помощью DNAT) всех днс запрсов от клиентов этих подсетей в dnsmasq, для пополнения списков ipset. Дальше нужно разрешить хождение пакетов между гостевой подсетью (или подсетью vpn сервера на роутере, в которую попадают клиенты при подключении извне) и vpn подключением, которое используется для обхода блокировок. Делается через раздел "межсетевой экран" веб морды. Или можно попробовать с помощью iptables (SNAT или MASQUERADE). И конечно для гостевой сети из правил выше надо убрать условие -s "${INFACE_GUEST_GW4}" иначе маркировка исходящего из гостевой сети траффика производиться не будет. Гарантии, что подобная конструкция окажется совместима с сетевыми ускорителями нет, надо пробовать....

Всем доброго дня! Где можно посмотреть алгоритм работы квас? то есть его исходники. В шапке ответ на этот вопрос не нашел, а всю тему лопатить лень если честно. Спасибо.

Вроде разобрался. Проблема судя по всему была в том, что в силу некоторых настроек на Debian сервере исходящие пакеты от висящих на нем сервисов tor и transmission-daemon шли с некорректной чексуммой. А на кинетике видимо по умолчанию такие пакеты отбрасываются. Кое-что поправил на серваке, пакеты в цепочке output от сервисов tor и transmission-daemon пошли с корректной чексуммой и сразу все заработало. Внимание вопрос к техподдержке: как отключить на кинетике фильтрацию пакетов с неправильной чексуммой? ИМХО это бредовая настройка, поскольку чексумма может сломаться по очень многим причинам и само по себе это не значит, что пакет носит злонамеренный характер.

Запустил tcpdump на сервере Debian, вот вывод: 10.8.3.2 это адрес кинетика, на котором нет проблем с доступом к портам 9091 и 9050 10.8.3.3 - проблемный в этом плане кинетик. Видно, что есть инициация коннекта с 10.8.3.3, затем идут ответные пакеты с адреса 192.168.1.44:9091 на адрес 10.8.3.3, но последний более не отвечает Вывод tcpdump на беспроблемном кинетике: Видно, что пакеты ходят, а вот так картина выглядит на проблемном: Исходящие запросы идут, а в ответ полная тишина. Отсюда делаю вывод, что стоит какой то фильтр на кинетике. Как его отключить? техподдержка, ау?

Настройки сети на сервере проверены много раз. Очень вряд ли, что проблема на стороне сервера хотя бы потому, что оба кинетика подключаются к одному и тому же впн, то есть находятся в одной подсети 10.8.3.0/24. Все правила и разрешения iptables в том числе межсетевого трафика на сервере debian настроены по подсетям. Соответственно, если бы проблема была бы в сервере, то она присутствовала бы на обоих клиентах - кинетиках. Может у техподдержки или у кого то из участников форума есть возможность воспроизвести аналогичную задачу и отписаться по наличию проблемы?

Попробовал с проблемного роутера настроить впн подключение до debian-сервера по протоколу openvpn - порты доступны. Похоже какая то проблема с реализацией в прошивке именно wireguard протокола...

Исходные данные: Сервер Wireguard vpn поднят на "взрослой" платформе x86 под управлением Debian. К нему в качестве клиентов с разных мест подключаются клиентами два роутера Keenetic Hopper. Оба на крайней стабильной прошивке. На обоих установлена entware на внутреннюю память. Настроена маршрутизация, доступ для обоих клиентов в локальную сеть за сервером Wireguard (вида 192.168.1.0/24) есть. На ип адресе 192.168.1.44 (который присвоен в локальной сети той же машине, на которой поднят сервер Wireguard) крутятся также socks tor (порт 9050) и торрент клиент transmission-daemon (порт 9091). Кроме того на 22 порту есть доступ к серверу по ssh. Теперь о проблеме: с самого начала почему-то для обоих клиентов (кинетиков) при обращении к адресу 192.168.1.44 были не доступны вышеозначенные порты 9050 и 9091, но при этом например доступ по ssh (порт 22) работал прекрасно. Также прекрасно доступны ресурсы samba, поднятые на том же адресе 192.168.1.44. Теперь самое странное - через какое то время на одном из роутеров кинетик доступ к этим портам и ресурсам появился. Какие либо целенаправленные настройки того роутера я не производил, точно их воспроизвести к сожалению не могу. На втором роутере доступ именно к портам 9050 и 9091, открытых на адресе 192.168.1.44, по прежнему отсутствует. Выглядит это так: На проблемном кинетике: # nmap 192.168.1.44 -p 9050 Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-10 10:03 +05 Nmap scan report for 192.168.1.44 Host is up (0.068s latency). PORT STATE SERVICE 9050/tcp filtered tor-socks Nmap done: 1 IP address (1 host up) scanned in 1.81 seconds ~ # nmap 192.168.1.44 -p 9091 Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-10 10:03 +05 Nmap scan report for 192.168.1.44 Host is up (0.089s latency). PORT STATE SERVICE 9091/tcp filtered xmltec-xmlmail Nmap done: 1 IP address (1 host up) scanned in 1.98 seconds ~ # nmap 192.168.1.44 -p 22 Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-10 10:04 +05 Nmap scan report for 192.168.1.44 Host is up (0.10s latency). PORT STATE SERVICE 22/tcp open ssh На другом кинетике, где проблема исчезла по неясной причине: ~ # nmap 192.168.1.44 -p 9050 Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-10 10:05 +05 Nmap scan report for 192.168.1.44 Host is up (0.028s latency). PORT STATE SERVICE 9050/tcp open tor-socks Nmap done: 1 IP address (1 host up) scanned in 1.13 seconds ~ # nmap 192.168.1.44 -p 9091 Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-10 10:06 +05 Nmap scan report for 192.168.1.44 Host is up (0.028s latency). PORT STATE SERVICE 9091/tcp open xmltec-xmlmail Nmap done: 1 IP address (1 host up) scanned in 1.07 seconds ~ # nmap 192.168.1.44 -p 22 Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-10 10:06 +05 Nmap scan report for 192.168.1.44 Host is up (0.028s latency). PORT STATE SERVICE 22/tcp open ssh Nmap done: 1 IP address (1 host up) scanned in 1.10 seconds Обратите внимание, что статус портов 9050 и 9091 на проблемном киентике не closed, а именно filtered ! Но кто или что их фильтрует никак не могу понять! Прошу помощи коллектива, заранее благодарен!

Судя по всему неправильно понимаете. SS технически это socks прокси, а не сетевой интерфейс. Со всеми вытекающими отсюда плюсами и минусами.

Посмотрел список изменений в версии 3.8 (бета) и там до сих пор версию OpenVPN не обновили. Грустно.

А в ответ тишина