search

deltachat / chatmail

chatmail service deployment scripts and docs
https://delta.chat/en/2023-12-13-chatmail
MIT License
134 stars 13 forks source link

cmdeploy issues in a NAT'd environment #414

Open feld opened 1 month ago

feld commented 1 month ago

I stumbled upon this while trying to deploy to a fresh Debian Bookworm VM behind NAT last night and had to work around it. This scenario breaks some assumptions that are built into chatmail:

If you try to deploy in a NAT'd environment where the hostname of the server is a private/internal hostname and not the same as the A/AAAA record and you'll find cmdeploy uses the chatmail.ini value for mail_domain, so you have to override that in a ~/.ssh/config so it will connect to the right place.

After you've overcome that hurdle, the next issue is that acmetool appears to have some built-in sanity checks to make sure it's reachable before attempting to issue the certificate, so it tries to reach http://`mail_domain`:80. This will fail because of hairpin routing (request hits your firewall/router and has to come right back out the same interface) which is generally denied for security reasons. You can fix this by adding an entry to your /etc/hosts file to declare your mail_domain is reachable at 127.0.0.1

At this point I can confirm that 80, 443, and all the IMAP/SMTP ports are open to the public internet. However, acmetool keeps failing to issue a certificate and I don't know why. I didn't capture those logs (sorry, it was very late and I just wanted this to work), but it was the typical failed-HTTP-validation scenario. I was looking in /run/acme/acme-challenge and nothing ever showed up in there, so I'm not surprised the validation was failing. Very strange all around.

I worked around this by disabling acmetool during deployment and using my own automation with Chef to deploy my certificate to the same location acmetool was going to use.

The chatmail cmdeploy could use some work to allow providing your own certificates and to not make some of these assumptions, or at least permit overriding what you're connecting to for deployment.

hpk42 commented 2 days ago

There is #439 which introduced an ssh-option. this simplifies the first problem, right?

hpk42 commented 2 days ago

could you maybe close this issue here and make a new one if needed, and also provide more information so we can work on a fix, addressing it?