Hi there!
I’m trying to follow the guide here
Most of the things described work well. However when I run
zrok access private token --headless --bind 0.0.0.0:11434
[ 1.994] INFO main.(*accessPrivateCommand).accessLocal: access the zrok share at the following endpoint: tcp://0.0.0.0:11434
[ 12.040] INFO main.(*accessPrivateCommand).accessLocal: ***.***.9.4:3837 -> ACCEPT token
it seems zrok automatically binds to ipv6 address, which is a) not what I want b) is not accessible on that VM instance anyway
ubuntu@instance-**-**:~$ ss -lntp -6 | grep 11434
LISTEN 0 4096 *:11434 : users (("zrok",pid=1135,fd=6))
ubuntu@instance-**-**:~$ ss -lntp -4 | grep 11434
I can’t access the service on port 11434 from outside the VM. And when I try to access it from the same machine with curl, it works if I use localhost, but does not work when I use 0.0.0.0.
I tried to debug it for a few hours by googling and chatgpting, however I’m at my wits end here. I’m not very proficient in cloud compute, since I work mostly with embedded systems. Would appreciate any help!
The address 0.0.0.0 means “all interfaces”, so that might very well be picking up any provisioned ipv6 addresses on the machine.
Maybe I’m missing something in what you’ve posted… but why not just --bind 127.0.0.1:11434 instead of 0.0.0.0? That would specifically bind the zrok access listener to localhost on ipv4?
Yes, it works and I’ve tried that before. But I think this will make it inaccessible outside of VM?
My end goal is to share 11434 publicly, as per document I shared.
PS: I have set bearer token auth on that port with caddy, so I’m okay with it being public.
If you want it accessible outside of the VM, you will need to bind it to the IP address you want it to listen on? You would --bind the zrok access private to whatever IP address you want to receive traffic from.
zrok access private is designed to listen on an IP address and route traffic to a zrok share. Is this what you’re trying to accomplish?
About a year ago, I wondered whether it is possible to explicitly specify an IPv6 address when configuring the listener—perhaps using bracket notation. Does Ziti 1.6.x support binding to a specific IPv6 address? I was unable to configure it this way; Ziti either binds to everything or to a specified IPv4 address.
Additionally, the documentation says that the Ziti router supports UDP and DTLS. Does zrok 1.1.2 support UDP edge routers?
Also, could you clarify what other protocols zrok supports?
Also make sure that the firewall on your VM allows inbound access to port 11434… that could also prevent traffic from reaching zrok access private.
I also tried that, but without any success:
ubuntu@instance-***-***:~$ zrok access private token --headless --bind public.ip.address.fromconsole:11434
[ 3.107] INFO main.(*accessPrivateCommand).accessLocal: access the zrok share at the following endpoint: tcp://public.ip.address.fromconsole:11434
[ 3.107] INFO main.(*accessPrivateCommand).shutdown: shutting down 'token'
[ERROR]: unable to create private access (error listening at '141.144.248.225:11434': listen tcp public.ip.address.fromconsole:11434: bind: cannot assign requested address)
And about firewall, I’m 95% sure I got it configured right:
sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
11434/tcp ALLOW IN Anywhere
22/tcp ALLOW IN Anywhere
11434/tcp (v6) ALLOW IN Anywhere (v6)
22/tcp (v6) ALLOW IN Anywhere (v6)
that’s on the machine side. and then in console
This is the problem:
(error listening at '141.144.248.225:11434': listen tcp public.ip.address.fromconsole:11434: bind: cannot assign requested address)
If you run the ip addr command on your system, what does the output show? Usually most VMs in the cloud use a private IP address that ultimately maps to the public IP address assigned to the instance. You will need to bind on that address, most likely.
It’s also possible that your cloud VM isn’t set up properly to expose a public IP address.
Okay, looks like it was just a whole bunch of red herrings. After doing more debugging I found out it was my faulty Caddyfile that was causing the issue.
I’ll try my best to document the process and post here as well for completeness, there was a lot of gotchas along the way, but it now seems to be working (publicly accessible Ollama with token auth).
1 Like
Sweet. Glad you got it worked out!
I use this same approach in my infrastructure. It works great once you get the recipe sorted out.
