search

srobo / ansible

Ansible configuration for Student Robotics' pet machines
MIT License
0 stars 4 forks source link

Add SR2023 Helpdesk system to proxy #40

Closed trickeydan closed 1 year ago

trickeydan commented 1 year ago

Summary

Add the helpdesk system for this year's comp to the proxy.

NB: The sign up is still being built. System is MVP currently, we're planning to work on it a bit more before the comp.

Code review

Testing

Links

PeterJCLaw commented 1 year ago

At first glance this looks like it ought to work. The syntax is fine, nginx boots ok and it does try to do the proxy. However it then fails to get a valid connection to the upstream when making requests.

I'm not sure what is going wrong, however I'd guess that something in fly.dev's setup doesn't like this proxying approach.

The errors I'm seeing in a local proxy instance's nginx logs are:

2023/03/18 16:38:16 [error] 36253#36253: *21 connect() to [2a09:8280:1::1:f9fd]:443 failed (101: Network is unreachable) while connecting to upstream, client: 192.168.56.1, server: sr-proxy, request: "GET /helpdesk/ HTTP/2.0", upstream: "https://[2a09:8280:1::1:f9fd]:443/", host: "sr-proxy"
2023/03/18 16:38:16 [error] 36253#36253: *21 peer closed connection in SSL handshake (104: Connection reset by peer) while SSL handshaking to upstream, client: 192.168.56.1, server: sr-proxy, request: "GET /helpdesk/ HTTP/2.0", upstream: "https://66.241.125.155:443/", host: "sr-proxy"

I can reproduce this in curl too:

$ curl "https://66.241.125.155:443/" -H 'Host: srhelpdesk.fly.dev'
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to 66.241.125.155:443

I can however access https://srhelpdesk.fly.dev both in my browser and via curl.

It should be fine to use the /helpdesk/ path for this purpose, so if there's printing you need to do then it should be fine to reference the desired url there. If we can't make the proxy work we can put in a redirect for this year and figure the rest out after the competition.

PeterJCLaw commented 1 year ago

Aha, it looks like SNI is what's causing the issue here. Some searching around led me to https://github.com/fly-apps/nginx/blob/master/nginx.conf which while aimed at hosting Nginx on Fly.io (rather than proxying Fly using Nginx) seemed useful from the perspective of seeing what they would do when proxying. They use proxy_ssl_server_name which I'd not seen before and which it turns out is off by default. Turning on fixes the proxying.

That then exposes that the underlying app doesn't play nicely with subpaths (it issues a redirect to /auth/login, which then 404s), but that's something that would need fixing on the app side.

PeterJCLaw commented 1 year ago

I've tested this and the proxying works. The underlying app still doesn't quite handle the /helpdesk/ sub-path right, but I don't see this as a blocker to this PR -- it can be fixed afterwards easily enough.