Question about reserved-public vs temp-public shares

zrok
1

I am trying to understand why a share would only work if its set up using a reserved-public FRONTEND_MODE.

My ZROK_TARGET is https://host.docker.internal:8080

If I try to set it up with FRONTEND_MODE of temp-public I get an error: error proxying: tls: failed to verify certificate: x509: certificate is not valid for any names, but wanted to match host.docker.internal

But if I specify reserved-public with a name it works fine. There are no other changes.

I have set ZROK_INSECURE: "--insecure"

2

That's unexpected. Could there be state files left over between these two experiments with temp-public and reserved-public values for the ZROK_FRONTEND_MODE variable?

I'm wondering if you started fresh with the temp-public value.

Is your container set up similar to this reserved public share example?

This is the script that example runs that references the ZROK_FRONTEND_MODE variable.

3

Coming back to this issue. I started from a fresh container install and get this issue. If I use --insecure I need to use reserved-public and not temp-public or I get ssl errors?

4

The sharing mode you use "probably" has nothing to do with any TLS erorrs you're seeing.

You're saying you make a share, try to access the share, and get: error proxying: tls: failed to verify certificate: x509: certificate is not valid for any names?

Can you make a share for me to poke at to see what happens on my side? Or, can you tell me your exact steps specifically so I can try to replicate it?

5

I am using docker with this configuration:

services:
  # set file ownership
  zrok-init:
    image: busybox
    # matches uid:gid of "ziggy" in zrok container image
    command: chown -Rc 2171:2171 /mnt/
    user: root
    volumes:
      - ./zrok_data:/mnt  # Replace named volume with a bind mount

  # enable zrok environment
  zrok-enable:
    image: ${ZROK_CONTAINER_IMAGE:-docker.io/openziti/zrok}
    depends_on:
      zrok-init:
        condition: service_completed_successfully
    entrypoint: zrok-enable.bash
    volumes:
      - ./zrok_data:/mnt  # Replace named volume with a bind mount
    environment:
      HOME: /mnt
      ZROK_ENABLE_TOKEN: "grS6auXwL0Hq"
      ZROK_API_ENDPOINT: "https://zrok.connect.gputrader.io"
      ZROK_ENVIRONMENT_NAME: "${ENV_NAME}"

  # reserve zrok frontend subdomain and start sharing the target
  zrok-share:
    image: ${ZROK_CONTAINER_IMAGE:-docker.io/openziti/zrok}
    restart: unless-stopped
    depends_on:
      zrok-enable:
        condition: service_completed_successfully
    entrypoint: zrok-share.bash
    volumes:
      - ./zrok_data:/mnt  # Replace named volume with a bind mount
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      # internal configuration
      HOME: /mnt  # zrok homedir in container

      # most relevant options
      ZROK_UNIQUE_NAME: "${SUBDOMAIN}" # name is used to construct frontend domain name, e.g. "myapp" in "myapp.share.zrok.io"
      ZROK_BACKEND_MODE:    # web, caddy, drive, proxy
      ZROK_TARGET: "https://host.docker.internal:${TARGET_PORT}"          # backend target, is a path in container filesystem unless proxy mode
      ZROK_INSECURE: "--insecure" # if proxy target has unverifiable TLS server certificate
      ZROK_OAUTH_PROVIDER:  # google, github
      ZROK_OAUTH_EMAILS:    # allow space-separated list of OAuth email address glob patterns
      ZROK_BASIC_AUTH:      # username:password, mutually-exclusive with ZROK_OAUTH_PROVIDER

      # least relevant options
      ZROK_VERBOSE:           # "--verbose"
      ZROK_SHARE_OPTS:        # additional arguments to "zrok reserve public" command
      ZROK_FRONTENDS: "public"        # "public"
      ZROK_FRONTEND_MODE: "reserved-public"
      PFXLOG_NO_JSON: "true"  # suppress JSON logging format

# Note: Removing the "volumes" section since we're now using a bind mount.

Basically if I change ZROK_FRONTEND_MODE: "temp-public" I get the following errors on the webapp I'm trying to share:

140253776602880:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1552:SSL alert number 42
 2024-10-09 23:32:34,044 [DEBUG] websocket 3: using SSL socket
 2024-10-09 23:32:34,044 [DEBUG] websocket 3: Client closed during handshake
 2024-10-09 23:32:34,044 [DEBUG] websocket 3: No connection after handshake
 2024-10-09 23:32:34,044 [DEBUG] websocket 3: handler exit
 2024-10-09 23:32:36,192 [INFO] websocket 4: got client connection from 172.21.0.1

As soon as i change to reserved-public it seems to work fine:

 2024-10-09 23:35:11,496 [DEBUG] websocket 20: X-Forwarded-For ip '73.3.236.160'
 2024-10-09 23:35:11,496 [INFO] websocket 24: got client connection from 172.21.0.1
 2024-10-09 23:35:11,496 [DEBUG] websocket 21: using SSL socket
6

There is no difference in any of the core zrok or the zrok.io deployment between reserved and ephemeral shares. It's literally using exactly the same code paths and infrastructure to service both methods, the only difference between them is when the share is "released".

If you're seeing a difference in behavior, it's likely attributed to something else in your footprint.

I can't speak to the docker components... it's possible there is something in there that is contributing to the issue?

7

I see the problem and will paste a solution here ASAP. The zrok-share.bash wrapper script doesn't set the --insecure flag under certain conditions. I'll refactor it with a notion of standard options that includes the --insecure and --verbose flags configured by their respective env vars.

8

I just built and pushed an x64 container image with v0.4.41 [17d3b07b] on my fix branch.

You can try it by setting your .env file like this to get it before the next zrok release.

ZROK_CONTAINER_IMAGE="docker.io/kbinghamnetfoundry/zrok:fixopts"
1 Like