[feature request] To support "Wireguard over raw TCP"

[KeXianbin(http://diyism.com)]

Thanks for the info.

On Sep 25, 2018 23:53, "StarBrilliant" <coder at poorlab.com> wrote:

> On Tue, Sep 25, 2018 at 1:17 PM KeXianbin(http://diyism.com)
> <kexianbin at diyism.com> wrote:
> >
> > Currently, I'm using udp2raw-tunnel to transform wireguard udp traffic
> into raw tcp (config files as follows),
> > It's very stable on my home network than using wireguard alone,
> > But if we can integrate RAW TCP feature into wireguard, it would
> significantly improve performance and stability for end users.
> >
> >
> > from: https://gist.github.com/diyism/1b80903a83776675031c73ae499438
> d8#file-wireguard_config-txt-L145
> >
> > $wget https://github.com/wangyu-/udp2raw-tunnel/releases/
> download/20180830.2/udp2raw_binaries.tar.gz
> > $tar xzvf udp2raw_binaries.tar.gz
> > $sudo cp udp2raw_amd64 /usr/bin/
> > $sudo udp2raw_amd64 -c -l127.0.0.2:24448 -r<server ip>:24447 -a
> > $cat /etc/wireguard/wg0.conf
> > [Interface]
> > PrivateKey = <client privkey>
> > Address = 10.0.0.3/32
> > ListenPort = 24447
> > MTU = 1300
> > PostUp = ip route add 10.0.0.0/24 dev wg0 && wg set wg0 peer <server
> pubkey> allowed-ips 0.0.0.0/0
> > PostDown = ip route del 10.0.0.0/24
> >
> > [Peer]
> > #10.0.0.1
> > PublicKey = <server pubkey>
> > Endpoint = 127.0.0.2:24448
> > #AllowedIPs = 0.0.0.0/0
> >
> > $sudo wg-quick down wg0 ; sudo wg-quick up wg0
> > $ping 10.0.0.1
> > 64 bytes from 10.0.0.1: icmp_seq=2113 ttl=64 time=183 ms
> > $sudo ip route add 104.24.0.0/16 dev wg0
> > $ping myip.ipip.net
> > PING myip.ipip.net (104.24.20.50) 56(84) bytes of data.
> > 64 bytes from 104.24.20.50 (104.24.20.50): icmp_seq=1 ttl=60 time=185 ms
> > $curl http://myip.ipip.net
> > IP：<server ip>
> >
> > #take care, "MTU = 1300" in wg0.conf is needed when wireguard over
> udp2raw, or else most https requests will be blocked because of mtu problem.
>
>
> Hello Kexianbin,
>
> This is an UNOFFICIAL response to your question. (But I think the
> official developers may have similar answers.)
>
> Wireguard probably will not accept an official integration to udp2raw.
> The reasons are:
>
> 1) Wireguard wants to keep their kernel part code minimized, therefore
> easy for security auditing, and less bugs.The UDP protocol is actually
> very simple and straightforward. (By the way, if you intended to use
> Wireguard in China, be informed that this is a protocol that is very
> easy to block by the ISP.)
>
> 2) I have read the source code of udp2raw. To be frank, the code is of
> very low quality. For this reason, I don't think udp2raw would be
> integrated into Wireguard unless it's rewritten.
>
> 3) Udp2raw is not suitable for everyone or for every country. For
> example udp2raw may have problems passing middleboxes, which is common
> among satellite ISPs in Oceania. Middleboxes break and resemble TCP
> segments thus make udp2raw literally unusable. Also it is not
> congestion friendly (by design), so a massive deployment may affect
> the global Internet ecology.
>
> However the good news is, Wireguard provides an open control interface
> (see https://www.wireguard.com/xplatform/ ). By utilizing this
> interface, we can develop an alternate frontend application other than
> the official command "wg", that automatically sets up the kernel
> Wireguard kernel part and a userland udp2raw part, packaged as one
> application.
>
>
> My words for Wireguard developers:
>
> 1) In case you may not know the udp2raw protocol, here is a
> description. Some ISPs in certain countries have strange QoS strategy
> that deprioritize UDP packets during network congestion, resulting a
> 50% loss rate or more for UDP. The udp2raw protocol simulates a
> three-way TCP handshake and add TCP header to UDP packets so they will
> not be dropped. This protocol does not do congestion control or rate
> control, neither does it understand any TCP semantics. It's a dirty
> hack for dirty ISP, not suitable for everyone, but overwhelmingly
> useful in certain countries.
>
> 2) Wireguard currently does not support binding to localhost. This is
> required for any third-party plugins upon Wireguard to work. We might
> need to consider binding to localhost an important feature to go in
> the near future.
>
>
> Best regards,
> StarBrilliant
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20180926/ee2ee032/attachment.html>