Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[QUESTION] frp inside Caddy server network - is that possible? #4171

Open
1 of 11 tasks
Kenya-West opened this issue Apr 19, 2024 · 3 comments
Open
1 of 11 tasks

[QUESTION] frp inside Caddy server network - is that possible? #4171

Kenya-West opened this issue Apr 19, 2024 · 3 comments

Comments

@Kenya-West
Copy link
Contributor

Kenya-West commented Apr 19, 2024

Bug Description

WhoAmI

Hi, a frontend guy that not so skilled in network stack is here.

What I try to do

I try to make FRP server fully isolated so it should work inside caddy network through Caddy server. (Is that even possible?)

Problem

The problem: since frps on VPS machine is working through Caddy server, it is accessible only by HTTP(S). While I can open dashboard in browser, any of frpc could not connect to server as they try to connect by TCP.
This problem is a ChatGPT conclusion and seems fair and adequate, I believe it.

Setup

  • FRP server is available on https://example.com/frp/server;
  • FRP server dashboard is on https://example.com/frp/dashboard.

I use lucaslorentz/caddy-docker-proxy repo that makes Caddy server setup even easier.

I just setup Caddy server by this repo and never touch it. It refreshes Caddyfile config dynamically once new Docker container in caddy network is created, modified or removed.

Architecture that I try represent:

flowchart TD
  aa(remote user) -.->|https://example.com/api/path| caddyserver
subgraph VPS
  caddyserver(Caddy server) -.-> |https://127.0.0.1:80/,\nhttps://127.0.0.1:443/| frp
  subgraph CaddyNetwork
    frp(frp) -->|https://172.27.0.4:84\nor whatever internal IP Docker gives| b(tunnel server)
  end
end
  b ===|https tunnel| c(tunnel client: 172.19.0.3)
subgraph home server
  c -->|frpc in network_host mode| d(frp)
  d -->|http| e(app)
end
  1. Files that setup on server:
~/caddy/
└── docker-compose.yml
~/frp/
├── .env
├── config-frps
│   └── frps.toml
└── docker-compose.yml
  1. Files that I setup on client:
~/frp/
├── config-frpc
│   └── frpc.toml
├── docker-compose.yml
└── .env

frpc Version

0.56.0

frps Version

0.56.0

System Architecture

linux/amd64

Configurations

Why does not frpc connect to frps?

SERVER

~/caddy/docker-compose.yml:

version: "3.8"
services:
  caddy:
    image: lucaslorentz/caddy-docker-proxy:ci-alpine
    container_name: caddy
    ports:
      - 80:80
      - 443:443
      - "443:443/udp"
    environment:
      - CADDY_INGRESS_NETWORKS=caddy
    networks:
      - caddy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./caddy_data:/data
      - ./config:/config
    restart: unless-stopped

networks:
  caddy:
    external: true

volumes:
  caddy_data: {}

~/frp/.env

DOMAIN=example.com                         # your domain
CADDY_PATH=frp                     # must be present, or it produces bugs. Example value: `frps`
FRPS_SERVER_PORT=7000               # the port of the server
FRPS_DASHBOARD_PORT=7500            # the port of the dashboard

~/frp/docker-compose.yml:

version: '3.8'
services:
  frps:
    image: snowdreamtech/frps
    container_name: frps
    restart: unless-stopped
    volumes:
      - ./config-frps:/etc/frp
    networks:
      - caddy
    labels:
      caddy: ${DOMAIN}
      caddy.0_handle_path: "/${CADDY_PATH}/dashboard"
      caddy.0_reverse_proxy: "{{upstreams ${FRPS_DASHBOARD_PORT}}}"
      caddy.1_handle_path: "/${CADDY_PATH}/server"
      caddy.1_reverse_proxy: "{{upstreams ${FRPS_SERVER_PORT}}}"
      caddy.2_handle_path: "/${CADDY_PATH}/server/port-22001"
      caddy.2_reverse_proxy: "{{upstreams 22001}}"
      caddy.3_handle_path: "/${CADDY_PATH}/server/port-22002"
      caddy.3_reverse_proxy: "{{upstreams 22002}}"
     # ...
      caddy.31_handle_path: "/${CADDY_PATH}/server/port-22030"
      caddy.31_reverse_proxy: "{{upstreams 22030}}"

networks:
  caddy:
    external: true

~/frp/config-frps/frps.toml

bindPort = 7000
allowPorts = [
  { start = 22001, end = 22030 }
]
webServer.addr = "0.0.0.0"
webServer.port = 7500
# dashboard's username and password are both optional
webServer.user = "admin"
webserver. Password = "password"
auth.method = "token"
auth.token = "sometoken"

CLIENT:

~/frp/config-frpc/frpc.toml

serverAddr = "example.com/frp/server"
serverPort = 443
auth.method = "token"
auth.token = "sometoken"

~/frp/docker-compose.yml:

version: '3.8'
services:
  frpc:
    image: snowdreamtech/frpc
    container_name: frpc
    restart: unless-stopped
    volumes:
      - ./config-frpc:/etc/frp
    network_mode: host

networks:
  caddy:
    external: true

Logs

Client (frpc) says:

frpc  | login to the server failed: dial tcp: lookup example.com/frp: no such host. With loginFailExit enabled, no additional retries will be attempted
frpc  | 2024-04-18 17:00:14.523 [I] [sub/root.go:142] start frpc service for config file [/etc/frp/frpc.toml]
frpc  | 2024-04-18 17:00:14.523 [I] [client/service.go:294] try to connect to server...
frpc  | 2024-04-18 17:00:14.524 [W] [client/service.go:297] connect to server error: dial tcp: lookup example.com/frp: no such host
frpc  | 2024-04-18 17:00:14.524 [I] [sub/root.go:160] frpc service for config file [/etc/frp/frpc.toml] stopped

Server (frps) displays nothing like client did not succeed to connect to it.

Since frps is inside caddy network, I check caddy and found nothing, too.

Affected area

  • Docs
  • Installation
  • Performance and Scalability
  • Security
  • User Experience
  • Test and Release
  • Developer Infrastructure
  • Client Plugin
  • Server Plugin
  • Extensions
  • Others
@xqzr
Copy link

xqzr commented Apr 19, 2024

frpc 与 frps 之间的连接,使用这几种协议

# supports tcp, kcp, quic, websocket and wss now, default is tcp

没有 https

@fatedier
Copy link
Owner

Try websocket and wss

Copy link

Issues go stale after 21d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants