☰

TL;DR

tag-icon • tag-icon ubuntu networking tcp port-forwarding socket
TL;DR

Estoy ejecutando Ubuntu server 22.04y tengo un problema peculiar de reenvío de puertos con una máquina local. Esta máquina tiene dos interfaces Ethernet y la enp1s0interfaz conectada tiene una dirección IP 192.168.1.50. La configuración IP completa es la siguiente:

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

He configurado reglas de reenvío de puertos para mi enrutador para que todos los paquetes TCP o UDP que lleguen from wan to port 22211seanforwarded to lan 192.168.1.50 port 22211

En mi ufwconfiguración, he permitido el enrutamiento permitido de este puerto:

$ sudo ufw status
[sudo] password for *
Status: active

To                         Action      From
--                         ------      ----
22211/tcp                  ALLOW       Anywhere                  
22211/tcp (v6)             ALLOW       Anywhere (v6)

Ahora, si inicio un socket netcat simple ( nc -l -p 22211) para este puerto, puedo acceder a él telneta través de otra máquina en la red local sin problemas. Aquí está tcudumpel registro cuando hago telnet desde otra máquina local. Me conecto, envío una carta ay presiono 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

Pero cuando intento hacer telnet fuera de mi red local, por alguna razón la conexión nunca se establece. Durante mucho tiempo estuve seguro de que mi configuración de reenvío de puertos estaba desactivada (aunque el mismo enrutador reenvía otros puertos a otra máquina en mi red local sin problemas, y básicamente simplemente reflejé la configuración en otro puerto), pero como puede ver en tcpdumplos registros A continuación, los paquetes llegan a la enp1s0interfaz:

$ 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

También puedo ver que netcat está escuchando todas las interfaces (la 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))

La tabla de enrutamiento se ve así:

$ 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

Entonces no sé por qué los paquetes provenientes de la red externa nunca llegan al socket local en el puerto 22211... ¿Hay alguna configuración de firewall adicional que debo configurar?

Editar: curiosamente, de hecho ping 8.8.8.8se agota el tiempo de espera (mientras que, por ejemplo, ping google.com funciona bien)

Respuesta1

TL;DR

Si algo complicado no funciona, primero asegúrese de que lo básico funcione correctamente.

Versión más larga

Preámbulo

Este es un buen ejemplo de cómo hacer una pregunta.

  1. Hay información básica, por ejemplo, está ejecutando Ubuntu 22.04, la máquina tiene dos interfaces Ethernet.

  2. Se proporciona información detallada, por ejemplo, la información de configuración de IP.

  3. Se muestran ejemplos tanto funcionales como no funcionales.

Depurando el problema.

Corregir malentendidos.

  • El OP declaró: "No sé por qué los paquetes provenientes de la red externa nunca llegan al socket local en el puerto 22211". cuando los datos mostraban que los paquetes estaban llegando, eran las respuestas las que no salían de esa interfaz.

  • El OP dijo que tenía dos interfaces. La información de IP muestra que la segunda interfaz está inactiva, pero ¿tal vez la máquina esperaba enviar la respuesta desde la otra interfaz?

Primera solicitud de más información.

  • "¿La tabla de enrutamiento muestra que la ruta a 126.33.189.168 se realiza a través de la interfaz activa (enp1s0)?" El OP respondió agregando la tabla de enrutamiento y también dijo

  • "Agregué la información de la tabla de enrutamiento al mensaje original. También me aseguré de que la otra interfaz eno1 esté inactiva, pero no parece haber ningún cambio".

Segunda solicitud de más información.

La tabla de enrutamiento tenía nombres simbólicos, en lugar de direcciones numéricas. Sin conocer el mapeo esto no fue muy útil, así que

  • "¿Podría cambiar su edición para mostrar el resultado y sudo route -vnmostrar los valores numéricos, por favor?"

Pregunte las cosas de una manera que sea natural para quien responde.

Un comentario sugirió usar ip routeen lugar de route -vn. Lo he usado ip routedurante años y afirmaría que es una mejor herramienta. La pregunta que hay que hacer es "¿estamos tratando de enseñarle al OP mejores herramientas o estamos tratando de ayudarlo a solucionar su problema?". Creo que sería una distracción empezar a introducir nuevas herramientas.

Segunda solicitud de más información - continuación.

  • "¿Puede confirmar también que puede hacer ping a alguna dirección conocida desde 192.168.1.50, por ejemplo, 8.8.8.8?" Esto provocó la respuesta

  • 'Tienes razón, por alguna razón, ¡el ping 8.8.8.8 se agota! Pero hacer ping a google.com funciona bien."

Depurar por qué ping google.comfunciona

  • "¿Y qué dirección IP elige ping google.com? (Se muestra en la primera línea). Parece que se ha protegido contra IPv4, pero aún tiene IPv6 en pleno funcionamiento".

Yo no usaría el término firewalled. Dado que la tabla de enrutamiento muestra 2 rutas predeterminadas con diferentes métricas, es casi seguro que ahora se trate de un problema de enrutamiento.

Tercera solicitud de más información.

La mayoría de las personas solo tienen una única conexión a Internet, pero trate de no hacer suposiciones injustificadas.

  • "¿Espera tener 2 enrutadores, cada uno de los cuales pueda acceder a Internet (quizás con 2 ISP diferentes)?"

cuando la respuesta fue negativa, solo fue cuestión de decirle al OP que solucionara el problema de enrutamiento (usando el comando con el que estaban más familiarizados) y todo funcionó. Anticipar la respuesta y poner las instrucciones junto con la pregunta ahorra demoras.

  • "Poder hacer ping a 8.8.8.8 es su problema más importante. Resolverlo puede resolverlo todo".

El problema real.

  • cuando los paquetes necesitaban salir a Internet, en lugar de a la red local, se les decía que lo hicieran a través de una máquina inexistente.

  • Para enviar paquetes a esta máquina inexistente, el host enviaba paquetes ARP, que no obtenían respuesta.

  • finalmente, el host dejó de intentar contactar con la máquina inexistente e informó un error en el comando ping, o no envió un acuse de recibo a la conexión entrante.

  • arreglar la tabla de enrutamiento para enviar paquetes destinados a Internet a través de la dirección correcta hizo que todo funcionara.

información relacionada