Jump to content

R0cky

Forum Members
 View Profile  See their activity

  • Posts

    49

  • Joined

  • Last visited

  • Days Won

    1

 Content Type 

Posts posted by R0cky

    Медленная работа SMB при использовании Wireguard

    in Обсуждение IPsec, OpenVPN и других туннелей

    Posted

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

    Wireguard и политики доступа

    in Обсуждение IPsec, OpenVPN и других туннелей

    Posted

    В 09.12.2022 в 03:50, Тимми сказал:

    А что, эксклюзивной маршрутизацией это не решается для вас?

    Маршрутизация не избирательно направляет весь исходящий трафик до определенного узла через заданный интерфейс

    Для задачи пустить подключение wireguard через определенный интеренет-интерфейс это не всегда подходит потому что:

    1. Ип адрес устройства, на котором поднят wireguard сервер может быть динамическим и тогда придется маршрутизировать целые подсети. Если маршрутизировать подсеть, то в ней могут быть ресурсы, на которые необходимо ходить через wireguard. Возникает противоречие, которое маршрутизацией никак не решить.

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

    Wireguard и политики доступа

    in Обсуждение IPsec, OpenVPN и других туннелей

    Posted

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

    Помощь в настройке wireguard

    in Обсуждение IPsec, OpenVPN и других туннелей

    Posted

    А вот эти настройки на роутере с белым ип делали? 

    WireGuard-интерфейсу должен быть установлен уровень безопасности private. Для этого потребуется в интерфейсе командной строки (CLI) роутера ввести следующую команду (в нашем примере для интерфейса Wireguard0):

interface Wireguard0 security-level private


Также для интерфейса должна быть включена установка автоматической трансляции адресов (NAT). Для этого потребуется ввести команду:

ip nat Wireguard0


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

system configuration save

     

    Выбор интернет-подключения для Wireguard VPN

    in Обсуждение IPsec, OpenVPN и других туннелей

    Posted · Edited by R0cky

    vasek00

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

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

    Кстати вот неплохой сервис, который позволяет узнать диапазоны выходных ип прова по заданному ип адресу:

    https://xseo.in/asn

    Выбор интернет-подключения для Wireguard VPN

    in Обсуждение IPsec, OpenVPN и других туннелей

    Posted

    vasek00

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

    Выбор интернет-подключения для Wireguard VPN

    in Обсуждение IPsec, OpenVPN и других туннелей

    Posted

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

    Пробуем КВАС

    in Каталог готовых решений Opkg

    Posted

    5 часов назад, Butyc сказал:

    добрый день, прошу прощения, не увидел обновления шапки! Изучу, на скорую руку провел тест со сменой днс, не помогло - не идет обход, скрин настроек прилагаю

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

    Пробуем КВАС

    in Каталог готовых решений Opkg

    Posted · Edited by R0cky

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

    • Thanks 1
    • Upvote 1

    Пробуем КВАС

    in Каталог готовых решений Opkg

    Posted · Edited by R0cky

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

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

    Перенаправление днс запрсов с подсетей впн сервера или гостевой сети:

    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}"

    Пробуйте.

     

     

    • Thanks 2

    Пробуем КВАС

    in Каталог готовых решений Opkg

    Posted · Edited by R0cky

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

    Доброго утра,
    Посмотреть исходники можно здесь. 

    Спасибо, вижу вы включили в проект некоторые мои наработки, это льстит) Только вот смущает этот коммент:

     
    Цитата

     

    # Маркируем трафик для гостевой (в том числе) сети и прохождение пакетов через VPN подключение
    ip4tables PREROUTING -t mangle ! -s "${INFACE_GUEST_GW4}" -m conntrack --ctstate NEW -m set --match-set ${table_name} dst -j CONNMARK --set-mark 0xd1000

    ip4tables PREROUTING -t mangle ! -s "${INFACE_GUEST_GW4}" -m set --match-set ${table_name} dst -j CONNMARK --restore-mark

     

    Думается Вы не совсем правильно поняли смысл условия  ! -s "${INFACE_GUEST_GW4}"

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

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

     

    • Thanks 1

    Wireguard vpn и проблема подключения к отдельным портам в локальной сети за сервером vpn

    in Обсуждение IPsec, OpenVPN и других туннелей

    Posted

    Вроде разобрался. Проблема судя по всему была в том, что в силу некоторых настроек на Debian сервере исходящие пакеты от висящих на нем сервисов tor и transmission-daemon шли с некорректной чексуммой. А на кинетике видимо по умолчанию такие пакеты отбрасываются. Кое-что поправил на серваке, пакеты в цепочке output от сервисов tor и transmission-daemon пошли с корректной чексуммой и сразу все заработало.

    Внимание вопрос к техподдержке: как отключить на кинетике фильтрацию пакетов с неправильной чексуммой? ИМХО это бредовая настройка, поскольку чексумма может сломаться по очень многим причинам и само по себе это не значит, что пакет носит злонамеренный характер.

    Wireguard vpn и проблема подключения к отдельным портам в локальной сети за сервером vpn

    in Обсуждение IPsec, OpenVPN и других туннелей

    Posted · Edited by R0cky

    Запустил tcpdump на сервере Debian, вот вывод:

    Скрытый текст

    tcpdump -nn -i wg0 host 192.168.1.44 and port 9091
    tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
    listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
    20:27:56.007133 IP 10.8.3.3.49194 > 192.168.1.44.9091: Flags [S], seq 3700018748, win 1024, options [mss 1460], length 0
    20:27:56.007153 IP 192.168.1.44.9091 > 10.8.3.3.49194: Flags [S.], seq 516608816, ack 3700018749, win 64240, options [mss 1460], length 0
    20:27:56.783259 IP 10.8.3.3.49195 > 192.168.1.44.9091: Flags [S], seq 3699953213, win 1024, options [mss 1460], length 0
    20:27:56.783278 IP 192.168.1.44.9091 > 10.8.3.3.49195: Flags [S.], seq 2932892427, ack 3699953214, win 64240, options [mss 1460], length 0
    20:27:57.021341 IP 192.168.1.44.9091 > 10.8.3.3.49194: Flags [S.], seq 516608816, ack 3700018749, win 64240, options [mss 1460], length 0
    20:27:57.789339 IP 192.168.1.44.9091 > 10.8.3.3.49195: Flags [S.], seq 2932892427, ack 3699953214, win 64240, options [mss 1460], length 0
    20:27:59.039340 IP 192.168.1.44.9091 > 10.8.3.3.49194: Flags [S.], seq 516608816, ack 3700018749, win 64240, options [mss 1460], length 0
    20:27:59.807308 IP 192.168.1.44.9091 > 10.8.3.3.49195: Flags [S.], seq 2932892427, ack 3699953214, win 64240, options [mss 1460], length 0
    20:28:03.133309 IP 192.168.1.44.9091 > 10.8.3.3.49194: Flags [S.], seq 516608816, ack 3700018749, win 64240, options [mss 1460], length 0
    20:28:03.903303 IP 192.168.1.44.9091 > 10.8.3.3.49195: Flags [S.], seq 2932892427, ack 3699953214, win 64240, options [mss 1460], length 0
    20:28:11.197341 IP 192.168.1.44.9091 > 10.8.3.3.49194: Flags [S.], seq 516608816, ack 3700018749, win 64240, options [mss 1460], length 0
    20:28:11.796617 IP 10.8.3.2.52953 > 192.168.1.44.9091: Flags [S], seq 1042555351, win 1024, options [mss 1460], length 0
    20:28:11.796636 IP 192.168.1.44.9091 > 10.8.3.2.52953: Flags [S.], seq 2625312514, ack 1042555352, win 64240, options [mss 1460], length 0
    20:28:11.831303 IP 10.8.3.2.52953 > 192.168.1.44.9091: Flags [R], seq 1042555352, win 0, length 0

    10.8.3.2 это адрес кинетика, на котором нет проблем с доступом к портам 9091 и 9050

    10.8.3.3 - проблемный в этом плане кинетик.

    Видно, что есть инициация коннекта с 10.8.3.3, затем идут ответные пакеты с адреса 192.168.1.44:9091 на адрес 10.8.3.3, но последний более не отвечает

     

    Вывод tcpdump на беспроблемном кинетике:

    Скрытый текст

    tcpdump -nn -i nwg1 host 192.168.1.44 and port 9091
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on nwg1, link-type RAW (Raw IP), capture size 262144 bytes
    22:33:12.124993 IP 10.8.3.2.61155 > 192.168.1.44.9091: Flags [S], seq 3722118243, win 1024, options [mss 1460], length 0
    22:33:12.152607 IP 192.168.1.44.9091 > 10.8.3.2.61155: Flags [S.], seq 1372688115, ack 3722118244, win 64240, options [mss 1460], length 0
    22:33:12.152844 IP 10.8.3.2.61155 > 192.168.1.44.9091: Flags [R], seq 3722118244, win 0, length 0

    Видно, что пакеты ходят, а вот так картина выглядит на проблемном:

    Скрытый текст

     tcpdump -nn -i nwg0 host 192.168.1.44 and port 9091
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on nwg0, link-type RAW (Raw IP), capture size 262144 bytes
    22:39:24.810961 IP 10.8.3.3.54628 > 192.168.1.44.9091: Flags [S], seq 1695354802, win 1024, options [mss 1460], length 0
    22:39:25.338232 IP 10.8.3.3.54629 > 192.168.1.44.9091: Flags [S], seq 1695289267, win 1024, options [mss 1460], length 0

    Исходящие запросы идут, а в ответ полная тишина. Отсюда делаю вывод, что стоит какой то фильтр на кинетике. Как его отключить? техподдержка, ау?

     

    Wireguard vpn и проблема подключения к отдельным портам в локальной сети за сервером vpn

    in Обсуждение IPsec, OpenVPN и других туннелей

    Posted · Edited by R0cky

    5 часов назад, Monstr86 сказал:

    Я бы проверил iptables на debian сервере, может там что то не так.

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

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

    Wireguard vpn и проблема подключения к отдельным портам в локальной сети за сервером vpn

    in Обсуждение IPsec, OpenVPN и других туннелей

    Posted

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

    Wireguard vpn и проблема подключения к отдельным портам в локальной сети за сервером vpn

    in Обсуждение IPsec, OpenVPN и других туннелей

    Posted · Edited by R0cky

    Исходные данные:

    Сервер 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 ! Но кто или что их фильтрует никак не могу понять!

    Прошу помощи коллектива, заранее благодарен!

     

     

    Пробуем КВАС

    in Каталог готовых решений Opkg

    Posted

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

    Я вот только понять не могу, как так получается трафик до того же 2ip при настроенном КВАСе идёт через SS (сервис рапортует IP SS) но при этом трассировка идёт через мой шлюз провайдера. Или я неправильно понимаю принцип работы SS? 

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

×
×
  • Create New...