Forum Replies Created
-
Posts
-
Вcе тесты выше в NAT mode (без
-lac). Возможно проблемы которые у Вас возникают связаны с разным MTU, неплохо было записать трафик запустив клиента с-log-level allи посмотреть что где ломается.Наконец дошли руки прогнать несколько тестов. Конфигурация:
Peer 1 (WireGuard Server):
—————————————
Windows 10 x64
WireGuard For Windows v0.5.3
WireSock VPN Gateway v1.1.4
—————————————
Peer 2 (WireGuard Client):
Windows 11 x64
WireSock VPN Client v1.2.28
—————————————
Peer 3 (WireGuard Client):
Windows 11 ARM64
WireSock VPN Client v1.2.28
—————————————
Peer 2 WireGuard configuration (NAT mode):
[Interface] PrivateKey = --REMOVED-KEY-- Address = 10.10.11.3/24 DNS = 8.8.8.8, 1.1.1.1 MTU = 1412 [Peer] PublicKey = --REMOVED-KEY-- AllowedIPs = 0.0.0.0/0 Endpoint = ENDPOINT:PORT PersistentKeepalive = 25 AllowedApps = chrome, mstsc, iperf3, simple-web-server DisallowedIPs = 192.168.3.0/24, 10.10.1.0/24—————————————
Peer 3 WireGuard configuration (NAT mode):
[Interface] PrivateKey = --REMOVED-KEY-- Address = 10.10.11.6/24 DNS = 8.8.8.8, 1.1.1.1 MTU = 1412 [Peer] PublicKey = --REMOVED-KEY-- AllowedIPs = 0.0.0.0/0 Endpoint = ENDPOINT:PORT PersistentKeepalive = 25 ; WireSock extensions DisallowedIPs = 192.168.3.0/24, 10.10.1.0/24—————————————
На Peer 2 запущены:
iperf3.exe -s simple-file-server.exeНа Peer 1 и Peer 2 запускаем iperf3 и тестовые скрипты simple-file-server/test:
python fs-test-single.py download test-file-1.txt 2000000 http://10.10.11.3:3000 File does not exist on the server. Uploading the file... File: test-file-1.txt already exists with the correct size of 2000000 bytes. File generated: test-file-1.txt, Size: 2000000 bytes, Time taken: 0.00s File uploaded: test-file-1.txt, Status: 200, Time taken: 12.59s File downloaded: test-file-1.txt, Status: 200, Time taken: 11.58s File deleted: test-file-1.txt, Status: 200, Time taken: 0.22siperf3 -c 10.10.11.3 Connecting to host 10.10.11.3, port 5201 [ 4] local 10.10.11.1 port 60574 connected to 10.10.11.3 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.01 sec 1.25 MBytes 10.4 Mbits/sec [ 4] 1.01-2.00 sec 128 KBytes 1.05 Mbits/sec [ 4] 2.00-3.01 sec 256 KBytes 2.07 Mbits/sec [ 4] 3.01-4.01 sec 384 KBytes 3.14 Mbits/sec [ 4] 4.01-5.00 sec 384 KBytes 3.19 Mbits/sec [ 4] 5.00-6.00 sec 384 KBytes 3.14 Mbits/sec [ 4] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec [ 4] 7.00-8.01 sec 128 KBytes 1.03 Mbits/sec [ 4] 8.01-9.00 sec 256 KBytes 2.12 Mbits/sec [ 4] 9.00-10.00 sec 384 KBytes 3.15 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 3.62 MBytes 3.04 Mbits/sec sender [ 4] 0.00-10.00 sec 3.45 MBytes 2.90 Mbits/sec receiverЕще обнаружил следующую проблему. Клиентом является Win2008R2+IIS ftp server + IIS web server. Если сервис стартует без -lac (wiresock-client.exe install -start-type 2 -config wg1.conf -log-level none), то при обращении со стороны wg интерфейса к ftp серверу в passive mode соединение крэшится, аналогично при обращении к web серверу. Если сервис стартует с -lac (wiresock-client.exe install -start-type 2 -config wg1.conf -log-level none -lac), то проблемы не наблюдается.
Если не затруднит, то не помешали бы подробности. Если я правильно понимаю, то вы пытаетесь получить доступ к указанным сервисам через туннель? Что значит соединение крешится? Не устанавливается или работает и рвется через какое-то время?
Режимы с виртуальным адаптером и без довольно сильно отличаются, во втором случае никакого дополнительного сетевого интерфейса в системе нет, весь трафик идет с дефолтового интерфейса и нужный упаковывается в туннель после NAT (адрес источника подменяется на адрес из конфига). В обратную сторону трафик распаковывается из туннеля и снова проходит через NAT (теперь адрес назначения меняется на реальный локальный сетевой адрес).
Хотелось-бы чтобы инициировал с заданным в конфиге портом, официальный клиент так делает, в некоторых случаях это удобно.
Это в принципе не сложно, если адрес свободен. Можно будет добавить в следующей версии.
День добрый!
Не могу понять, вопрос о клиенте Wiresock? Клиент не слушает какой-либо специфический порт и функционирует только как клиент (инициатор туннеля), параметр keepalive передается в BoringTun, который периодически отправляет пакеты keepalive. В принципе, хотя из интерфейса библиотеки это и неочевидно, BoringTun позволяет реализовать и серверную часть (принимать соединения). Возможно, займусь как-нибудь если будет свободное время, тема в основном смежная с поддержкой множественных туннелей.
The feasibility of this depends on the application in question. If you’re able to rename the second instance or relocate it to a different path (such as a portable edition), you can still use the “AllowedApps” option by specifying the full pathname. For example, you could set “AllowedApps = C:\Program Files\Mozilla Firefox\firefox.exe”.
However, if the only difference between your application instances is the process ID, unfortunately, this feature is not supported. While it’s technically feasible to implement, I’m currently unsure of how to do so in a user-friendly manner.
The current Wiresock VPN Client does not support local Wireguard endpoints in the configuration file, rendering the method of redirecting WireGuard through the local proxy, as described in the provided link, unfeasible. I’m contemplating the inclusion of local endpoints as a feature, however, this isn’t necessary for your specific situation.
You can simply specify the applications you want to forward over the Wireguard tunnel under the “AllowedApps” configuration option. For instance, setting “AllowedApps = firefox” will result in only the Firefox browser’s traffic being forwarded over the WireGuard tunnel.
If you prefer to have your browser explicitly configured to use the specified local proxy, you can install a lightweight SOCKS5 proxy and include its name in the “AllowedApps”. Consequently, all outgoing traffic from this proxy will be directed through Wiresock over the WireGuard tunnel. This setup will also apply to all traffic from the proxy’s clients.
В логах anti-spam’а я не нашел ничего релевантного, затрудняюсь сказать, что ему не понравилось. Но без него тоже никак, вручную текущие объёмы спама модерировать невозможно. Можете отправить мне напрямую на [email protected].
Установить драйвер получилось или опять ACCESS_DENIED? Такое ощущение, что что-то в системе блокирует установку определенного типа драйверов…
Может в “роллбеке” msi, при неудачной инсталляции указывать именно удаление через sc? Потому что через “‘C:\WINDOWS\system32\netcfg.exe” -v -u nt_ndisrd’ не отработало и в системе остался не запускающийся драйвер:
Да, пожалуй имеет смысл. Но сперва надо разобраться с ACCESS_DENIED.
Если не затруднит, скачайте ndiswgc и попробуйте установить его вручную, либо используя netcfg:
netcfg.exe -v -l ndiswgc_lwf.inf -c s -i nt_ndiswgcЛибо через свойства сетевого соединения, Install->Service->Have a Disk.
Если при установке в ручную ошибки не будет, то дело в MSI скрипте, будем разбираться что с ним не так.
DNS reserves a significant range of ports, the specifics of which you can explore here: DNS Port Allocation. It would be advisable to select a different range when assigning a port for WireGuard.
The purpose of this DPI protection is to mask the WireGuard handshake from the DPI system that sits between the WireGuard peers.
The log says: Could not bind socket to [::]:59539 (0xc0000043)
From the error messages provided, it seems like there is a conflict on port 59539, which WireSock is trying to bind to. The error message “The process cannot access the file because it is being used by another process” often means that the port is being used by another application or service on the system.
I would recommend trying to identify the application using the port. Use the
netstatcommand to identify which application is currently using the port 59539. Open the Command Prompt and typenetstat -aon | findstr 59539. The last column of the output will give you the process ID (PID) of the application using the port. You can then use the Task Manager to find the application associated with this PID.I’m not entirely sure if I have accurately comprehended your question. The premise seems to be that when tunneling the Wireguard handshake via SOCKS5, Deep Packet Inspection (DPI) will observe the handshake and handshake response packets with an additional SOCKS5 header appended. This extra layer increases the complexity of accurately identifying the nature of these packets.
