vrr/g3
2
0
Fork 0
mirror of https://github.com/bytedance/g3.git synced 2026-05-01 21:20:40 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

format makrdown doc

Browse source
This commit is contained in:
Zhang Jingqiang 2024-08-25 19:21:10 +08:00
parent ad089cc0db
commit aa04d5d345
3 changed files with 317 additions and 252 deletions
Download patch file Download diff file Expand all files Collapse all files

322
g3proxy/UserGuide.en_US.md
View file

@ -46,22 +46,29 @@
## Installation
Currently, g3proxy only supports Linux systems and provides packaging and installation support for Debian, RHEL, and other distributions.
Refer to the [Release and Packaging Steps](/README.md#release-and-packaging) to package and install directly on the target system.
Currently, g3proxy only supports Linux systems and provides packaging and installation support for Debian, RHEL, and
other distributions.
Refer to the [Release and Packaging Steps](/README.md#release-and-packaging) to package and install directly on the
target system.
## Basic Concepts
### Service Management
Multiple g3proxy services can be deployed on a single machine and managed through systemd unit services. Each unit corresponds to a g3proxy process group (daemon_group),
Multiple g3proxy services can be deployed on a single machine and managed through systemd unit services. Each unit
corresponds to a g3proxy process group (daemon_group),
and each process group has a Unix socket file for local RPC management.
Each service has an entry configuration file in YAML format, with a customizable suffix, but all referenced configuration files must have the same suffix. In the following text, *main.yml* will be used to refer to the entry configuration file.
Each service has an entry configuration file in YAML format, with a customizable suffix, but all referenced
configuration files must have the same suffix. In the following text, *main.yml* will be used to refer to the entry
configuration file.
For installations using native distribution packages, systemd parameterized service configuration files are already installed. The parameter is the process group name,
For installations using native distribution packages, systemd parameterized service configuration files are already
installed. The parameter is the process group name,
and the corresponding entry configuration file is located at `/etc/g3proxy/<daemon_group>/main.yml`.
For installations without using packages, you can refer to [g3proxy@.service](service/g3proxy@.latest.service) to design your own service usage.
For installations without using packages, you can refer to [g3proxy@.service](service/g3proxy@.latest.service) to design
your own service usage.
### Hot Upgrades
@ -71,9 +78,13 @@ The default systemd service configuration supports hot upgrades, following these
2. Execute `systemctl daemon-reload` to load the new version service configuration.
3. Execute `systemctl restart g3proxy@<daemon_group>` to start the new process and notify the old process to go offline.
After the old process goes offline, it will wait for the existing tasks to exit or forcibly go offline after a certain period of time (default 10 hours).
After the old process goes offline, it will wait for the existing tasks to exit or forcibly go offline after a certain
period of time (default 10 hours).
The hot upgrade mechanism is similar to nginx reload. Due to operating system limitations, there is a chance that new connection requests will be dropped when sockets are released. Starting from Linux 5.14, the [tcp_migrate_req](https://docs.kernel.org/networking/ip-sysctl.html) option is introduced to ensure that connections are not lost.
The hot upgrade mechanism is similar to nginx reload. Due to operating system limitations, there is a chance that new
connection requests will be dropped when sockets are released. Starting from Linux 5.14,
the [tcp_migrate_req](https://docs.kernel.org/networking/ip-sysctl.html) option is introduced to ensure that connections
are not lost.
### Configuration Structure
@ -81,18 +92,20 @@ g3proxy adopts a modular approach for functionality design, mainly consisting of
1. Server
Responsible for accepting client requests and processing them, invoking the functionalities of the Egress, User, and Audit modules.
Entry of type *Port* can be placed before non-port type entries for chaining.
Responsible for accepting client requests and processing them, invoking the functionalities of the Egress, User, and
Audit modules.
Entry of type *Port* can be placed before non-port type entries for chaining.
2. Escaper
Responsible for connecting to and controlling the target address, invoking the functionalities of the Resolver module.
Egress of type *Route* can be placed before other egresses for chaining.
Responsible for connecting to and controlling the target address, invoking the functionalities of the Resolver
module.
Egress of type *Route* can be placed before other egresses for chaining.
3. Resolver
Provides domain name resolution functionality.
Failover resolution can be placed before other resolvers for chaining.
Provides domain name resolution functionality.
Failover resolution can be placed before other resolvers for chaining.
4. UserGroup
@ -102,18 +115,24 @@ g3proxy adopts a modular approach for functionality design, mainly consisting of
Provides traffic auditing functionality.
The configuration for these modules can be written together with *main.yml* or managed using separate configuration files, which allows for independent reloading.
The configuration for these modules can be written together with *main.yml* or managed using separate configuration
files, which allows for independent reloading.
In addition to the configuration for the above modules, including threads/logs/monitoring, all need to be written in *main.yml*.
In addition to the configuration for the above modules, including threads/logs/monitoring, all need to be written in
*main.yml*.
For a single file configuration, refer to [examples/inspect_http_proxy](examples/inspect_http_proxy),
For a split file configuration, refer to [examples/hybrid_https_proxy](examples/hybrid_https_proxy).
The following examples will not display the complete configuration file, but only show the relevant parts. For complete examples, refer to [examples](examples).
The following examples will not display the complete configuration file, but only show the relevant parts. For complete
examples, refer to [examples](examples).
### Monitoring
To facilitate integration with various monitoring solutions, the G3 project uses [StatsD](https://www.datadoghq.com/blog/statsd/) as the monitoring output protocol. Users can choose a suitable StatsD implementation (such as [gostatsd](https://github.com/atlassian/gostatsd)) based on their actual situation, configure it, and then integrate it into their own monitoring system.
To facilitate integration with various monitoring solutions, the G3 project
uses [StatsD](https://www.datadoghq.com/blog/statsd/) as the monitoring output protocol. Users can choose a suitable
StatsD implementation (such as [gostatsd](https://github.com/atlassian/gostatsd)) based on their actual situation,
configure it, and then integrate it into their own monitoring system.
The monitoring configuration for g3proxy is configured in the main configuration file *main.yml*, as shown below:
@ -126,7 +145,8 @@ stat:
emit_duration: 200ms # Interval between metrics
```
The specific metrics are defined in the [metrics](doc/metrics) folder. It is recommended to generate the Sphinx HTML documentation and view it.
The specific metrics are defined in the [metrics](doc/metrics) folder. It is recommended to generate the Sphinx HTML
documentation and view it.
## Basic Usage
@ -141,8 +161,9 @@ server:
type: http_proxy
listen:
address: "[::]:8080"
tls_client: {} # Open layer-7 https forward forwarding support
tls_client: { } # Open layer-7 https forward forwarding support
```
### SOCKS Proxy
To enable the SOCKS proxy entry, add the SocksProxy type entry, as shown below:
@ -169,7 +190,7 @@ server:
type: tcp_stream
listen:
address: "[::1]:10086"
proxy_pass: # Target address, can be single/multiple
proxy_pass: # Target address, can be single/multiple
- "127.0.0.1:5201"
- "127.0.0.1:5202"
upstream_pick_policy: rr # Load balancing algorithm, default is random
@ -186,7 +207,7 @@ server:
type: tcp_stream
listen: "[::1]:80"
proxy_pass: "127.0.0.1:443"
tls_client: {} # Use TLS to connect to the target port, configure TLS parameters, such as CA certificate, client certificate (mTLS), etc.
tls_client: { } # Use TLS to connect to the target port, configure TLS parameters, such as CA certificate, client certificate (mTLS), etc.
```
### TLS Encapsulation
@ -202,12 +223,12 @@ server:
type: tls_stream
listen:
address: "[::1]:10443"
tls_server: # Configure TLS parameters
tls_server: # Configure TLS parameters
cert_pairs:
certificate: /path/to/cert
private_key: /path/to/key
enable_client_auth: true # Optional, enable mTLS
proxy_pass: # Target address, can be single/multiple
proxy_pass: # Target address, can be single/multiple
- "127.0.0.1:5201"
- "127.0.0.1:5202"
upstream_pick_policy: rr # Load balancing algorithm, default is random
@ -220,7 +241,7 @@ server:
- name: tcp
escaper: default
type: tcp_stream
proxy_pass: # Target address, can be single/multiple
proxy_pass: # Target address, can be single/multiple
- "127.0.0.1:5201"
- "127.0.0.1:5202"
upstream_pick_policy: rr # Load balancing algorithm, default is random
@ -228,7 +249,7 @@ server:
type: plain_tls_port
listen:
address: "[::1]:10443"
tls_server: # Configure TLS parameters
tls_server: # Configure TLS parameters
cert_pairs:
certificate: /path/to/cert
private_key: /path/to/key
@ -238,7 +259,8 @@ server:
### SNI Proxy
Automatically recognize the target address in TLS SNI / HTTP Host headers and forward it. Add the SniProxy type entry, as shown below:
Automatically recognize the target address in TLS SNI / HTTP Host headers and forward it. Add the SniProxy type entry,
as shown below:
```yaml
server:
@ -271,7 +293,8 @@ The system level config should be taken is different depending on the OS type:
### Route Binding
When there are multiple network routes on a machine and you need to bind to one of them when accessing a target website, specify the Bind IP in the outbound configuration, using DirectFixed as an example:
When there are multiple network routes on a machine and you need to bind to one of them when accessing a target website,
specify the Bind IP in the outbound configuration, using DirectFixed as an example:
```yaml
escaper:
@ -289,7 +312,8 @@ resolver:
### Proxy Chaining
When you need to chain with other proxies, use the *Proxy* type of outbound configuration, using ProxyHttps as an example:
When you need to chain with other proxies, use the *Proxy* type of outbound configuration, using ProxyHttps as an
example:
```yaml
escaper:
@ -307,14 +331,16 @@ escaper:
### Connection Throttling
Both the inbound and outbound support per-connection throttling on a global level. Set the same key in the corresponding server & escaper:
Both the inbound and outbound support per-connection throttling on a global level. Set the same key in the corresponding
server & escaper:
```yaml
tcp_sock_speed_limit: 10M/s
udp_sock_speed_limit: 10M/s
```
The inbound configuration is for the Client-Proxy connection, and the outbound configuration is for the Proxy-Target connection.
The inbound configuration is for the Client-Proxy connection, and the outbound configuration is for the Proxy-Target
connection.
### Secure Resolution
@ -348,7 +374,9 @@ resolver:
### User Authentication and Authorization
Both Http proxy and Socks5 proxy support user authentication. It needs to be configured in conjunction with UserGroup. For the overall configuration, refer to [examples/simple_user_auth](examples/simple_user_auth). An example of a user group is shown below:
Both Http proxy and Socks5 proxy support user authentication. It needs to be configured in conjunction with UserGroup.
For the overall configuration, refer to [examples/simple_user_auth](examples/simple_user_auth). An example of a user
group is shown below:
```yaml
user_group:
@ -356,14 +384,14 @@ user_group:
static_users:
- name: root
# password: toor
token: # Authentication token
token: # Authentication token
salt: 113323bdab6fd2cc
md5: 5c81f2becadde7fa5fde9026652ccc84
sha1: ff9d5c1a14328dd85ee95d4e574bd0558a1dfa96
dst_port_filter: # Pass-through port
dst_port_filter: # Pass-through port
- 80
- 443
dst_host_filter_set: # Pass-through address
dst_host_filter_set: # Pass-through address
exact:
- ipinfo.io # Allow access to ipinfo.io
- 1.1.1.1
@ -371,16 +399,18 @@ user_group:
- "ipip.net" # Allow access to myip.ipip.net
regex:
- "lum[a-z]*[.]com$" # Allow access to lumtest.com
source: # Dynamic users, static users have priority, match dynamic users when no static users are available
source: # Dynamic users, static users have priority, match dynamic users when no static users are available
type: file # Load from file regularly, also supports loading and caching through lua/python scripts
path: dynamic_users.json
```
To generate a user authentication token, you need to use the [scripts/passphrase_hash.py](/scripts/passphrase_hash.py) script.
To generate a user authentication token, you need to use the [scripts/passphrase_hash.py](/scripts/passphrase_hash.py)
script.
### User Rate Limiting and Throttling
User-level rate limiting and throttling support single connection rate limiting, RPS limiting, and total concurrent task limiting:
User-level rate limiting and throttling support single connection rate limiting, RPS limiting, and total concurrent task
limiting:
```yaml
tcp_sock_speed_limit: 10M/s # TCP single connection bidirectional speed limit 10M/s
@ -394,7 +424,9 @@ request_max_alive: 2000 # Total concurrent task number limit
### mTLS Client
In several sections of this document, TLS client configuration is mentioned. If you need to enable mTLS mutual authentication as a TLS client, use the following example configuration:
In several sections of this document, TLS client configuration is mentioned. If you need to enable mTLS mutual
authentication as a TLS client, use the following example configuration:
```yaml
tls_client:
certificate: /path/to/cert.crt # Client certificate
@ -406,7 +438,8 @@ tls_client:
This feature requires enabling the vendored-tongsuo feature at compile time.
In some scenarios, it may be necessary to use the Guomi protocol for access. Many clients do not support the Guomi protocol, so you can use g3proxy for protocol conversion:
In some scenarios, it may be necessary to use the Guomi protocol for access. Many clients do not support the Guomi
protocol, so you can use g3proxy for protocol conversion:
* TLCP to layer-4 TCP
@ -422,6 +455,7 @@ server:
# Additional configuration for mTLS, etc.
upstream_tls_name: target.host.domain # Target domain name, used to verify the target identity (if the upstream url contains the domain name, it can be omitted)
```
* TLCP to layer-4 TLS
```yaml
@ -493,9 +527,11 @@ server:
type: SocksProxy
listen: "127.0.0.1:2002" # Listen on the local address to prevent abuse, it will not be used itself
```
### Listening on Multiple Ports
When the same service configuration needs to listen on multiple ports, you can chain Port-type entries in front of the Server.
When the same service configuration needs to listen on multiple ports, you can chain Port-type entries in front of the
Server.
An example of SNI Proxy listening on multiple ports:
@ -520,7 +556,7 @@ server:
escaper: default # Required, can be any type of exit
type: http_proxy
listen: "[::]:8080"
tls_client: {} # Open layer-7 https forward forwarding support
tls_client: { } # Open layer-7 https forward forwarding support
- name: tls
type: plain_tls_port
listen: "[::]:8443"
@ -532,11 +568,13 @@ server:
enable_client_auth: true # Optional, enable mTLS
```
Port-type entries only have independent Listen monitoring, while traffic monitoring and logging are handled by the next hop Server. When planning, consider whether chaining Ports or splitting Servers is more appropriate.
Port-type entries only have independent Listen monitoring, while traffic monitoring and logging are handled by the next
hop Server. When planning, consider whether chaining Ports or splitting Servers is more appropriate.
### Enabling PROXY Protocol on Listening Ports
In a chaining scenario, if you need to pass through client address information, you can use the PROXY Protocol. You can use PlainTcpPort or PlainTlsPort to configure a separate port that supports the PROXY Protocol.
In a chaining scenario, if you need to pass through client address information, you can use the PROXY Protocol. You can
use PlainTcpPort or PlainTlsPort to configure a separate port that supports the PROXY Protocol.
Example:
@ -545,14 +583,14 @@ server:
- name: real_http
listen: "[127.0.0.1]:1234" # Optional
type: http_proxy
ingress_network_filter: {} # Configure the filter rule for extracting the source address for PROXY Protocol
ingress_network_filter: { } # Configure the filter rule for extracting the source address for PROXY Protocol
# ... Other configurations
- name: pp_for_http
type: plain_tcp_port
listen: "[::]:8080"
server: real_http
proxy_protocol: v2
ingress_network_filter: {} # Configure the filter rule for the original socket source address
ingress_network_filter: { } # Configure the filter rule for the original socket source address
```
### Guomi TLCP Protocol Encapsulation
@ -571,7 +609,7 @@ server:
type: native_tls_port
listen: "[::]:443"
tls_server:
tlcp_cert_pairs: # Enable Guomi TLCP protocol
tlcp_cert_pairs: # Enable Guomi TLCP protocol
sign_certificate: /path/to/sign.crt
sign_private_key: /path/to/sign.key
enc_certificate: /path/to/enc.crt
@ -583,7 +621,9 @@ server:
### Socks5 UDP IP Mapping
When processing Socks5 UDP, the client needs to be sent the address of the UDP data connection, which is usually the local IP:Port. In some cases, the client cannot directly access the IP address of the proxy. In this case, you need to configure a mapping table in the socks server:
When processing Socks5 UDP, the client needs to be sent the address of the UDP data connection, which is usually the
local IP:Port. In some cases, the client cannot directly access the IP address of the proxy. In this case, you need to
configure a mapping table in the socks server:
```yaml
transmute_udp_echo_ip:
@ -592,7 +632,8 @@ transmute_udp_echo_ip:
### Secure Reverse Proxy
Many software exposes HTTP APIs or metrics interfaces. Their own security protection strategies are relatively simple. You can use the following configuration to strengthen security:
Many software exposes HTTP APIs or metrics interfaces. Their own security protection strategies are relatively simple.
You can use the following configuration to strengthen security:
```yaml
server:
@ -611,9 +652,12 @@ server:
upstream: 127.0.0.1:8082 # Path/all forwarding
# Enable TLS through tls_server, or add an independent TLS port through the front plain_tls_port
```
### Domain Name Resolution Hijacking
In many cases, you may want to bypass the normal DNS resolution process and use special domain name resolution rules. You can configure this in the user configuration:
In many cases, you may want to bypass the normal DNS resolution process and use special domain name resolution rules.
You can configure this in the user configuration:
```yaml
resolve_redirection:
- exact: t1.example.net # Fixed to specific IP
@ -626,7 +670,8 @@ resolve_redirection:
### Dynamic Route Binding
Some machines have dynamically assigned IP addresses, such as through DHCP or PPP dial-up. These IP addresses can be dynamically bound to the DirectFloat egress:
Some machines have dynamically assigned IP addresses, such as through DHCP or PPP dial-up. These IP addresses can be
dynamically bound to the DirectFloat egress:
Proxy configuration:
@ -645,7 +690,9 @@ g3proxy-ctl -G <daemon_group> -p <pid> escaper float publish "{\"ipv4\": \"192.1
### Dynamic Proxy Chaining
In web scraping scenarios, many obtained proxy addresses have a limited validity period. You can encapsulate an intermediate proxy and automatically handle expired proxy replacement through auxiliary programs. This way, clients only need to set a fixed proxy address:
In web scraping scenarios, many obtained proxy addresses have a limited validity period. You can encapsulate an
intermediate proxy and automatically handle expired proxy replacement through auxiliary programs. This way, clients only
need to set a fixed proxy address:
Proxy configuration:
@ -674,13 +721,13 @@ explicit_sites:
- id: example-net
child_match: example.net
emit_stats: true # Establish independent monitoring, the id field will be part of the monitoring entry name
resolve_strategy: # Can configure separate resolution strategies
resolve_strategy: # Can configure separate resolution strategies
query: ipv4only # Only resolve ipv4 addresses
```
### Custom User-Site MITM TLS Client Config
In the user-site configuration, you can set tls_client params to control the TLS behaviour in TLS MITM hijacking.
In the user-site configuration, you can set tls_client params to control the TLS behaviour in TLS MITM hijacking.
在用户-站点配置中，可对TLS劫持时的TLS Client行为进行设置：
```yaml
@ -697,32 +744,37 @@ explicit_sites:
### Traffic Audit
To enable traffic audit, refer to the complete configuration in [examples/inspect_http_proxy](examples/inspect_http_proxy). An example configuration for the audit module is as follows:
To enable traffic audit, refer to the complete configuration
in [examples/inspect_http_proxy](examples/inspect_http_proxy). An example configuration for the audit module is as
follows:
```yaml
auditor:
- name: default
protocol_inspection: {} # Enable protocol recognition, use default parameters
tls_cert_generator: {} # Enable TLS hijacking, use default parameters, peer address will be 127.0.0.1:2999
tls_interception_client: {} # Can configure proxy to target address TLS connection parameters
h1_interception: {} # HTTP/1.0 parsing parameters
h2_interception: {} # HTTP/2 parsing parameters
protocol_inspection: { } # Enable protocol recognition, use default parameters
tls_cert_generator: { } # Enable TLS hijacking, use default parameters, peer address will be 127.0.0.1:2999
tls_interception_client: { } # Can configure proxy to target address TLS connection parameters
h1_interception: { } # HTTP/1.0 parsing parameters
h2_interception: { } # HTTP/2 parsing parameters
icap_reqmod_service: icap://xxx # ICAP REQMOD service configuration
icap_respmod_service: icap://xxx # ICAP RESPMOD service configuration
application_audit_ratio: 1.0 # Application traffic audit ratio, matched according to client proxy request, if audit then perform protocol recognition and TLS hijacking
```
Note that you will need to run the `tls cert generator` first, such as [g3fcgen](/g3fcgen) which is a reference implementation, see [g3fcgen simple conf](/g3fcgen/examples/simple) for an example conf.
Note that you will need to run the `tls cert generator` first, such as [g3fcgen](/g3fcgen) which is a reference
implementation, see [g3fcgen simple conf](/g3fcgen/examples/simple) for an example conf.
### Exporting Decrypted TLS Traffic
When enabling traffic audit and TLS interception, you can configure the export of decrypted TLS traffic to [udpdump](https://www.wireshark.org/docs/man-pages/udpdump.html).
When enabling traffic audit and TLS interception, you can configure the export of decrypted TLS traffic
to [udpdump](https://www.wireshark.org/docs/man-pages/udpdump.html).
For specific configurations, refer to [examples/inspect_http_proxy](examples/inspect_http_proxy).
### Performance Optimization
By default, the proxy will use all CPU cores and perform cross-core task scheduling. In some scenarios, binding CPU cores can improve performance. You can configure it as follows:
By default, the proxy will use all CPU cores and perform cross-core task scheduling. In some scenarios, binding CPU
cores can improve performance. You can configure it as follows:
In the *main.yml* file, configure the worker:
@ -732,7 +784,8 @@ worker:
sched_affinity: true # Enable core binding, which binds threads in order by default. You can also expand it to set the mapping relationship between Worker ID and CPU ID.
```
When configuring the server to listen, you can configure it to listen according to the number of workers and distribute it to each worker:
When configuring the server to listen, you can configure it to listen according to the number of workers and distribute
it to each worker:
```yaml
listen: "[::]:8080"
@ -750,58 +803,59 @@ Taking three regions as an example, the overall topology is as follows:
```mermaid
flowchart LR
%% Paste to https://mermaid.live/ to see the graph
subgraph Area1
a1_client[Client]
a1_site[Site]
subgraph Proxy1
a1_proxy[GW]
a1_relay[relay]
a1_route[route]
a1_proxy -.-> a1_route
subgraph Area1
a1_client[Client]
a1_site[Site]
subgraph Proxy1
a1_proxy[GW]
a1_relay[relay]
a1_route[route]
a1_proxy -.-> a1_route
end
a1_client --> a1_proxy
a1_route -- local --> a1_site
a1_relay -- local --> a1_site
end
a1_client --> a1_proxy
a1_route --local--> a1_site
a1_relay --local--> a1_site
end
subgraph Area2
a2_client[Client]
a2_site[Site]
subgraph Proxy2
a2_proxy[GW]
a2_relay[relay]
a2_route[route]
a2_proxy -.-> a2_route
subgraph Area2
a2_client[Client]
a2_site[Site]
subgraph Proxy2
a2_proxy[GW]
a2_relay[relay]
a2_route[route]
a2_proxy -.-> a2_route
end
a2_client --> a2_proxy
a2_route -- local --> a2_site
a2_relay -- local --> a2_site
end
a2_client --> a2_proxy
a2_route --local--> a2_site
a2_relay --local--> a2_site
end
subgraph Area3
a3_client[Client]
a3_site[Site]
subgraph Proxy3
a3_proxy[GW]
a3_relay[relay]
a3_route[route]
a3_proxy -.-> a3_route
subgraph Area3
a3_client[Client]
a3_site[Site]
subgraph Proxy3
a3_proxy[GW]
a3_relay[relay]
a3_route[route]
a3_proxy -.-> a3_route
end
a3_client --> a3_proxy
a3_route -- local --> a3_site
a3_relay -- local --> a3_site
end
a3_client --> a3_proxy
a3_route --local--> a3_site
a3_relay --local--> a3_site
end
a1_route --mTLS to a2----> a2_relay
a1_route --mTLS to a3----> a3_relay
a2_route --mTLS to a1----> a1_relay
a2_route --mTLS to a3----> a3_relay
a3_route --mTLS to a1----> a1_relay
a3_route --mTLS to a2----> a2_relay
a1_route -- mTLS to a2 ----> a2_relay
a1_route -- mTLS to a3 ----> a3_relay
a2_route -- mTLS to a1 ----> a1_relay
a2_route -- mTLS to a3 ----> a3_relay
a3_route -- mTLS to a1 ----> a1_relay
a3_route -- mTLS to a2 ----> a2_relay
```
Each node's Proxy is configured with the following functions:
- GW
Handles local user requests and can use [SNI Proxy](#sni-proxy) for Layer-4 acceleration or [HTTP Reverse Proxy](#secure-reverse-proxy) for Layer-7 acceleration.
Handles local user requests and can use [SNI Proxy](#sni-proxy) for Layer-4 acceleration
or [HTTP Reverse Proxy](#secure-reverse-proxy) for Layer-7 acceleration.
Simplified configuration:
@ -831,7 +885,8 @@ Each node's Proxy is configured with the following functions:
- route
Routes and distributes local user requests, requiring configuration of >=1 route-type exits, one local exit, and one Proxy exit for each region.
Routes and distributes local user requests, requiring configuration of >=1 route-type exits, one local exit, and one
Proxy exit for each region.
Simplified configuration:
```yaml
@ -859,40 +914,43 @@ Each node's Proxy is configured with the following functions:
### Dual Exit Disaster Recovery
When a single IDC has multiple POP points with public network exits or in similar cases where there are at least 2 **non-local** routes available for accessing the target site, if you want to automatically switch between the two routes for automatic disaster recovery, you can design it as follows:
When a single IDC has multiple POP points with public network exits or in similar cases where there are at least 2 *
*non-local** routes available for accessing the target site, if you want to automatically switch between the two routes
for automatic disaster recovery, you can design it as follows:
The topology diagram is as follows:
```mermaid
flowchart LR
%% Paste to https://mermaid.live/ to see the graph
subgraph IDC
i1_client[Client]
subgraph Proxy
i1_proxy[GW]
i1_route[route]
i1_proxy -.-> i1_route
subgraph IDC
i1_client[Client]
subgraph Proxy
i1_proxy[GW]
i1_route[route]
i1_proxy -.-> i1_route
end
i1_client --> i1_proxy
end
i1_client --> i1_proxy
end
subgraph POP1
p1_proxy[relay]
end
subgraph POP2
p2_proxy[relay]
end
internet[Internet]
i1_route --proxy to pop1--> p1_proxy
i1_route --proxy to pop2--> p2_proxy
p1_proxy --local---> internet
p2_proxy --local---> internet
subgraph POP1
p1_proxy[relay]
end
subgraph POP2
p2_proxy[relay]
end
internet[Internet]
i1_route -- proxy to pop1 --> p1_proxy
i1_route -- proxy to pop2 --> p2_proxy
p1_proxy -- local ---> internet
p2_proxy -- local ---> internet
```
Each node's Proxy is configured with the following functions:
- GW
Handles client requests and can be configured as any type of server, such as forward proxy, reverse proxy, TCP mapping, etc.
Handles client requests and can be configured as any type of server, such as forward proxy, reverse proxy, TCP
mapping, etc.
- relay
@ -908,11 +966,13 @@ Each node's Proxy is configured with the following functions:
tls_server: {} # Configure TLS parameters
```
Note: If the GW in the IDC needs to support the Socks5 UDP protocol, the relay should be configured as a UDP proxy, using [SOCKS Proxy](#socks-proxy).
Note: If the GW in the IDC needs to support the Socks5 UDP protocol, the relay should be configured as a UDP proxy,
using [SOCKS Proxy](#socks-proxy).
- route
Routes and distributes local user requests, requiring configuration of >=1 route-type exits and one Proxy exit for each region.
Routes and distributes local user requests, requiring configuration of >=1 route-type exits and one Proxy exit for
each region.
Simplified configuration: