Wau how easy it was to register to #cloudflare, create tunnel and expose a service from home kube to internet. My ISP seems to block neighbour to neighbour traffic. This hop via cf resolves it nicely! Well productized service.
Edit: There was a solution. Also turned out cloudflared is MITM with https.
Damned, I failed with the cloudflare tunnel after switching to https service. If I run the service in kube with the public tls certs, cloudflared fails to trust it due that local url doesn't match the public one. Well of course not. How to make it trust it? Can I somehow give it the cert so it won't mind the cert doesn't match the kube hostmame?
#cloudflare
@watchfulcitizen@goingdark.social whoa, you have taken extra steps to docunent it. I'll take a look. In meanwhile I found out last night I can set domain name matching the original cert in tunnel serrings, which removes the problem. Then I learned tunneld is actually mitm. I wasted time setting letsencrypt certs with cert-manager to my apache pod, as cloudflare does re-encrypt the traffic in the middle. I don't know if this can be avoided.
@ikkeT@mementomori.social Yeah I've gone way overboard with my #homelab lol. My own #instance runs there too, tuned for ~1000 users but it's just me + 5 others.
Strict mode in #Cloudflare just means they’ll validate the cert from my end when connecting origin > edge, so the second TLS leg is trusted/encrypted. But with Tunnel, the first leg still terminates at Cloudflare. Both hops are encrypted, but Cloudflare’s in the middle by design. Only #DNS only or Spectrum gives true end-to-end.
Ilkka Tengvall