Recebendo timeout ao tentar criar certificado, existe um bloqueio de IP?

Help Ajuda (em português)
1

Por favor, preencha todos os campos abaixo para que nós possamos ajudar você. Obs.: você deve indicar seu nome de domínio para receber ajuda. Os nomes de domínio dos certificados emitidos são divulgados nos logs da Transparência de Certificados (por exemplo, crt.sh | example.com). Assim, não indicar seu nome de domínio não o mantém em segredo, mas torna a nossa ajuda mais difícil.

Posso ler respostas em inglês:
Sim.

Meu nome de domínio é:
shipay.com.br

Executei esse comando:
PING
CURL

Produziu essa saída:

root@nginx-57999549f8-79b9d:/# ping acme-v02.api.letsencrypt.org
PING ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com (172.65.32.248) 56(84) bytes of data.

--- ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 50ms

###############################################################################
root@nginx-57999549f8-79b9d:/# ping acme-staging-v02.api.letsencrypt.org
PING 56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com (172.65.46.172) 56(84) bytes of data.

--- 56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 75ms

###############################################################################

root@nginx-57999549f8-79b9d:/# curl -v https://acme-v02.api.letsencrypt.org/directory

  • Expire in 0 ms for 6 (transfer 0x5af44e01afb0)
  • Expire in 1 ms for 1 (transfer 0x5af44e01afb0)
  • Expire in 0 ms for 1 (transfer 0x5af44e01afb0)
  • Expire in 1 ms for 1 (transfer 0x5af44e01afb0)
  • Expire in 0 ms for 1 (transfer 0x5af44e01afb0)
  • Expire in 0 ms for 1 (transfer 0x5af44e01afb0)
  • Expire in 1 ms for 1 (transfer 0x5af44e01afb0)
  • Expire in 0 ms for 1 (transfer 0x5af44e01afb0)
  • Expire in 0 ms for 1 (transfer 0x5af44e01afb0)
  • Expire in 1 ms for 1 (transfer 0x5af44e01afb0)
  • Expire in 0 ms for 1 (transfer 0x5af44e01afb0)

Meu servidor web é (com versão):
Ambassador 2.0

O sistema operacional no meu servidor web é (com versão):
Linux

O serviço de hospedagem do meu site (se aplicável) é:

Posso acessar um shell root na minha máquina (sim ou não, ou não sei):
Sim.

Uso um painel de controle para administrar meu site (não, ou indique o nome e a versão do painel de controle): Uso Kubernetes, então meu API Gateway hoje está rodando em um pod dentro do meu cluster, uso também o cert-manager para criar o certificado no Let's Encrypt, porém depois de uma atualização no cluster aonde o cert-manager reiniciou várias vezes, comecei a tomar timeout. Gostaria de saber se pode acontecer e quando acontece como resolvo?

2

Olá @iagogfn, bem-vindo à comunidade Let's Encrypt. :slightly_smiling_face:

Tente sudo traceroute -T -p 443 acme-v02.api.letsencrypt.org e compartilhe a saída.

1 Like
3

Bruce, Obrigado!

Segue abaixo o commando traceroute que me pediu.

root@nginx-57999549f8-79b9d:/# traceroute -T -p 443 acme-v02.api.letsencrypt.org
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 60 byte packets
1 10.64.16.1 (10.64.16.1) 0.038 ms 0.012 ms 0.010 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

4

What output do you get with just a normal traceroute acme-v02.api.letsencrypt.org?

1 Like
5

10.64.16.1 não é um endereço de Internet roteável.

1 Like
6

That's fine if it's OPs router, my first hop on a traceroute is also my router with a private IP address. It just means OP is behind NAT. (Possibly CG-NAT, but that should currently not be an issue.)

1 Like
7

Correct; NAT (most likely) or not they didn't get past the first hop.

8

I believe my outgoing IP is blocked.

root@nginx-57999549f8-79b9d:/# traceroute acme-v02.api.letsencrypt.org
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 60 byte packets
1 10.64.16.1 (10.64.16.1) 0.022 ms 0.012 ms 0.010 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

9

Is there any way to find out if my IP is blocked?

10

I would expect to see making to the IPv4 Address of 3.236.205.174, but that is not happening.

$ nslookup shipay.com.br ns-1068.awsdns-05.org.
Server:         ns-1068.awsdns-05.org.
Address:        205.251.196.44#53

Name:   shipay.com.br
Address: 3.236.205.174
1 Like
11

This is my traceroute with and without -T -p 443:

osiris@erazer ~ $ sudo traceroute -T -p 443 acme-v02.api.letsencrypt.org
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  172.65.32.248 (172.65.32.248)  14.766 ms  9.645 ms  9.598 ms
osiris@erazer ~ $ sudo traceroute acme-v02.api.letsencrypt.org
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 60 byte packets
 1  192.168.2.1 (192.168.2.1)  1.416 ms  1.394 ms  1.383 ms
 2  lo0-2.bras2.fi007.example.com (x.x.x.x)  10.451 ms  10.440 ms  12.170 ms
 3  connected.by.example.com (x.x.x.x)  12.160 ms  13.566 ms  13.898 ms
 4  as13335.frys-ix.net (x.x.x.x)  16.520 ms  16.862 ms  16.500 ms
 5  172.71.180.2 (172.71.180.2)  15.362 ms 172.71.100.2 (172.71.100.2)  28.052 ms  28.357 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  *^C
osiris@erazer ~ $

As you can see the -T -p 443 does get a response by the destination server, but not from the hops in between. Perhaps due to my routers firewall blocking the return ICMP packets, I dunno. But the traceroute without -T -p 443 does show the hops in between. It's just that the destination server doesn't reply to those requests.. So I'd always advise to use both traceroutes if one doesn't provide an immediate answer.

I would not. I also don't see my public IP address in any traceroute. The NAT router replies with its (private) LAN IP address, not with its (public) WAN IP address, as the origin of the traceroute is from inside the LAN. It wouldn't make sense to reply with the WAN address.

Well, not by Let's Encrypt/Cloudflare anyway, as it looks like the requests for 172.65.32.248 don't even leave your or your ISPs network?

Can you ping the API hostname? Can you traceroute and ping 172.64.32.88? (Which is one of Cloudflares DNS servers from the same IP range as the API.)

3 Likes
12

Then try ping google.com

13

@Osiris , I just ran the ping and traceroute for cloudflare's DNS and I took a timeout, I went to search the internet and cloudflared's firewall also uses fail2ban, this guy checks the authentication attempts and if you exceed the limit your IP is blocked on firewall, I believe this happened to my IP.

root@nginx-57999549f8-79b9d:/# ping 172.64.32.88
PING 172.64.32.88 (172.64.32.88) 56(84) bytes of data.
^C
--- 172.64.32.88 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 59ms

root@nginx-57999549f8-79b9d:/# traceroute 172.64.32.88
traceroute to 172.64.32.88 (172.64.32.88), 30 hops max, 60 byte packets
1 10.64.16.1 (10.64.16.1) 0.040 ms 0.024 ms 0.010 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

@Bruce5051,You will not receive a return IP as I use AWS Cloudfront on this domain. Here's the test you asked me to do.

root@nginx-57999549f8-79b9d:/# ping google.com
PING google.com (172.217.28.14) 56(84) bytes of data.
64 bytes from eze03s15-in-f14.1e100.net (172.217.28.14): icmp_seq=1 ttl=121 time=1.38 ms
64 bytes from eze03s15-in-f14.1e100.net (172.217.28.14): icmp_seq=2 ttl=121 time=1.03 ms
64 bytes from eze03s15-in-f14.1e100.net (172.217.28.14): icmp_seq=3 ttl=121 time=1.03 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 1.025/1.145/1.382/0.171 ms

14

That would indicate to me that your outgoing IP is not blocked; at least for some destinations.

1 Like
15

I highly doubt that, Cloudflare is a gigantic CDN, it probably won't run something relatively simple as fail2ban.

I think your router or ISP somehow blocks access to the (tested) Cloudflare IP addresses, as otherwise I would have expected more hops visible in the traceroutes.

1 Like
16

Sounds like a routing misconfiguration:
172.16.0.0/12 being entered as 172.0.0.0/8 [OR something like that]

3 Likes
17

@Bruce5051
Got it, I ruled out the possibility that it was a problem with my gateway output because my cluster in production uses this same output, I have several applications that make external queries and they did not present a problem, even the cert-manager was working, it stopped after we forced updates several times .

2 Likes
18

Updates of what?

19

However you did make to the destination.

20

@rg305, I managed to solve it. in my case there was a route that took this IP range (172.65.0.0/16) from cloudflare, so when trying to reach the acme-v02.api.letsencrypt.org address, the packet was forwarded internally within the network, instead of to go to the egress gateway to the internet.

Thank you all.

4 Likes