search

matrix-org / matrix-federation-tester

Tester for matrix federation written in golang.
78 stars 17 forks source link

.well-known on server_name appears to be insufficent? #60

Closed cyphar closed 5 years ago

cyphar commented 5 years ago

I just set up my own matrix server at cyphar.com, with both of the following delegations set up:

  1. https://cyphar.com/.well-known/matrix/server gives you { "m.server": "matrix.cyphar.com:8448" }.
  2. _matrix._tcp.cyphar.com has a SRV record containing 10 0 8448 matrix.cyphar.com..

However it appears this is not sufficient -- the federation tester gives a notice that well-known isn't in use.

In order to get well-known recognised I have to add https://matrix.cyphar.com/.well-known/matrix/server -- which doesn't make much sense since the whole point of the .well-known setup is that you need it to redirect from the Matrix server name.

Is this caused by me having both methods set up?

richvdh commented 5 years ago

https://cyphar.com/.well-known/matrix/server is a 404 for me

richvdh commented 5 years ago

(this isn't really the right place for support requests: please come to #synapse:matrix.org)

cyphar commented 5 years ago

It isn't a 404:

% curl https://cyphar.com/.well-known/matrix/server
{
    "m.server": "matrix.cyphar.com:8448"
}

This wasn't really a support request -- my understanding of the well-known extension is that https://cyphar.com/.well-known/matrix/server should be enough and thus the federation-tester isn't correctly handling it.

But sure, I'll post something in #synapse:matrix.org.

richvdh commented 5 years ago

ok, it turns out it's only not a 404 on ipv4:

rav@fred:~$ curl -4 https://cyphar.com/.well-known/matrix/server
{
    "m.server": "matrix.cyphar.com:8448"
}
rav@fred:~$ curl -6 https://cyphar.com/.well-known/matrix/server

<html>
  <head><title>404 - No Such Resource</title></head>
  <body>
    <h1>No Such Resource</h1>
    <p>Sorry. No luck finding that resource.</p>
  </body>
</html>
cyphar commented 5 years ago

Thanks, it turns out that was the issue (and due to a variety of things NGINX happened to route IPv6 requests to matrix.cyphar.com since that happened to be the default_server hence my incorrect diagnosis).

It is a bit confusing that .well-known failures happened for both IPv4 and IPv6 -- but that is tracked by #57 AFAICS. Sorry for the line-noise, and thanks. :D

aftab03 commented 4 years ago

Same issue. Cant find out what wrong Can you help out how did you get rid of this issue

cyphar commented 4 years ago

If you're using nginx, you need to have entries like the following in the server {} block for your Matrix server (if your server is reachable by IPv6):

    # Client-Server (client) API (requires matrix.cyphar.com certificate).          
    listen 443 ssl http2;                                                           
    listen [::]:443 ssl http2;                                                      
    # Server-Server (federation) API (requires cyphar.com certificate).             
    listen 8448 ssl http2;                                                          
    listen [::]:8448 ssl http2;

(http2 is optional, the key thing is the listen [::]:... lines which indicate that nginx should handle IPv6 connections to the relevant host using this block. If you don't do this, then the default_server will be used for all IPv6 requests -- hence the 404s.)

If you'd like to see my entire setup, the configurations are available in the srv/ sub-directory of https://github.com/cyphar/cyphar.com (and the nginx configuration can be found here).