Raw http services work, but things behind more complex setups like proxies, or laravel are having issues

zrok
1

This is probably something I have done. I have setup a local instance of zrok and it seems to work fine. However I seem to have issues when accessing more complex web services. In my test cases, I have one person who uses Laravel on their mac. And they use Laravel Valet to serve their pages. I believe this is behind NGINX. In this case, it worked fine locally, but when trying to serve the page through zrok, it returns a 404.

Another example, I have CUPS running locally on my mac. It is access via http://localhost:631. When I share this with ZROK I just see "Bad Request". using the randomized link. Looking at the CUPS log I see:
[08/Jul/2024:11:50:48 -0400] [Client 2062] Request from "localhost" using invalid Host: field "l0f6zodvldyp.zrok.domain.com".

So it seems like ZROK isnt sending the endpoint host header? Is there a way for ZROK to access the local resource using the local resource hostname in the host header?

2

Hi @icsy7867, welcome to the community and to zrok (and OpenZiti)!

I don't think zrok would be able to ever actually support adding that host header on it's own if you are using a single share to access two different services expecting a Host header... It sounds to me like that's the situation? You have two different services behind ONE zrok share? Could you zrok share twice and using the expected hostname for each share? I'm not sure if that would work either tbh, I sort of think it wouldn't, but in a 1:1 share situation, it's conceivable that a feature request to zrok would make sense where you could ask for one or more HTTP headers to be added in that sort of situation.

Alternatively, if you have access to "code" on the client side, you could set the desired host header there and zrok will happily send that along. I tried to lookup CUPS but I don't know what that is and it wasn't an easy thing to find on the internet due to the common name it has...

3

I just learned from @michael.quigley that the caddy backed is already setup for exactly this purpose! :slight_smile:

See:

for example:

    # All other traffic goes to localhost:3000
    reverse_proxy /* 127.0.0.1:3000 {
        header_up Host localhost:3000
        header_up X-Real-IP {http.request.header.x-forwarded-for}                                                          
    }
4

This office hours video demonstrates the feature:

5

But that is only for the frontend correct? So if I am in chrome, and I type:
https://l0f6zodvldyp.zrok.domain.com into my browser, this will hit Caddy, and then redirect to the ZROK frontend, and preserves:
https://l0f6zodvldyp.zrok.domain.com/ in the host header as Caddy sends the incoming request to the zrok frontend. I dont think that would preserve my "localhost" once it hits the zrok client running on my mac?

Or am I thinking about the Caddy Proxy additional container here:
https://docs.zrok.io/docs/guides/self-hosting/docker/
Which would be considered a frontend? And there this is another caddy backend I should look at?

6

Incorrect. This sets the Host header for your service so the request appears to be coming from localhost.

This uses Caddy in your zrok share process instead of the plain reverse proxy of the proxy backend.

7

Oh nice, I will look at that... One last, possibly dumb question....

This caddy backend service is the same one listed here?
https://docs.zrok.io/docs/guides/self-hosting/docker/

And is provided with the caddy.compose.override.yml and caddy.Dockerfile?

If so I will see if I can get this working.

8

No. Caddy is used in the Docker configuration primarily as a mechanism to manage TLS.

I'm describing the --backend-mode caddy backend for zrok share. It's there to allow you to aggregate multiple endpoints into a single HTTP share, and do header rewriting and such.

There aren't currently good docs for it. You might just want to give the YouTube video listed above a quick watch, and check out the example configurations:

Once you understand the bind directive:

http:// {
    bind {{ .ZrokBindAddress }}
    # customize reverse_proxy, file_server, etc.
}

...you generally just need to refer to the Caddy docs for details about what you can accomplish.

9

@qrkourier might have more insight with getting this working under Docker.

10

Awesome, this is actually preferred because I have an nginx proxy for my docker containers that handles auto proxying to various containers and SSL.

I will give your youtube video a closer look! Thanks for replying so quickly. You guys are awesome.

1 Like
11

Holy! That worked. SUPER easy. This is awesome! Thank you guys!

3 Likes
12

@michael.quigley @TheLumberjack

This is pretty cool. I took this a step further, and I used caddy to integrate SSO Via our on-prem ADFS with OIDC!

I manually built zrok after adding caddy-security

And then wrote a custom caddy file which you can see in this github issue:

And now, when you hit the zrok generated link, it forces me through my companies SSO/ADFS page! Neat!

1 Like
13

That's amazing to hear, sounds very neat! If you end up blogging about it or posting something on social media let us know so we can get the official OpenZiti account to repost etc :slight_smile:

We really do appreciate you taking the time to give us the good news though, thanks for sharing!

1 Like