Estou executando Ubuntu server 22.04e tenho um problema peculiar de encaminhamento de porta com uma máquina local. Esta máquina possui duas interfaces Ethernet e a enp1s0interface conectada possui um endereço IP 192.168.1.50. A configuração completa do IP é a seguinte:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:e0:4f:68:02:bb brd ff:ff:ff:ff:ff:ff
inet 192.168.1.50/24 metric 100 brd 192.168.1.255 scope global enp1s0
valid_lft forever preferred_lft forever
inet6 240f:74:de92::d1e/128 scope global dynamic noprefixroute
valid_lft 35597sec preferred_lft 35597sec
inet6 fd41:d8b6:99ba::d1e/128 scope global dynamic noprefixroute
valid_lft 35597sec preferred_lft 35597sec
inet6 fd41:d8b6:99ba:0:2e0:4fff:fe68:2bb/64 scope global mngtmpaddr noprefixroute
valid_lft forever preferred_lft forever
inet6 240f:74:de92:0:2e0:4fff:fe68:2bb/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 98462sec preferred_lft 98462sec
inet6 fe80::2e0:4fff:fe68:2bb/64 scope link
valid_lft forever preferred_lft forever
3: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 00:e0:4c:68:01:6e brd ff:ff:ff:ff:ff:ff
altname enp2s0
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:55:86:e6:e5 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
Eu configurei regras de encaminhamento de porta para meu roteador para que quaisquer pacotes TCP ou UDP recebidos from wan to port 22211sejamforwarded to lan 192.168.1.50 port 22211
Na minha ufwconfiguração, permiti o roteamento desta porta:
$ sudo ufw status
[sudo] password for *
Status: active
To Action From
-- ------ ----
22211/tcp ALLOW Anywhere
22211/tcp (v6) ALLOW Anywhere (v6)
Agora, se eu iniciar um soquete netcat simples ( nc -l -p 22211) para esta porta, posso acessá-lo telnetatravés de outra máquina na rede local sem problemas. Aqui está tcudumpo log quando eu faço telnet de outra máquina local. Eu me conecto, envio uma carta ae pressiono enter:
$ sudo tcpdump -pnvvi enp1s0 port 22211
tcpdump: listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:01:48.350024 IP (tos 0x0, ttl 64, id 59572, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.196.38840 > 192.168.1.50.22211: Flags [S], cksum 0x527d (correct), seq 3440167578, win 32120, options [mss 1460,sackOK,TS val 3772353734 ecr 0,nop,wscale 7], length 0
21:01:48.350139 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.50.22211 > 192.168.1.196.38840: Flags [S.], cksum 0x3a60 (correct), seq 495600843, ack 3440167579, win 65160, options [mss 1460,sackOK,TS val 102903428 ecr 3772353734,nop,wscale 7], length 0
21:01:48.351892 IP (tos 0x0, ttl 64, id 59573, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.196.38840 > 192.168.1.50.22211: Flags [.], cksum 0x66b7 (correct), seq 1, ack 1, win 251, options [nop,nop,TS val 3772353737 ecr 102903428], length 0
21:01:50.698846 IP (tos 0x0, ttl 64, id 59574, offset 0, flags [DF], proto TCP (6), length 55)
192.168.1.196.38840 > 192.168.1.50.22211: Flags [P.], cksum 0xf275 (correct), seq 1:4, ack 1, win 251, options [nop,nop,TS val 3772356082 ecr 102903428], length 3
Mas quando tento o formulário telnet fora da minha rede local, por algum motivo a conexão nunca é estabelecida. Por muito tempo eu tive certeza de que minha configuração de encaminhamento de porta estava desativada (embora o mesmo roteador encaminhe outras portas para outra máquina em minha rede local perfeitamente, e eu basicamente apenas espelhei a configuração para outra porta), mas como você pode ver nos tcpdumplogs abaixo, os pacotes chegam à enp1s0interface:
$ sudo tcpdump -pnvvi enp1s0 port 22211
tcpdump: listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:58:05.448829 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x4448 (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560510789 ecr 0,sackOK,eol], length 0
20:58:06.593532 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x405f (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560511790 ecr 0,sackOK,eol], length 0
20:58:07.613818 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x3c76 (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560512791 ecr 0,sackOK,eol], length 0
20:58:08.603603 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x388c (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560513793 ecr 0,sackOK,eol], length 0
20:58:09.563590 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
126.33.109.168.36371 > 192.168.1.50.22211: Flags [S], cksum 0xcd21 (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560514795 ecr 0,sackOK,eol], length 0
Também posso ver que o netcat está ouvindo todas as interfaces (a parte 0.0.0.0):
$ sudo ss -tulpn | grep 22211
tcp LISTEN 0 1 0.0.0.0:22211 0.0.0.0:* users:(("nc",pid=3344,fd=3))
A tabela de roteamento se parece com a seguinte:
$ sudo route -vn
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 enp1s0
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 enp1s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp1s0
192.168.1.1 0.0.0.0 255.255.255.255 UH 100 0 0 enp1s0
Então, estou perdido porque os pacotes vindos de fora da rede nunca alcançam o soquete local na porta 22211... Existe alguma configuração adicional de firewall que devo configurar?
Editar: curiosamente, na verdade ping 8.8.8.8o tempo limite (enquanto, por exemplo, ping google.com funciona bem)
Responder1
DR
Se algo complicado não funcionar, primeiro certifique-se de que o básico esteja funcionando corretamente.
Versão mais longa
Preâmbulo
Este é um bom exemplo de como fazer uma pergunta.
Há informações básicas, por exemplo, está executando o Ubuntu 22.04, a máquina possui duas interfaces Ethernet.
Informações detalhadas, por exemplo, informações de configuração de IP são fornecidas.
São mostrados exemplos funcionais e não funcionais.
Depurando o problema.
Corrigir mal-entendidos.
O OP declarou: "Então, estou perdido porque os pacotes vindos de fora da rede nunca alcançam o soquete local na porta 22211." quando os dados mostravam que os pacotes estavam chegando, eram as respostas que não saíam daquela interface.
O OP disse que tinha duas interfaces. As informações de IP mostram que a segunda interface está inoperante, mas talvez a máquina esperasse enviar a resposta da outra interface?
Primeiro pedido de mais informações.
"A tabela de roteamento mostra que a rota para 126.33.189.168 é através da interface ativa (enp1s0)?" O OP respondeu adicionando a tabela de roteamento e também disse
"Adicionei as informações da tabela de roteamento à mensagem original. Também me certifiquei de que a outra interface eno1 está inativa, mas parece não haver alteração"
Segundo pedido de mais informações.
A tabela de roteamento continha nomes simbólicos, em vez de endereços numéricos. Sem conhecer o mapeamento isso não foi muito útil, então
- "Você poderia alterar sua edição para mostrar a saída
sudo route -vnpara mostrar os valores numéricos, por favor?"
Pergunte as coisas de uma forma que seja natural para quem responde.
Um comentário sugeriu usar ip routeem vez de route -vn. Eu uso ip routehá anos e diria que é uma ferramenta melhor. A pergunta a ser feita é "estamos tentando ensinar melhores ferramentas ao OP ou estamos tentando ajudá-lo a resolver seu problema?". Acho que seria uma distração começar a introduzir novas ferramentas.
Segundo pedido de mais informações – continuação.
"Você também pode confirmar se pode executar ping em algum endereço conhecido de 192.168.1.50, por exemplo, 8.8.8.8?" Isto suscitou a resposta
'Você está certo, por algum motivo o ping 8.8.8.8 atingiu o tempo limite! Mas o ping google.com funciona bem."
Depurar por que ping google.comfunciona
- "E qual endereço IP o ping google.com escolhe? (É mostrado na primeira linha.) Parece que você se protegeu do IPv4, mas ainda tem o IPv6 totalmente funcional."
Eu não usaria o termo firewalled. Com a tabela de roteamento mostrando duas rotas padrão com métricas diferentes, isso era quase certamente um problema de roteamento.
Terceiro pedido de mais informações.
A maioria das pessoas tem apenas uma conexão com a Internet, mas tente não fazer suposições injustificadas.
- "Você espera ter 2 roteadores, cada um deles capaz de acessar a Internet (talvez com 2 ISPs diferentes)?"
quando a resposta foi negativa, foi apenas uma questão de dizer ao OP para corrigir o problema de roteamento (usando o comando com o qual eles estavam familiarizados) e tudo está funcionando. Antecipar a resposta e incluir as instruções junto com a pergunta evita atrasos.
- "Ser capaz de executar ping em 8.8.8.8 é o seu problema mais importante. Resolver isso pode muito bem resolver tudo."
O problema real.
quando os pacotes precisam sair para a Internet, em vez de para a rede local, eles foram instruídos a passar por uma máquina inexistente.
Para enviar pacotes para esta máquina inexistente o host estava enviando pacotes ARP, que não estavam obtendo resposta.
eventualmente, o host desistiu de tentar entrar em contato com a máquina inexistente e relatou um erro ao comando ping ou não enviou uma confirmação para a conexão de entrada.
consertar a tabela de roteamento para enviar pacotes destinados à internet pelo endereço correto fez tudo funcionar.