* Vision server allow multiple blocks of padding
* Fix Vision client to support multiple possible padding blocks
* Vision padding upgrade
- Now we have two types of padding: long (pad to 900-1400) and traditional (0-256)
- Long padding is applied to tls handshakes and first (empty) packet
- Traditional padding is applied to all beginning (7) packets of the connection (counted two-way)
- Since receiver changed its way to unpad buffer in fd6973b3c6, we can freely extend padding packet length easily in the future
- Simplify code
* Adjust receiver withinPaddingBuffers
Now default withinPaddingBuffers = true to give it a chance to do unpadding
* Fix magic numbers for Vision
Thanks @H1JK
Thanks @RPRX for guidance
This only affects the Vision client for protocols expecting server to send data first.
The change is compatible with existing version of Vision server.
In the past, when user open xtls vision on the server side, plain vless+tls can connect.
Pure tls is known to have certain tls in tls characters.
Now server need to specify "xtls-rprx-vision,none" for it be able usable on the same port.
Before this change, Vision client need a pure inbound like socks or http.
After this change, it will support any inbound.
This is useful in traffic forwarder use case inside China.
* Add XTLS RPRX's Vision
* Add helpful warning when security is wrong
* Add XTLS padding (draft)
* Fix number of packet to filter
* Xtls padding version 1.0 and unpadding logic
* DialSystem for Quic
DialSystem() is needed in case of Android client,
where the raw conn is protected for vpn service
* Fix client dialer log
Log such as:
tunneling request to tcp:www.google.com:80 via tcp:x.x.x.x:443
the second "tcp" is misleading when using mKcp or quic transport
Remove the second "tcp" and add the correct logging for transport dialer:
- transport/internet/tcp: dialing TCP to tcp:x.x.x.x:443
- transport/internet/quic: dialing quic to udp:x.x.x.x:443
* Quic new stream allocation mode
Currently this is how Quic works: client muxing all tcp and udp traffic through a single session, when there are more than 32 running streams in the session,
the next stream request will fail and open with a new session (port). Imagine lineup the session from left to right:
|
| |
| | |
As the streams finishes, we still open stream from the left, original session. So the base session will always be there and new sessions on the right come and go.
However, either due to QOS or bugs in Quic implementation, the traffic "wear out" the base session. It will become slower and in the end not receiving any data from server side.
I couldn't figure out a solution for this problem at the moment, as a workaround:
| |
| | |
| | |
I came up with this new stream allocation mode, that it will never open new streams in the old sessions, but only from current or new session from right.
The keeplive config is turned off from server and client side. This way old sessions will natually close and new sessions keep generating.
Note the frequency of new session is still controlled by the server side. Server can assign a large max stream limit. In this case the new allocation mode will be similar to the current mode.
* Increase some tls test timeout
* Fix TestUserValidator
* Change all tests to VMessAEAD
Old VMess MD5 tests will be rejected and fail in 2022
* Chore: auto format code
* Added test for no terminate signal
* unified drain support for vmess and shadowsockets
* drain: add generated file
Co-authored-by: Shelikhoo <xiaokangwang@outlook.com>
* use shadowsocket's bloomring for shadowsocket's replay protection
* added shadowsockets iv check for tcp socket
* Rename to shadowsockets iv check
* shadowsocks iv check config file
* iv check should proceed after decryption
* use shadowsocket's bloomring for shadowsocket's replay protection
* Chore: format code (#842)
Co-authored-by: Shelikhoo <xiaokangwang@outlook.com>
Co-authored-by: Loyalsoldier <10487845+Loyalsoldier@users.noreply.github.com>
* DNS: add clientip for specific nameserver
* Refactoring: DNS App
* DNS: add DNS over QUIC support
* Feat: add disableCache option for DNS
* Feat: add queryStrategy option for DNS
* Feat: add disableFallback & skipFallback option for DNS
* Feat: DNS hosts support multiple addresses
* Feat: DNS transport over TCP
* DNS: fix typo & refine code
* DNS: refine code
* Add disableFallbackIfMatch dns option
* Feat: routing and freedom outbound ignore Fake DNS
Turn off fake DNS for request sent from Routing and Freedom outbound.
Fake DNS now only apply to DNS outbound.
This is important for Android, where VPN service take over all system DNS
traffic and pass it to core. "UseIp" option can be used in Freedom outbound
to avoid getting fake IP and fail connection.
* Fix test
* Fix dns return
* Fix local dns return empty
* Apply timeout to dns outbound
* Update app/dns/config.go
Co-authored-by: Loyalsoldier <10487845+loyalsoldier@users.noreply.github.com>
Co-authored-by: Ye Zhihao <vigilans@foxmail.com>
Co-authored-by: maskedeken <52683904+maskedeken@users.noreply.github.com>
Co-authored-by: V2Fly Team <51714622+vcptr@users.noreply.github.com>
Co-authored-by: CalmLong <37164399+calmlong@users.noreply.github.com>
Co-authored-by: Shelikhoo <xiaokangwang@outlook.com>
Co-authored-by: 秋のかえで <autmaple@protonmail.com>
Co-authored-by: 朱聖黎 <digglife@gmail.com>
Co-authored-by: rurirei <72071920+rurirei@users.noreply.github.com>
Co-authored-by: yuhan6665 <1588741+yuhan6665@users.noreply.github.com>
Co-authored-by: Arthur Morgan <4637240+badO1a5A90@users.noreply.github.com>
* Deprecate legacy VMess header with a planned decommission
* show legacy warning only once
Co-authored-by: Xiaokang Wang <xiaokangwang@outlook.com>
Co-authored-by: hmol233 <82594500+hmol233@users.noreply.github.com>
* Update all proto files with existing vprotogen
* Chore: remove protoc-gen-gofast
* Feat: vprotogen adds version detector to block generation code from old protobuf version
* Feat: vprotogen refine logic
Co-authored-by: Loyalsoldier <10487845+Loyalsoldier@users.noreply.github.com>
