Since yesterday, from a very specific subnet, the script constantly fails in random locations (where curl happens), with urlopen error [Errno 104] Connection reset by peer.
The servers I have problem from fall into the 78.108.34.* range.
Sometimes I reproduce this with plain curl as well:
# connection fail:
$ curl https://acme-v02.api.letsencrypt.org/acme/new-order
curl: (35) gnutls_handshake() failed: Error in the pull function.
# connection success (the "malformed" is just an expected API response):
$ curl https://acme-v02.api.letsencrypt.org/acme/new-order
{
"type": "urn:ietf:params:acme:error:malformed",
"detail": "Method not allowed",
"status": 405
Servers which I manage in Hetzner do not have this issue.
Is there a possibility that the problematic range has been blocked or throttled from letsencrypt for some reason?
Sorry in case the pasted block confused you. I’ve edited my question with clarifying that the second curl is successful (it’s just the expected API response).
Yes, connectivity via curl works, just not all of the times. The issue is that it now constantly fails via the https://github.com/diafygi/acme-tiny I use.
[just as a "test" : not permanently : 1400-1460 should be fine]
[continued success via lower MTU would prove there exist some problematic device(s) along the path]
I’ve lowered with ifconfig ens3 mtu 1400 and confirmed with ip addr | grep mtu. I tried 1300 and 1400 and, again, it fails with urlopen error [Errno 104] Connection reset by peer in random places (once in https://acme-v02.api.letsencrypt.org/acme/new-nonce and the second time in https://acme-v02.api.letsencrypt.org/directory).
$ sudo traceroute -I --mtu acme-v02.api.letsencrypt.org
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 65000 byte packets
1 ... (...) 0.622 ms F=1500 0.519 ms 0.414 ms
2 ... (...) 0.631 ms 0.592 ms 0.560 ms
3 100.64.11.165 (100.64.11.165) 0.703 ms 0.696 ms 0.663 ms
4 100.64.11.54 (100.64.11.54) 1.328 ms 1.067 ms 1.234 ms
5 cloudflare.bnix.net (194.53.172.66) 2.184 ms 2.071 ms 2.014 ms
6 172.65.32.248 (172.65.32.248) 0.861 ms 0.898 ms 1.013 ms
$ sudo traceroute -I --mtu acme-v02.api.letsencrypt.org
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 65000 byte packets
1 static.....clients.your-server.de (...) 0.125 ms F=1500 0.040 ms 0.039 ms
2 static.....clients.your-server.de (...) 1.598 ms 0.297 ms 0.273 ms
3 core24.fsn1.hetzner.com (213.239.203.193) 2.918 ms 3.344 ms 5.528 ms
4 core1.fra.hetzner.com (213.239.229.77) 4.868 ms 4.877 ms 5.308 ms
5 core9.fra.hetzner.com (213.239.224.174) 17.095 ms 5.139 ms 5.078 ms
6 162.158.84.254 (162.158.84.254) 13.691 ms 13.105 ms 13.388 ms
7 172.65.32.248 (172.65.32.248) 5.138 ms 5.107 ms 5.123 ms
From non working location:
$ sudo traceroute -I --mtu acme-v02.api.letsencrypt.org
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 65000 byte packets
1 ... (...) 0.628 ms F=1500 1.077 ms 0.671 ms
2 ... (...) 7.558 ms 7.573 ms 8.401 ms
3 cloudflare.thess.gr-ix.gr (185.1.123.10) 15.576 ms 10.323 ms 13.406 ms
4 172.65.32.248 (172.65.32.248) 8.345 ms 8.320 ms 8.358 ms
Could you paste the full output of curl -vvv 'https://acme-v02.api.letsencrypt.org/directory' when it fails, please? There may be too many connections from the mentioned IP range 78.108.34.0/24 and Cloudflare may rate-limit the (not necessarily letsencrypt related) inbound connenctions. You want to check the general health of that network.
* Trying 172.65.32.248...
* Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 596 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* gnutls_handshake() failed: Error in the pull function.
* Closing connection 0
curl: (35) gnutls_handshake() failed: Error in the pull function.