mirror of
https://hubproxy.babadafafafafa.cn/https://github.com/1Panel-dev/1Panel.git
synced 2026-09-21 00:24:12 +08:00
f35b0deb29
Port forwarding no longer shares the filter client. FilterClient keeps only
filter capabilities, and forwarding gets its own adapter, service and boot
replay:
- utils/firewall/forwarding holds the provider adapters. firewalld uses native
forward-port, ufw and iptables share the NAT implementation moved out of
client/iptables/forward.go.
- service/forwarding.go owns base info, search, operate, enable and replay.
The API keeps its routes and dispatches on name/type/operate.
- init/firewall replays forwarding through that service instead of loading NAT
rule files inline.
Also adds 1PANEL_FORWARD to the IptablesOp name enum: the frontend already
sends {"name":"1PANEL_FORWARD","operate":"init-forward"} and the validator
rejected it with 400 before reaching the service. Besides that, the only
observable difference is that a forward-tab search no longer triggers the
port/address record cleanup goroutine on the side.
20 lines
559 B
Go
20 lines
559 B
Go
package client
|
|
|
|
type FireInfo struct {
|
|
ID uint `json:"id"`
|
|
Chain string `json:"chain"`
|
|
Family string `json:"family"` // ipv4 ipv6
|
|
Address string `json:"address"` // Anywhere
|
|
Port string `json:"port"`
|
|
Protocol string `json:"protocol"` // tcp udp tcp/udp
|
|
Strategy string `json:"strategy"` // accept drop
|
|
|
|
Num string `json:"num"`
|
|
TargetIP string `json:"targetIP"`
|
|
TargetPort string `json:"targetPort"`
|
|
Interface string `json:"interface"`
|
|
|
|
UsedStatus string `json:"usedStatus"`
|
|
Description string `json:"description"`
|
|
}
|