documentation: Bump version & Refactor docs

This commit is contained in:
世界
2023-11-09 17:04:08 +08:00
parent 18dfbd1cef
commit 3c5f658863
105 changed files with 2061 additions and 1767 deletions

287
docs/manual/proxy/client.md Normal file
View File

@@ -0,0 +1,287 @@
---
icon: material/cellphone-link
---
# Client
### :material-ray-start: Introduction
For a long time, the modern usage and principles of proxy clients
for graphical operating systems have not been clearly described.
However, we can categorize them into three types:
system proxy, firewall redirection, and virtual interface.
### :material-web-refresh: System Proxy
Almost all graphical environments support system-level proxies,
which are essentially ordinary HTTP proxies that only support TCP.
| Operating System / Desktop Environment | System Proxy | Application Support |
|:---------------------------------------------|:-------------------------------------|:--------------------|
| Windows | :material-check: | :material-check: |
| macOS | :material-check: | :material-check: |
| GNOME/KDE | :material-check: | :material-check: |
| Android | ROOT or adb (permission) is required | :material-check: |
| Android/iOS (with sing-box graphical client) | via `tun.platform.http_proxy` | :material-check: |
As one of the most well-known proxy methods, it has many shortcomings:
many TCP clients that are not based on HTTP do not check and use the system proxy.
Moreover, UDP and ICMP traffics bypass the proxy.
```mermaid
flowchart LR
dns[DNS query] -- Is HTTP request? --> proxy[HTTP proxy]
dns --> leak[Leak]
tcp[TCP connection] -- Is HTTP request? --> proxy
tcp -- Check and use HTTP CONNECT? --> proxy
tcp --> leak
udp[UDP packet] --> leak
```
### :material-wall-fire: Firewall Redirection
This type of usage typically relies on the firewall or hook interface provided by the operating system,
such as Windows WFP, Linuxs redirect, TProxy and eBPF, and macOSs pf.
Although it is intrusive and cumbersome to configure,
it remains popular within the community of amateur proxy open source projects like V2Ray,
due to the low technical requirements it imposes on the software.
### :material-expansion-card: Virtual Interface
All L2/L3 proxies (seriously defined VPNs, such as OpenVPN, WireGuard) are based on virtual network interfaces,
which is also the only way for all L4 proxies to work as VPNs on mobile platforms like Android, iOS.
The sing-box inherits and develops clash-premiums TUN inbound (L3 to L4 conversion)
as the most reasonable method for performing transparent proxying.
```mermaid
flowchart TB
packet[IP Packet]
packet --> windows[Windows / macOS]
packet --> linux[Linux]
tun[TUN interface]
windows -. route .-> tun
linux -. iproute2 route/rule .-> tun
tun --> gvisor[gVisor TUN stack]
tun --> system[system TUN stack]
assemble([L3 to L4 assemble])
gvisor --> assemble
system --> assemble
assemble --> conn[TCP and UDP connections]
conn --> router[sing-box Router]
router --> direct[Direct outbound]
router --> proxy[Proxy outbounds]
router -- DNS hijack --> dns_out[DNS outbound]
dns_out --> dns_router[DNS router]
dns_router --> router
direct --> adi([auto detect interface])
proxy --> adi
adi --> default[Default network interface in the system]
default --> destination[Destination server]
default --> proxy_server[Proxy server]
proxy_server --> destination
```
## :material-cellphone-link: Examples
### Basic TUN usage for Chinese users
=== ":material-numeric-4-box: IPv4 only"
```json
{
"dns": {
"servers": [
{
"tag": "google",
"address": "tls://8.8.8.8"
},
{
"tag": "local",
"address": "223.5.5.5",
"detour": "direct"
}
],
"rules": [
{
"outbound": "any",
"server": "local"
}
],
"strategy": "ipv4_only"
},
"inbounds": [
{
"type": "tun",
"inet4_address": "172.19.0.1/30",
"auto_route": true,
"strict_route": false
}
],
"outbounds": [
// ...
{
"type": "direct",
"tag": "direct"
},
{
"type": "dns",
"tag": "dns-out"
}
],
"route": {
"rules": [
{
"protocol": "dns",
"outbound": "dns-out"
},
{
"geoip": [
"private"
],
"outbound": "direct"
}
],
"auto_detect_interface": true
}
}
```
=== ":material-numeric-6-box: IPv4 & IPv6"
```json
{
"dns": {
"servers": [
{
"tag": "google",
"address": "tls://8.8.8.8"
},
{
"tag": "local",
"address": "223.5.5.5",
"detour": "direct"
}
],
"rules": [
{
"outbound": "any",
"server": "local"
}
]
},
"inbounds": [
{
"type": "tun",
"inet4_address": "172.19.0.1/30",
"inet6_address": "fdfe:dcba:9876::1/126",
"auto_route": true,
"strict_route": false
}
],
"outbounds": [
// ...
{
"type": "direct",
"tag": "direct"
},
{
"type": "dns",
"tag": "dns-out"
}
],
"route": {
"rules": [
{
"protocol": "dns",
"outbound": "dns-out"
},
{
"geoip": [
"private"
],
"outbound": "direct"
}
],
"auto_detect_interface": true
}
}
```
=== ":material-domain-switch: FakeIP"
```json
{
"dns": {
"servers": [
{
"tag": "google",
"address": "tls://8.8.8.8"
},
{
"tag": "local",
"address": "223.5.5.5",
"detour": "direct"
},
{
"tag": "remote",
"address": "fakeip"
}
],
"rules": [
{
"outbound": "any",
"server": "local"
},
{
"query_type": [
"A",
"AAAA"
],
"server": "remote"
}
],
"fakeip": {
"enabled": true,
"inet4_range": "198.18.0.0/15",
"inet6_range": "fc00::/18"
},
"independent_cache": true
},
"inbounds": [
{
"type": "tun",
"inet4_address": "172.19.0.1/30",
"inet6_address": "fdfe:dcba:9876::1/126",
"auto_route": true,
"strict_route": true
}
],
"outbounds": [
// ...
{
"type": "direct",
"tag": "direct"
},
{
"type": "dns",
"tag": "dns-out"
}
],
"route": {
"rules": [
{
"protocol": "dns",
"outbound": "dns-out"
},
{
"geoip": [
"private"
],
"outbound": "direct"
}
],
"auto_detect_interface": true
}
}
```

View File

@@ -0,0 +1,10 @@
---
icon: material/server
---
# Server
To use sing-box as a proxy protocol server, you pretty much only need to configure the inbound for that protocol.
The Proxy Protocol menu below contains descriptions and configuration examples
of recommended protocols for bypassing GFW.

66
docs/manual/proxy/tun.md Normal file
View File

@@ -0,0 +1,66 @@
# :material-expansion-card: TUN
## :material-text-box: Definition
Refers to TUNnel, a virtual network device supported by the kernel.
Its also used in sing-box to denote the extensive functionality surrounding TUN inbound:
including traffic assembly, automatic routing, and network and default interface monitoring.
The following flow chart describes the minimal TUN-based transparent proxy process in sing-box:
``` mermaid
flowchart LR
subgraph inbound [Inbound]
direction TB
packet[IP Packet]
packet --> windows[Windows / macOS]
packet --> linux[Linux]
tun[TUN interface]
windows -. route .-> tun
linux -. iproute2 route/rule .-> tun
tun --> gvisor[gVisor TUN stack]
tun --> system[system TUN stack]
assemble([L3 to L4 assemble])
gvisor --> assemble
system --> assemble
assemble --> conn[TCP and UDP connections]
conn --> router[sing-box Router]
end
subgraph outbound [Outbound]
direction TB
direct[Direct outbound]
proxy[Proxy outbounds]
direct --> adi([auto detect interface])
proxy --> adi
adi --> default[Default network interface in the system]
default --> destination[Destination server]
default --> proxy_server[Proxy server]
proxy_server --> destination
end
inbound --> outbound
```
## :material-help-box: How to
A basic TUN-based transparent proxy configuration file includes: an TUN inbound, `route.auto_detect_interface`, like:
```json
{
"inbounds": [
{
"type": "tun",
"inet4_address": "172.19.0.1/30",
"inet6_address": "fdfe:dcba:9876::1/126",
"auto_route": true,
"strict_route": true
}
],
"route": {
"auto_detect_interface": true
}
}
```
TODO: finish this wiki