1
2
3
4

auto eth1
iface eth1 inet static
        address 172.26.0.1
        netmask 255.255.255.0

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215

diff --git a/kea-dhcp4.conf b/kea-dhcp4.conf
index a26ae75..e9c578a 100644
--- a/kea-dhcp4.conf
+++ b/kea-dhcp4.conf
@@ -31,7 +31,7 @@
         // See section 8.2.4 for more details. You probably want to add just
         // interface name (e.g. "eth0" or specific IPv4 address on that
         // interface name (e.g. "eth0/192.0.2.1").
-        "interfaces": [ ]
+        "interfaces": [ "eth1" ]

         // Kea DHCPv4 server by default listens using raw sockets. This ensures
         // all packets, including those sent by directly connected clients
@@ -149,7 +149,7 @@
         // but it's a lot of writing, so it's easier to do this instead:
         {
             "name": "domain-name-servers",
-            "data": "192.0.2.1, 192.0.2.2"
+            "data": "119.29.29.29"
         },

         // Typically people prefer to refer to options by their names, so they
@@ -159,7 +159,7 @@
         // "name": "domain-name" or "code": 15.
         {
             "code": 15,
-            "data": "example.org"
+            "data": "gaein.cn"
         },

         // Domain search is also a popular option. It tells the client to
@@ -168,7 +168,7 @@
         // foo.mydomain.example.com and if it fails, then as foo.example.com
         {
             "name": "domain-search",
-            "data": "mydomain.example.com, example.com"
+            "data": "cn-tvs-alpine-homerouter"
         },

         // String options that have a comma in their values need to have
@@ -217,31 +217,6 @@
     // Based on the class information, you can then allow or reject clients
     // to use certain subnets, add special options for them or change values
     // of some fixed fields.
-    "client-classes": [
-        {
-            // This specifies a name of this class. It's useful if you need to
-            // reference this class.
-            "name": "voip",
-
-            // This is a test. It is an expression that is being evaluated on
-            // each incoming packet. It is supposed to evaluate to either
-            // true or false. If it's true, the packet is added to specified
-            // class. See Section 12 for a list of available expressions. There
-            // are several dozens. Section 8.2.14 for more details for DHCPv4
-            // classification and Section 9.2.19 for DHCPv6.
-            "test": "substring(option[60].hex,0,6) == 'Aastra'",
-
-            // If a client belongs to this class, you can define extra behavior.
-            // For example, certain fields in DHCPv4 packet will be set to
-            // certain values.
-            "next-server": "192.0.2.254",
-            "server-hostname": "hal9000",
-            "boot-file-name": "/dev/null"
-
-            // You can also define option values here if you want devices from
-            // this class to receive special options.
-        }
-    ],

     // Another thing possible here are hooks. Kea supports a powerful mechanism
     // that allows loading external libraries that can extract information and
@@ -294,14 +269,14 @@
             "id": 1,

             // This is mandatory parameter for each subnet.
-            "subnet": "192.0.2.0/24",
+            "subnet": "172.26.66.0/23",

             // Pools define the actual part of your subnet that is governed
             // by Kea. Technically this is optional parameter, but it's
             // almost always needed for DHCP to do its job. If you omit it,
             // clients won't be able to get addresses, unless there are
             // host reservations defined for them.
-            "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
+            "pools": [ { "pool": "172.26.67.2 - 172.26.67.100" } ],

             // These are options that are subnet specific. In most cases,
             // you need to define at least routers option, as without this
@@ -312,7 +287,7 @@
                     // For each IPv4 subnet you most likely need to specify at
                     // least one router.
                     "name": "routers",
-                    "data": "192.0.2.1"
+                    "data": "172.26.66.1"
                 }
             ],

@@ -335,31 +310,32 @@
                 // It's a rather simple reservation: just an address and nothing
                 // else.
                 {
-                    "hw-address": "1a:1b:1c:1d:1e:1f",
-                    "ip-address": "192.0.2.201"
+                    "hw-address": "DC:65:55:8A:F6:27",
+                    "ip-address": "172.26.67.1",
+                   "hostname": "h3c-ap"
                 },

                 // This is a reservation for a specific client-id. It also shows
                 // the this client will get a reserved hostname. A hostname can
                 // be defined for any identifier type, not just client-id.
-                {
-                    "client-id": "01:11:22:33:44:55:66",
-                    "ip-address": "192.0.2.202",
-                    "hostname": "special-snowflake"
-                },
+                // {
+                //     "client-id": "01:11:22:33:44:55:66",
+                //     "ip-address": "192.0.2.202",
+                //     "hostname": "special-snowflake"
+                // },

                 // The third reservation is based on DUID. This reservation defines
                 // a special option values for this particular client. If the
                 // domain-name-servers option would have been defined on a global,
                 // subnet or class level, the host specific values take preference.
-                {
-                    "duid": "01:02:03:04:05",
-                    "ip-address": "192.0.2.203",
-                    "option-data": [ {
-                        "name": "domain-name-servers",
-                        "data": "10.1.1.202, 10.1.1.203"
-                    } ]
-                },
+                // {
+                //     "duid": "01:02:03:04:05",
+                //     "ip-address": "192.0.2.203",
+                //     "option-data": [ {
+                //         "name": "domain-name-servers",
+                //         "data": "10.1.1.202, 10.1.1.203"
+                //     } ]
+                // },

                 // The fourth reservation is based on circuit-id. This is an option
                 // inserted by the relay agent that forwards the packet from client
@@ -370,31 +346,31 @@
                 // reservations-global, reservations-in-subnet,
                 // reservations-out-of-pool (subnet specific parameters)
                 // and host-reservation-identifiers (global parameter).
-                {
-                    "client-id": "01:12:23:34:45:56:67",
-                    "ip-address": "192.0.2.204",
-                    "option-data": [
-                        {
-                            "name": "vivso-suboptions",
-                            "data": "4491"
-                        },
-                        {
-                            "name": "tftp-servers",
-                            "space": "vendor-4491",
-                            "data": "10.1.1.202, 10.1.1.203"
-                        }
-                    ]
-                },
+                // {
+                //     "client-id": "01:12:23:34:45:56:67",
+                //     "ip-address": "192.0.2.204",
+                //     "option-data": [
+                //         {
+                //             "name": "vivso-suboptions",
+                //             "data": "4491"
+                //         },
+                //         {
+                //             "name": "tftp-servers",
+                //             "space": "vendor-4491",
+                //             "data": "10.1.1.202, 10.1.1.203"
+                //         }
+                //     ]
+                // },
                 // This reservation is for a client that needs specific DHCPv4
                 // fields to be set. Three supported fields are next-server,
                 // server-hostname and boot-file-name
-                {
-                    "client-id": "01:0a:0b:0c:0d:0e:0f",
-                    "ip-address": "192.0.2.205",
-                    "next-server": "192.0.2.1",
-                    "server-hostname": "hal9000",
-                    "boot-file-name": "/dev/null"
-                },
+                // {
+                //     "client-id": "01:0a:0b:0c:0d:0e:0f",
+                //     "ip-address": "192.0.2.205",
+                //     "next-server": "192.0.2.1",
+                //     "server-hostname": "hal9000",
+                //     "boot-file-name": "/dev/null"
+                // },
                 // This reservation is using flexible identifier. Instead of
                 // relying on specific field, sysadmin can define an expression
                 // similar to what is used for client classification,
@@ -405,10 +381,10 @@
                 //
                 // Note: flexible identifier requires flex_id hook library to be
                 // loaded to work.
-                {
-                    "flex-id": "'s0mEVaLue'",
-                    "ip-address": "192.0.2.206"
-                }
+                // {
+                //     "flex-id": "'s0mEVaLue'",
+                //     "ip-address": "192.0.2.206"
+                // }
                 // You can add more reservations here.
             ]
             // You can add more subnets there.

1
2

auto eth0
iface eth0 inet dhcp

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

noipdefault
defaultroute
replacedefaultroute
hide-password
#lcp-echo-interval 30
#lcp-echo-failure 4
noauth
persist
#mtu 1492
#maxfail 0
#holdoff 20
plugin pppoe.so eth0 # WAN 侧网卡
user "ip1**********" # PPPoE 用户名
#usepeerdns          # 使用运营商 DNS

1
2

# <PPPoE 用户名> <服务器> <PPPoE 密码>
"ip1**********" * "********"

1
2
3

auto ppp0
iface ppp0 inet ppp
    provider isp

1
2

net.core.default_qdisc=fq_codel
net.ipv4.tcp_congestion_control=bbr

1

net.ipv4.ip_forward=1

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

#!/usr/sbin/nft -f

table inet nat {
    chain prerouting {
        type nat hook prerouting priority dstnat; policy accept;
    }

    chain postrouting {
        type nat hook postrouting priority srcnat; policy accept;
        oifname "ppp0" masquerade
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

#!/usr/sbin/nft -f

table inet filter {
    chain input {
        iifname "eth1" accept
    }

    chain forward {
        type filter hook forward priority filter; policy accept;

        tcp flags syn tcp option maxseg size set rt mtu
    }

    chain output {
        type filter hook output priority filter; policy accept;
    }
}

1

tcp flags syn tcp option maxseg size set rt mtu

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_BPF_JIT=y
CONFIG_CGROUPS=y
CONFIG_KPROBES=y
CONFIG_NET_INGRESS=y
CONFIG_NET_EGRESS=y
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_CLS_BPF=m
CONFIG_NET_CLS_ACT=y
CONFIG_BPF_STREAM_PARSER=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
CONFIG_DEBUG_INFO_BTF=y
CONFIG_KPROBE_EVENTS=y
CONFIG_BPF_EVENTS=y

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105

# load all dae files placed in ./config.d/
include {
    config.d/*.dae
}

global {
    ##### Software options.

    # tproxy port to listen on. It is NOT a HTTP/SOCKS port, and is just used by eBPF program.
    # In normal case, you do not need to use it.
    tproxy_port: 12345

    # Set it true to protect tproxy port from unsolicited traffic. Set it false to allow users to use self-managed
    # iptables tproxy rules.
    tproxy_port_protect: true

    # Set non-zero value to enable pprof.
    pprof_port: 0

    # If not zero, traffic sent from dae will be set SO_MARK. It is useful to avoid traffic loop with iptables tproxy
    # rules.
    so_mark_from_dae: 0

    # Log level: error, warn, info, debug, trace.
    log_level: info

    # Disable waiting for network before pulling subscriptions.
    disable_waiting_network: false

    # Enable fast redirect for local TCP connections. There is a known kernel issue that breaks certain clients/proxies, such as nadoo/glider. Users may enable this experimental option at their own risks.
    enable_local_tcp_fast_redirect: false

    ##### Interface and kernel options.

    # The LAN interface to bind. Use it if you want to proxy LAN.
    # Multiple interfaces split by ",".
    lan_interface: eth1

    # The WAN interface to bind. Use it if you want to proxy localhost.
    # Multiple interfaces split by ",". Use "auto" to auto detect.
    wan_interface: auto

    # Automatically configure Linux kernel parameters like ip_forward and send_redirects. Check out
    # https://github.com/daeuniverse/dae/blob/main/docs/en/user-guide/kernel-parameters.md to see what will dae do.
    auto_config_kernel_parameter: true

    ##### Node connectivity check.

    # Host of URL should have both IPv4 and IPv6 if you have double stack in local.
    # First is URL, others are IP addresses if given.
    # Considering traffic consumption, it is recommended to choose a site with anycast IP and less response.
    #tcp_check_url: 'http://cp.cloudflare.com'
    tcp_check_url: 'http://cp.cloudflare.com,1.1.1.1,2606:4700:4700::1111'

    # The HTTP request method to `tcp_check_url`. Use 'HEAD' by default because some server implementations bypass
    # accounting for this kind of traffic.
    tcp_check_http_method: HEAD

    # This DNS will be used to check UDP connectivity of nodes. And if dns_upstream below contains tcp, it also be used to check
    # TCP DNS connectivity of nodes.
    # First is URL, others are IP addresses if given.
    # This DNS should have both IPv4 and IPv6 if you have double stack in local.
    #udp_check_dns: 'dns.google.com:53'
    udp_check_dns: 'dns.google.com:53,8.8.8.8,2001:4860:4860::8888'

    check_interval: 120s

    # G/oup will switch node only when new_latency <= old_latency - tolerance.
    check_tolerance: 50ms


    ##### Connecting options.

    # Optional values of dial_mode are:
    # 1. "ip". Dial proxy using the IP from DNS directly. This allows your ipv4, ipv6 to choose the optimal path
    #       respectively, and makes the IP version requested by the application meet expectations. For example, if you
    #       use curl -4 ip.sb, you will request IPv4 via proxy and get a IPv4 echo. And curl -6 ip.sb will request IPv6.
    #       This may solve some wierd full-cone problem if your are be your node support that. Sniffing will be disabled
    #       in this mode.
    # 2. "domain". Dial proxy using the domain from sniffing. This will relieve DNS pollution problem to a great extent
    #       if have impure DNS environment. Generally, this mode brings faster proxy response time because proxy will
    #       re-resolve the domain in remote, thus get better IP result to connect. This policy does not impact routing.
    #       That is to say, domain rewrite will be after traffic split of routing and dae will not re-route it.
    # 3. "domain+". Based on domain mode but do not check the reality of sniffed domain. It is useful for users whose
    #       DNS requests do not go through dae but want faster proxy response time. Notice that, if DNS requests do not
    #       go through dae, dae cannot split traffic by domain.
    # 4. "domain++". Based on domain+ mode but force to re-route traffic using sniffed domain to partially recover
    #       domain based traffic split ability. It doesn't work for direct traffic and consumes more CPU resources.
    dial_mode: domain+

    # Timeout to waiting for first data sending for sniffing. It is always 0 if dial_mode is ip. Set it higher is useful
    # in high latency LAN network.
    sniffing_timeout: 100ms

    # TLS implementation. tls is to use Go's crypto/tls. utls is to use uTLS, which can imitate browser's Client Hello.
    tls_implementation: tls

    # The Client Hello ID for uTLS to imitate. This takes effect only if tls_implementation is utls.
    # See more: https://github.com/daeuniverse/dae/blob/331fa23c16/component/outbound/transport/tls/utls.go#L17
    utls_imitate: chrome_auto
}

# dns sniff see:        /etc/dae/config.d/dns.dae
# node and group: see   /etc/dae/config.d/nodes.dae
# routing: see          /etc/dae/config.d/route.dae