Forum Replies Created
-
Posts
-
В логах anti-spam’а я не нашел ничего релевантного, затрудняюсь сказать, что ему не понравилось. Но без него тоже никак, вручную текущие объёмы спама модерировать невозможно. Можете отправить мне напрямую на support@ntkernel.com.
Установить драйвер получилось или опять 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.
Hmm, it might be beneficial for you to consider utilizing the command line version of the WireSock VPN Client. This allows you the flexibility to start or stop the client either as a standalone application or as a service, directly from a PowerShell script.
Yes, you’re absolutely correct. The SOCKS5 proxy should indeed be remote, preferably residing on the same machine as the VPN server. This configuration ensures it is beyond the DPI (Deep Packet Inspection), thus facilitating pass-through.
Apologies for the oversight in our documentation update. The new log location is
C:\ProgramData\NT KERNEL\WireSock VPN Client. PCAP files are saved either to the working directory or within Windows\System32 when operating as a service.Thank you for your diligent efforts in troubleshooting the issue. I greatly appreciate your time and your willingness to try out different steps to diagnose the problem.
In order to assist us with a deeper analysis, I recommend starting the console version of the Wiresock client. Please use the “-log-level all” argument to collect detailed logs and capture network traffic during the times when the connection drops, which could shed light on what may be causing these disruptions.
Thank you once again for your cooperation.
Wiresock VPN Client implements this feature via additional parameters:
- Socks5Proxy – specifies SOCKS5 proxy endpoint, e.g. Socks5Proxy = socks5.sshvpn.me:1080 or Socks5Proxy = 13.134.12.31:1080
- Socks5ProxyUsername – specifies SOCKS5 username (optional)
- Socks5ProxyPassword – specifies SOCKS5 password (optional)
Wiresock operates by establishing a connection to the indicated SOCKS5 proxy. This involves associating a UDP endpoint and transmitting handshake packets through the SOCKS5 UDP tunnel. The handshake response emerges from the same tunnel. However, all subsequent data traffic is routed directly to the intended WireGuard endpoint.
Although the methodology is quite straightforward, it adds a layer of complexity to the WireGuard handshake and response process, making it more challenging to detect and subsequently block the tunnel.
Currently, that option is not available. However, I’m interested in understanding your perspective. Could you please share why you believe this feature would be beneficial?
Well, I’m afraid, it could prove to be somewhat complex and time-consuming. This would require you to install Visual Studio, clone the WiresockUI repository, and build the debug version of it. Next, you would need to run WiresockUI under Visual Studio debugger and use it until you encounter a hang. Subsequently, you would be required to examine the state of the application to identify the problem. The sequence of these actions could be intricate and demanding, so please consider your willingness to commit to this task carefully.
