Descrição do problema:
Estou tentando configurar a transferência de arquivos entre meu Raspberry Pi e um desktop Ubuntu usando um servidor FastAPI. Aqui está minha configuração:
Configuração do servidor FastAPI :
- FastAPI implantado no desktop Ubuntu.
- O servidor escuta na porta
2121.
Configuração de IP estático :
- Meu ISP me atribuiu o IP estático
172.168.4.50(conforme confirmado pelas configurações do roteador). - Habilitei o encaminhamento de porta no meu roteador para a porta
2121para o IP local do desktop Ubuntu.
- Meu ISP me atribuiu o IP estático
Testando a configuração :
- O servidor FastAPI pode ser acessado localmente (por exemplo,
http://localhost:2121/). - Entretanto, quando tento acessar
http://172.168.4.50:2121/de fora da rede, a solicitação falha.
- O servidor FastAPI pode ser acessado localmente (por exemplo,
Etapas de solução de problemas tomadas :
- Regras de encaminhamento de porta verificadas no roteador.
- Foi verificado se o servidor FastAPI está em execução e escutando na porta correta.
- Acessibilidade testada desabilitando temporariamente o firewall no desktop do Ubuntu.
Preocupação:
Depois de alguma pesquisa, percebi que ele 172.168.4.50se enquadra no intervalo de IP privado ( 172.16.0.0para 172.31.255.255). Pelo que entendi, IPs privados não são roteáveis na internet pública.
Questões:
- É possível que meu ISP tenha fornecido um IP estático privado em vez de um IP estático público?
- Se sim, isso significa que a API não estará acessível pela internet, mesmo com o encaminhamento de porta habilitado?
- Devo pedir ao meu ISP para atribuir um IP estático público?
Detalhes do sistema:
- SO do servidor: Ubuntu Desktop
- IP estático fornecido pelo ISP: 172.168.4.50
- Porta encaminhada: 2121
- FastAPI: servidor de API baseado em Python
Comportamento esperado:
A API deve ser acessível de qualquer lugar usando o IP estático e a porta atribuídos pelo ISP 2121.
Comportamento real:
Solicitações http://172.168.4.50:2121/endpointfalham e atingem o tempo limite, mesmo que o encaminhamento de porta esteja configurado.
De certa forma, sim. Isso é muito comum entre ISPs residenciais (e cada vez mais comum até mesmo para planos empresariais menores), pois os ISPs simplesmente ficam sem endereços IPv4 e não têm como obter mais.
Embora seu ISP tenha usado o intervalo errado (como outros mencionaram, o ISP confundiu dois intervalos de IP privados diferentes, ou talvez tenha digitado incorretamente "172.16" como "172.168", e acabou usando uma parte do espaço de endereço público da Microsoft ), o resultado final é funcionalmente o mesmo: o endereço que você tem não é roteado para você pela Internet e só funciona dentro da rede do ISP.
(Para endereços realmente privados, a Internet não tem nenhuma rota. Para "172.168", a Internet tem uma rota, mas em uma direção completamente diferente – em direção à rede Azure da Microsoft, que legitimamente possui esses endereços – e o resultado final é o mesmo, ou seja, pacotes de outros ISPs não têm chance de chegar até você. Em ambos os casos, seu acesso de saída à Internet só funciona porque o ISP fará SNAT de todos os pacotes para um de seus endereços realmente públicos.)
Sim.
Sim.
Inicialmente, fiquei confuso sobre se o endereço IP atribuído era privado ou público. Após uma investigação mais aprofundada, descobri que o endereço IP é de fato um endereço IP privado. O roteador está usando Carrier-Grade NAT (CGNAT) para fins de roteamento, e é por isso que o endereço IP aparece em um intervalo privado e não é diretamente acessível pela internet.