search

YunoHost / issues

General issue tracker for the YunoHost project
72 stars 8 forks source link

YunoHost constantly fails to renew MUC subdomain #2175

Closed csolisr closed 1 year ago

csolisr commented 1 year ago

Describe the bug

YunoHost keeps attempting to renew muc.maindomain.tld (a fixed subdomain generated by YNH to manage MUC in XMPP) and keeps failing to do so in a daily basis.

Context

To reproduce

  1. Create a domain (for the purposes of this bug we'll call it maindomain.tld)
  2. Add a Let's Encrypt certificate to that domain
  3. (Optional) Add a subdomain and a certificate for that subdomain
  4. Wait for the scheduled certificate renovation script to run

Expected behavior

The scheduled task should run without issues, and properly detect that muc.maindomain.tld is a subdomain of maindomain.tld specifically intended for XMPP MUC.

Logs

args:
  email: true
  force: false
  no_checks: false
ended_at: 2023-03-13 14:00:12.104739
error: Certificate renewing for maindomain.tld failed!
interface: cli
operation: letsencrypt_cert_renew
parent: null
related_to:
- - domain
  - maindomain.tld
started_at: 2023-03-13 13:59:34.561036
success: false
yunohost_version: 11.1.15

============

2023-03-13 07:59:34,573: DEBUG - Making sure tmp folders exists...
2023-03-13 07:59:34,587: DEBUG - Fetching IP from https://ip.yunohost.org 
2023-03-13 07:59:35,496: DEBUG - IP fetched: xx.xx.xx.xx
2023-03-13 07:59:35,513: DEBUG - Fetching IP from https://ip6.yunohost.org 
2023-03-13 08:00:05,728: DEBUG - Could not get public IPv6 : URL inválida https://ip6.yunohost.org (¿Existe este sitio?).
2023-03-13 08:00:05,728: DEBUG - IP fetched: None
2023-03-13 08:00:05,740: DEBUG - Prepare key and certificate signing request (CSR) for maindomain.tld...
2023-03-13 08:00:06,293: DEBUG - Saving to /tmp/acme-challenge-private/maindomain.tld.csr.
2023-03-13 08:00:06,293: DEBUG - Now using ACME Tiny to sign the certificate...
2023-03-13 08:00:06,294: INFO - Parsing account key...
2023-03-13 08:00:06,307: INFO - Parsing CSR...
2023-03-13 08:00:06,316: INFO - Found domains: muc.maindomain.tld, xmpp-upload.maindomain.tld, maindomain.tld
2023-03-13 08:00:06,316: INFO - Getting directory...
2023-03-13 08:00:06,870: INFO - Directory found!
2023-03-13 08:00:06,870: INFO - Registering account...
2023-03-13 08:00:07,567: INFO - Already registered!
2023-03-13 08:00:07,568: INFO - Creating new order...
2023-03-13 08:00:08,322: INFO - Order created!
2023-03-13 08:00:09,029: INFO - Verifying maindomain.tld...
2023-03-13 08:00:10,671: INFO - maindomain.tld verified!
2023-03-13 08:00:11,722: INFO - Verifying muc.maindomain.tld...
2023-03-13 08:00:12,100: ERROR - Wrote file to /tmp/acme-challenge-public/YOdKlDZ50HxV-NuVgZQmtnYJvPcVlR4gmAqJWtNWOEg, but couldn't download http://muc.maindomain.tld/.well-known/acme-challenge/YOdKlDZ50HxV-NuVgZQmtnYJvPcVlR4gmAqJWtNWOEg: Error:
Url: http://muc.maindomain.tld/.well-known/acme-challenge/YOdKlDZ50HxV-NuVgZQmtnYJvPcVlR4gmAqJWtNWOEg
Data: None
Response Code: None
Response: <urlopen error [Errno 111] Connection refused>
2023-03-13 08:00:12,104: ERROR - Certificate renewing for maindomain.tld failed!
alexAubin commented 1 year ago

The scheduled task should run without issues, and properly detect that muc.maindomain.tld is a subdomain of maindomain.tld specifically intended for XMPP MUC.

Yes that's already what YunoHost does ...

Can you confirm that yunohost tools regen-conf nginx doesn't complain about a manually modified file about the domain.tld ?

Server is hosted behind NAT, uses WireGuard to connect to an internet-facing VPS

Could it be that you configured some reverse-proxying for domain.tld but not for muc.domain.tld nor xmpp-upload.domain.tld ...

csolisr commented 1 year ago

The regen-conf nginx command didn't output anything, so I suppose it's already correct. The WireGuard reverse proxy is configured per port and not per domain - any new domain I add is correctly funneled to my home server as long as I add any ports required to the WireGuard configuration. The only variant I have is that I need to configure specific ports to NOT tunnel through WireGuard to account for the server being behind NAT: Jellyfin (1900, 7359), UnifiedPush (5000), Jitsi (4443, 10000), and Synapse Coturn (5349-5351, 49153-49193).

alexAubin commented 1 year ago

In that case idk, this could be some combination of funky DNS + network config such as, for example, domain.tld being resolved to the proper IP, but muc.domain.tld being resolved to a different IP (maybe 127.0.0.1) such that the connection is "refused" because of some firewall or routing ..

I guess you can investigate running curl domain.tld and curl muc.domain.tld with some debug option and check which IP is used etc...

csolisr commented 1 year ago

It might be related to the fact that my router is configured to directly point the DNS to my home server instead of to the external VPS proxy, but the configuration must be done per domain and subdomain. For instance, the main domain correctly points to localhost:

curl -v maindomain.tld
*   Trying ::1:80...
* Connected to maindomain.tld (::1) port 80 (#0)
> GET / HTTP/1.1
> Host: maindomain.tld
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Mon, 13 Mar 2023 17:19:55 GMT
< Content-Type: text/html
< Content-Length: 162
< Connection: keep-alive
< Location: https://maindomain.tld/
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host maindomain.tld left intact

But muc.maindomain.tld does try to resolve to the external VPS:

curl -v muc.maindomain.tld
*   Trying XXX.XXX.XXX.XXX:80...
* connect to XXX.XXX.XXX.XXX port 80 failed: Connection refused
* Failed to connect to muc.maindomain.tld port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to muc.maindomain.tld port 80: Connection refused
alexAubin commented 1 year ago

And doesn't your external VPS accept connections on port 80 ?

csolisr commented 1 year ago

Of course my VPS accepts connections on port 80 - that's how it tunnels all HTTP(S) traffic back to my device.

alexAubin commented 1 year ago

Well idk to me it sounds like a TCP-layer issue ... Maybe your server banned your home IP somehow, idk ...

What if you try to run curl -v domain.tld --resolve domain.tld:80:XXX.XXX.XXX.XXX (with XXX.XXX... being your VPS IP)

Or also nc -zv XXX.XXX.XXX.XXX 80

csolisr commented 1 year ago 
curl -v maindomain.tld --resolve maindomain.tld:80:XXX.XXX.XXX.XXX
* Added maindomain.tld:80:XXX.XXX.XXX.XXX to DNS cache
* Hostname maindomain.tld was found in DNS cache
*   Trying XXX.XXX.XXX.XXX:80...
* connect to XXX.XXX.XXX.XXX port 80 failed: Connection refused
* Failed to connect to maindomain.tld port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to maindomain.tld port 80: Connection refused
alexAubin commented 1 year ago

Yeah so idk your VPS somehow blocks traffic from your home server ...

csolisr commented 1 year ago

All ports except for port 22 (SSH) are being blocked.

nc -zv XXX.XXX.XXX.XXX 80
nc: connect to XXX.XXX.XXX.XXX port 80 (tcp) failed: Connection refused
nc -zv XXX.XXX.XXX.XXX 22
Connection to XXX.XXX.XXX.XXX 22 port [tcp/ssh] succeeded!
csolisr commented 1 year ago

My VPS has the following IPTables set on Wireguard:

iptables -A FORWARD -i wg0 -j ACCEPT;
iptables -t nat -A POSTROUTING -o ens18 -j MASQUERADE;
#VPN
iptables -t nat -A POSTROUTING -s 10.7.0.3 -o ens18 -j MASQUERADE;
iptables -t nat -A POSTROUTING -s 10.7.0.4 -o ens18 -j MASQUERADE;
# icmp
iptables -A INPUT -p icmp -j ACCEPT;
# Routing TCP port 25 and 587 from Yunohost Server to internet
for j in 25 587
do
        iptables -t nat -A POSTROUTING -s 10.7.0.2 -p tcp --dport $j -j SNAT --to XXX.XXX.XXX.XXX;
        iptables -A FORWARD -s 10.7.0.2 -p tcp --dport $j -j ACCEPT;
done

# Routing TCP port required from VPN server to Yunohost server
for i in 25 53 80 443 587 993 1935 2222 5222 5269 5353 7359 8090 8448 9002 9003 9004 9005 1900 5349 5350 7359
do
        iptables -t nat -A PREROUTING -i ens18 -p tcp --dport $i -j DNAT --to-destination 10.7.0.2;
        iptables -A FORWARD -d 10.7.0.2 -p tcp --dport $i -j ACCEPT;
done

# Routing TCP directly for Matrix/Synapse/Coturn/Jellyfin
for port in udp tcp
do
        for i in 5000 4443 10000 5351 #1900 5349 5350 7359
        do
                iptables -A FORWARD -s 10.7.0.2 -p $port --dport $i -j ACCEPT;
                iptables -A FORWARD -d 10.7.0.2 -p $port --dport $i -j ACCEPT;
                iptables -t nat -A PREROUTING -i ens18 -p $port --dport $i -j DNAT --to-destination 10.7.0.2;
                iptables -t nat -A POSTROUTING -s 10.7.0.2 -p $port --dport $i -j SNAT --to XXX.XXX.XXX.XXX;
        done

        iptables -A FORWARD -s 10.7.0.2 -p $port --dport 49153:49193 -j ACCEPT;
        iptables -A FORWARD -d 10.7.0.2 -p $port --dport 49153:49193 -j ACCEPT;
        iptables -t nat -A PREROUTING -i ens18 -p $port --dport 49153:49193 -j DNAT --to-destination 10.7.0.2;
        iptables -t nat -A POSTROUTING -s 10.7.0.2 -p $port --dport 49153:49193 -j SNAT --to XXX.XXX.XXX.XXX;
done
alexAubin commented 1 year ago

This is your VPS dude, I'm not gonna retroengineer your iptables rules, this ain't a YunoHost issue ...

csolisr commented 1 year ago

Any way to bypass it in the meanwhile? Besides of deleting the entire VPS?

alexAubin commented 1 year ago

I guess you can add 127.0.0.1 muc.domain.tld in your /etc/hosts on YunoHost and same for xmpp-upload ... Or disable XMPP if you don't use it ...

alexAubin commented 1 year ago

Closing assuming the issue is fixed and the cause doesn't seem to be YunoHost ...