Forum Replies Created
-
Posts
-
Thanks, I checked the log and it looks strange. The tunnel appears to be broken at the very beginning, immediately after receiving the response to the handshake. I also noticed that you are running a SOCKS proxy on the same host as the WireGuard Server. I’ve never tested this setup and can’t exclude some sort of network collision going on. Have you tried disabling the SOCKS5 proxy feature? Also could you update to the latest WireSock client 1.2.15? It will be easier if we use the same build.
Are you by any chance running two wireguard clients with the same configuration (keys, etc.)? In such a case, two (or even more) clients will compete for the same slot, causing tunnel errors from time to time.
If not then some logs could help to understand the problem.
В режиме прокси тоже не работает?
Можно запустить как приложение и посмотреть/записать логи. Должно стать понятнее.
Yes, you are right about ExitLag, it does indeed use WinpkFilter to intercept and process network traffic. However, I’m afraid the only way I can suggest for researching how it affects traffic flow is to create two winpkfilter-derived drivers and set one above and one below ExitLag in the stack. Thus, you can capture and record the traffic from these two drivers, save to a PCAP file, and analyze the difference in Wireshark.
Hmm, looks like the problem is in v2rayN. Perhaps his SOCKS5 implementation has issues with UDP support.
It would be helpful to look at the log/PCAP files, however, I would check to see if the handshake packet is being blocked by Windows Firewall on another machine.
Off topic:
Your website blocked in my country, so I need VPN to access it.
Your web server also disallows to accept a post or comment from any kind of non-personal IP address.
I had a really hard time to overcome this issue!SPAM is a real problem, but I’ve just adjusted the spam protection settings a little, I hope this improves your situation.
The problem is using a locally running SOCKS5 proxy (127.0.0.1:1080). WireSock does not currently support this option, it is assumed that the SOCKS5 proxy is running on another machine.
I wouldn’t say it’s anything complicated, just another filter similar to the existing DNS redirect implementation. But at the same time, it requires adding new configuration options and some tests. All in all, it will probably take me a day. So I guess if I won’t have anything urgent, I can dedicate a day to it next weekend.
I think the SMB redirector runs in the context of a system process, so adding something like this to AllowedApps will tunnel more than you really need. However, I think I can add a new setting called AllowedPorts to have AllowedPorts = tcp:139, tcp:445 force SMB traffic into the tunnel.
There is no such example, and although it is not difficult to create one, note that some information is required to build the TCP SYN packet, e.g. source and destination MAC, IP addresses and TCP ports. Requesting all of these options from the command line can be annoying. Any ideas what it might look like?
By the way, please clarify, is your question about constructing a TCP SYN packet or sending it to the network?
В каком контексте могут понадобиться десятки туннелей? Хотя давеча меня спросили можно ли пропустить 50 браузеров через 50 разных SOCKS на 50 амазоновских аккаунтов. Так что, похоже, такое действительно бывает нужно, но случай весьма специфический.
И тут возникает сразу несколько вопросов.
Во-первых, подобное хозяйство нужно как-то конфигурировать, так что вероятно стоит начать с какого-то UI. У меня не так много свободного времени этим заниматься, но есть надежда, что Tunnl.To (это UI для WireSock) допилят до стабильной версии и можно будет развиваться в этом направлении.
Во-вторых, если делать десятки туннелей в режиме NAT еще более-менее беспроблемно, то десятки виртуальных интерфейсов могут создать серьезную путаницу, особенно если каждый сконфигурирован как дефолтовый гейтвей (0.0.0.0/0).
Но в целом, если ограничиться режимом NAT, то поддержку множества WireGuard туннелей сделать не слишком сложно. Пакеты будут перехватываться, шифроваться в соответствии с выбранным на основе списка приложений туннелем и отправляться дальше.
Works perfectly!
Thanks for checking!
Unrelated suggestion: display version info in the initial notice message
As you wish, v1.2.15!
Так как DNS указан в config, то весь DNS трафик (через dnscache) идет через тоннель на 1.1.1.1. И DNS трафик браузеров не включенных в AllowedApps тоже (исключение, случаи использования DNS over HTTPS в том же Firefox).
На всякий случай я попробовал такую же конфигурацию с 1.1.1.1 у себя и она работает как ожидалось. Так что описанное поведение для меня выглядит странно, надо бы записать логи и PCAP файлы, посмотреть, что там на уровне сети происходит. Не исключено, что установлен какой-то антивирусный пакет, который встраивается в браузер, и за DNS происходит некий конфликт. Если что-то такое установлено, попробуйте удалить/выключить. Еще попробуйте поменять адрес DNS, на что-то альтернативное (8.8.8.8), посмотреть будет ли разница.
