Aquí está el problema que estoy tratando de resolver. Hay un servidor ("sistema remoto") en el que puedo ingresar desde mi computadora local, pero este sistema remoto no tiene conexión a Internet. Quiero proporcionar al sistema remoto acceso a Internet a través de mi computadora local utilizando una VPN basada en ssh. ¿Cómo logro esto? He intentado lo siguiente, que parece funcionar parcialmente. Lo que quiero decir con "trabajo parcial" es que los paquetes de conexión (paquetes de sincronización) se envían a mi computadora local pero no pueden establecer la conexión a Internet. Estoy usando tcpdump para capturar paquetes en la computadora local. La computadora local y el sistema remoto están ejecutando centos 7.
La configuración - Nota: los comandos a continuación se ejecutan en orden. Los comandos user @ remote se ejecutan en el servidor remoto y los comandos user @ local se ejecutan en la computadora local.
[usuario @ remoto ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state DESCONOCIDO
enlace / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 ámbito host lo
válido_lft para siempre preferido_lft para siempre
inet6 :: host de alcance 1/128
válido_lft para siempre preferido_lft para siempre
2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
enlace / éter AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 alcance global dinámico eth0
valid_lft 1785sec preferred_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 alcance global noprefixroute dinámico
valid_lft 2591987sec preferred_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: enlace de alcance LLLL / 64
válido_lft para siempre preferido_lft para siempre
[usuario @ local ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state DESCONOCIDO
enlace / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 ámbito host lo
válido_lft para siempre preferido_lft para siempre
inet6 :: host de alcance 1/128
válido_lft para siempre preferido_lft para siempre
2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
enlace / éter AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 alcance global dinámico eth0
valid_lft 1785sec preferred_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 alcance global noprefixroute dinámico
valid_lft 2591987sec preferred_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: enlace de alcance LLLL / 64
válido_lft para siempre preferido_lft para siempre
Cree la interfaz tun0 en el sistema remoto .
[usuario @ remoto ~] $ sudo ip tuntap agregar tun0 mode tun
[usuario @ remoto ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state DESCONOCIDO
enlace / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 ámbito host lo
válido_lft para siempre preferido_lft para siempre
inet6 :: host de alcance 1/128
válido_lft para siempre preferido_lft para siempre
2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
enlace / éter AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 alcance global dinámico eth0
valid_lft 1785sec preferred_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 alcance global noprefixroute dinámico
valid_lft 2591987sec preferred_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: enlace de alcance LLLL / 64
válido_lft para siempre preferido_lft para siempre
3: tun0: mtu 1500 qdisc noop state DOWN qlen 500
enlace / ninguno
Cree la interfaz tun0 en el sistema local .
[usuario @ local ~] $ sudo ip tuntap agregar tun0 mode tun
[usuario @ local ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state DESCONOCIDO
enlace / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 ámbito host lo
válido_lft para siempre preferido_lft para siempre
inet6 :: host de alcance 1/128
válido_lft para siempre preferido_lft para siempre
2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
enlace / éter AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 alcance global dinámico eth0
valid_lft 1785sec preferred_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 alcance global noprefixroute dinámico
valid_lft 2591987sec preferred_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: enlace de alcance LLLL / 64
válido_lft para siempre preferido_lft para siempre
3: tun0: mtu 1500 qdisc noop state DOWN qlen 500
enlace / ninguno
Asigne una dirección IP a tun0 y tráigalo
[usuario @ local ~] $ sudo ip addr add 10.0.2.1/30 dev tun0
[user @ local ~] $ sudo ip link set dev tun0 up
[usuario @ local ~] $ ip addr show tun0
3: tun0: mtu 1500 qdisc pfifo_fast estado ABAJO qlen 500
enlace / ninguno
inet 10.0.2.1/30 alcance global tun0
válido_lft para siempre preferido_lft para siempre
[usuario @ remoto ~] $ sudo ip addr add 10.0.2.2/30 dev tun0
[user @ remote ~] $ sudo ip link set dev tun0 up
[usuario @ remoto ~] $ ip addr show tun0
3: tun0: mtu 1500 qdisc pfifo_fast estado ABAJO qlen 500
enlace / ninguno
inet 10.0.2.2/30 alcance global tun0
válido_lft para siempre preferido_lft para siempre
Modifique sshd_config en los sistemas remotos y locales para habilitar la tunelización:
[usuario @ remoto ~] $ sudo grep PermitTunnel / etc / ssh / sshd_config PermitTunnel punto a punto
[usuario @ local ~] $ sudo grep PermitTunnel / etc / ssh / sshd_config PermitTunnel punto a punto
Crea el túnel ssh:
[usuario @ local ~] $ sudo ssh -f -w0: 0 root @ remote true contraseña de root @ remote: [usuario @ local ~] $ ps aux | grep root @ remote raíz 1851 0.0 0.0 76112 1348? Ss 23:12 0:00 ssh -f -w0: 0 root @ remote true
Pruebe el ping en ambos servidores utilizando las nuevas direcciones IP:
[usuario @ local ~] $ ping 10.0.2.2 -c 2 PING 10.0.2.2 (10.0.2.2) 56 (84) bytes de datos. 64 bytes de 10.0.2.2: icmp_seq = 1 ttl = 64 tiempo = 1.68 ms 64 bytes de 10.0.2.2: icmp_seq = 2 ttl = 64 tiempo = 0.861 ms --- 10.0.2.2 estadísticas de ping --- 2 paquetes transmitidos, 2 recibidos, 0% de pérdida de paquetes, tiempo 1002 ms rtt min / avg / max / mdev = 0.861 / 1.274 / 1.688 / 0.415 ms
[usuario @ remoto ~] $ ping 10.0.2.1 -c 2 PING 10.0.2.1 (10.0.2.1) 56 (84) bytes de datos. 64 bytes de 10.0.2.1: icmp_seq = 1 ttl = 64 tiempo = 0.589 ms 64 bytes de 10.0.2.1: icmp_seq = 2 ttl = 64 tiempo = 0.889 ms --- 10.0.2.1 estadísticas de ping --- 2 paquetes transmitidos, 2 recibidos, 0% de pérdida de paquetes, tiempo 1000ms rtt min / avg / max / mdev = 0.589 / 0.739 / 0.889 / 0.150 ms
[usuario @ remoto ~] $ ruta Tabla de enrutamiento IP del núcleo Destination Gateway Genmask Flags Referencia métrica Uso Iface puerta de enlace predeterminada 0.0.0.0 UG 100 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.252 U 0 0 0 tun0 AAA.BBB.CCC.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0 [usuario @ remoto ~] $ ip route show predeterminado a través de AAA.BBB.CCC.1 dev eth0 proto static metric 100 10.0.2.0/30 dev tun0 proto kernel scope link src 10.0.2.2 AAA.BBB.CCC.0 / 24 dev eth0 proto kernel scope link src AAA.BBB.CCC.31 métrica 100
Obtenga direcciones ip de google:
[usuario @ local ~] $ nslookup google.com Servidor: servidor Dirección: servidor # 53 Respuesta no autorizada: Nombre: google.com Dirección: 173.194.219.101 Nombre: google.com Dirección: 173.194.219.100 Nombre: google.com Dirección: 173.194.219.113 Nombre: google.com Dirección: 173.194.219.102 Nombre: google.com Dirección: 173.194.219.139 Nombre: google.com Dirección: 173.194.219.138
IMPORTANTE: ejecuté el comando anterior en un momento diferente y obtuve un resultado diferente. No asuma que su respuesta será la misma que la mía para nslookup anterior.
Como todas las direcciones IP de Google comienzan con 173.194.219, enrutemos todas estas direcciones IP a través de la computadora local.
[user @ remote ~] $ sudo ip route add 173.194.219.0/24 dev tun0 [usuario @ remoto ~] $ ruta Tabla de enrutamiento IP del núcleo Destination Gateway Genmask Flags Referencia métrica Uso Iface puerta de enlace predeterminada 0.0.0.0 UG 100 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.252 U 0 0 0 tun0 AAA.BBB.CCC.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0 173.194.219.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 [usuario @ remoto ~] $ ip route show predeterminado a través de AAA.BBB.CCC.1 dev eth0 proto static metric 100 10.0.2.0/30 dev tun0 proto kernel scope link src 10.0.2.2 AAA.BBB.CCC.0 / 24 dev eth0 proto kernel scope link src AAA.BBB.CCC.31 métrica 100 173.194.219.0/24 dev tun0 alcance enlace
Habilitar ip_forwarding:
[usuario @ local ~] $ grep ip_forward /etc/sysctl.conf net.ipv4.ip_forward = 1 [usuario @ local ~] reinicio de red del servicio $ sudo Reinicio de la red (a través de systemctl): [OK]
Configure la captura de paquetes en la computadora local usando tcpdump:
[usuario @ local ~] $ sudo tcpdump -nn -vv 'puerto no 22' -i cualquiera tcpdump: escucha en cualquier, tipo de enlace LINUX_SLL (Linux cocinado), tamaño de captura 65535 bytes
Intente conectarse a google desde el servidor remoto.
[usuario @ remoto ~] $ openssl s_client -connect google.com:443 zócalo: no hay ruta al host conectar: errno = 113
Tan pronto como se ejecuta el comando openssl en el servidor remoto, el tcpdump captura algunos paquetes:
10.0.2.2.52768> 173.194.219.102.443: Banderas [S], cksum 0x8702 (correcto), seq 994650730, win 29200, opciones [mss 1460, sackOK, TS val 7701438 ecr 0, nop, wscale 7], longitud 0
00: 49: 33.247753 IP (tos 0x0, ttl 64, id 46037, offset 0, banderas [DF], proto TCP (6), longitud 60)
10.0.2.2.48774> 173.194.219.100.443: Flags [S], cksum 0x47a7 (correcto), seq 2218733674, win 29200, opciones [mss 1460, sackOK, TS val 7701439 ecr 0, nop, wscale 7], longitud 0
00: 49: 33.247883 IP (tos 0xc0, ttl 64, id 9538, offset 0, flags [none], proto ICMP (1), longitud 88)
10.0.2.1> 10.0.2.2: host ICMP 173.194.219.100 inalcanzable - administrador prohibido, longitud 68
IP (tos 0x0, ttl 63, id 46037, offset 0, banderas [DF], proto TCP (6), longitud 60)
10.0.2.2.48774> 173.194.219.100.443: Flags [S], cksum 0x47a7 (correcto), seq 2218733674, win 29200, opciones [mss 1460, sackOK, TS val 7701439 ecr 0, nop, wscale 7], longitud 0
00: 49: 33.253068 IP (tos 0x0, ttl 64, id 26282, offset 0, banderas [DF], proto TCP (6), longitud 60)
10.0.2.2.51312> 173.194.219.101.443: Flags [S], cksum 0x6ff8 (correcto), seq 2634016105, win 29200, opciones [mss 1460, sackOK, TS val 7701443 ecr 0, nop, wscale 7], longitud 0
00: 49: 33.254771 IP (tos 0xc0, ttl 64, id 9539, offset 0, flags [none], proto ICMP (1), longitud 88)
10.0.2.1> 10.0.2.2: host ICMP 173.194.219.101 inalcanzable - administrador prohibido, longitud 68
IP (tos 0x0, ttl 63, id 26282, desplazamiento 0, banderas [DF], proto TCP (6), longitud 60)
10.0.2.2.51312> 173.194.219.101.443: Flags [S], cksum 0x6ff8 (correcto), seq 2634016105, win 29200, opciones [mss 1460, sackOK, TS val 7701443 ecr 0, nop, wscale 7], longitud 0
00: 49: 33.258805 IP (tos 0x0, ttl 64, id 9293, offset 0, flags [DF], proto TCP (6), longitud 60)
10.0.2.2.33686> 173.194.219.139.443: Banderas [S], cksum 0x542b (correcto), seq 995927943, win 29200, opciones [mss 1460, sackOK, TS val 7701450 ecr 0, nop, wscale 7], longitud 0
00: 49: 33.258845 IP (tos 0xc0, ttl 64, id 9540, offset 0, flags [none], proto ICMP (1), longitud 88)
10.0.2.1> 10.0.2.2: host ICMP 173.194.219.139 inalcanzable - administrador prohibido, longitud 68
IP (tos 0x0, ttl 63, id 9293, desplazamiento 0, banderas [DF], proto TCP (6), longitud 60)
10.0.2.2.33686> 173.194.219.139.443: Banderas [S], cksum 0x542b (correcto), seq 995927943, win 29200, opciones [mss 1460, sackOK, TS val 7701450 ecr 0, nop, wscale 7], longitud 0
^ C
13 paquetes capturados
13 paquetes recibidos por filtro
0 paquetes descartados por el núcleo
Los paquetes capturados con tcpdump sugieren que se intenta establecer la conexión (se envían paquetes de sincronización) pero no se recibe nada. También hay un mensaje 10.0.2.1 > 10.0.2.2: ICMP host 173.194.219.139 unreachable - admin prohibited, length 68que parece sugerir un problema.
¿Alguna sugerencia sobre cómo solucionar este problema? ¿Hay reglas iptable que deben agregarse? Cualquier problema de firewall (firewall-d?).
Nota # 1
Salida de iptables-save:
[usuario @ local ~] $ sudo iptables -t nat -A POSTROUTING -s 10.0.2.2/32! -d 10.0.2.1/30 -j MASQUERADA -o eth0 [usuario @ local ~] $ sudo iptables-save # Generado por iptables-save v1.4.21 el sábado 15 de abril 01:40:57 2017 * nat : ACEPTACIÓN DE PREROUTING [35: 8926] : ACEPTACIÓN DE ENTRADA [1:84] : ACEPTACIÓN DE SALIDA [6: 439] : ACEPTACIÓN POSTROUTING [6: 439] : OUTPUT_direct - [0: 0] : POSTROUTING_ZONES - [0: 0] : POSTROUTING_ZONES_SOURCE - [0: 0] : POSTROUTING_direct - [0: 0] : POST_public - [0: 0] : POST_public_allow - [0: 0] : POST_public_deny - [0: 0] : POST_public_log - [0: 0] : PREROUTING_ZONES - [0: 0] : PREROUTING_ZONES_SOURCE - [0: 0] : PREROUTING_direct - [0: 0] : PRE_public - [0: 0] : PRE_public_allow - [0: 0] : PRE_public_deny - [0: 0] : PRE_public_log - [0: 0] -A PREROUTING -j PREROUTING_direct -A PREROUTING -j PREROUTING_ZONES_SOURCE -A PREROUTING -j PREROUTING_ZONES -A OUTPUT -j OUTPUT_direct -A POSTROUTING -j POSTROUTING_direct -A POSTROUTING -j POSTROUTING_ZONES_SOURCE -A POSTROUTING -j POSTROUTING_ZONES -A POSTROUTING -s 10.0.2.2/32! -d 10.0.2.0/30 -j MASQUERADA -A POSTROUTING_ZONES -o eth0 -g POST_public -A POSTROUTING_ZONES -g POST_public -A POST_public -j POST_public_log -A POST_public -j POST_public_deny -A POST_public -j POST_public_allow -A ZONAS DE PREROUTING -i eth0 -g PRE_public -A PREROUTING_ZONES -g PRE_public -A PRE_public -j PRE_public_log -A PRE_public -j PRE_public_deny -A PRE_public -j PRE_public_allow COMETER # Completado el sáb 15 abr 01:40:57 2017 # Generado por iptables-save v1.4.21 el sábado 15 de abril 01:40:57 2017 *mutilar : ACEPTACIÓN DE PREROUTING [169: 18687] : ACEPTACIÓN DE ENTRADA [144: 11583] : ADELANTE ADELANTE [0: 0] : ACEPTACIÓN DE SALIDA [80: 8149] : ACEPTACIÓN POSTROUTING [80: 8149] : FORWARD_direct - [0: 0] : INPUT_direct - [0: 0] : OUTPUT_direct - [0: 0] : POSTROUTING_direct - [0: 0] : PREROUTING_ZONES - [0: 0] : PREROUTING_ZONES_SOURCE - [0: 0] : PREROUTING_direct - [0: 0] : PRE_public - [0: 0] : PRE_public_allow - [0: 0] : PRE_public_deny - [0: 0] : PRE_public_log - [0: 0] -A PREROUTING -j PREROUTING_direct -A PREROUTING -j PREROUTING_ZONES_SOURCE -A PREROUTING -j PREROUTING_ZONES -A INPUT -j INPUT_direct -A FORWARD -j FORWARD_direct -A OUTPUT -j OUTPUT_direct -A POSTROUTING -j POSTROUTING_direct -A ZONAS DE PREROUTING -i eth0 -g PRE_public -A PREROUTING_ZONES -g PRE_public -A PRE_public -j PRE_public_log -A PRE_public -j PRE_public_deny -A PRE_public -j PRE_public_allow COMETER # Completado el sáb 15 abr 01:40:57 2017 # Generado por iptables-save v1.4.21 el sábado 15 de abril 01:40:57 2017 *seguridad : ACEPTACIÓN DE ENTRADA [2197: 163931] : ADELANTE ADELANTE [0: 0] : ACEPTACIÓN DE SALIDA [1229: 185742] : FORWARD_direct - [0: 0] : INPUT_direct - [0: 0] : OUTPUT_direct - [0: 0] -A INPUT -j INPUT_direct -A FORWARD -j FORWARD_direct -A OUTPUT -j OUTPUT_direct COMETER # Completado el sáb 15 abr 01:40:57 2017 # Generado por iptables-save v1.4.21 el sábado 15 de abril 01:40:57 2017 *crudo : ACEPTACIÓN DE PREROUTING [2362: 184437] : ACEPTACIÓN DE SALIDA [1229: 185742] : OUTPUT_direct - [0: 0] : PREROUTING_direct - [0: 0] -A PREROUTING -j PREROUTING_direct -A OUTPUT -j OUTPUT_direct COMETER # Completado el sáb 15 abr 01:40:57 2017 # Generado por iptables-save v1.4.21 el sábado 15 de abril 01:40:57 2017 *filtrar : ACEPTACIÓN DE ENTRADA [0: 0] : ADELANTE ADELANTE [0: 0] : ACEPTACIÓN DE SALIDA [80: 8149] : FORWARD_IN_ZONES - [0: 0] : FORWARD_IN_ZONES_SOURCE - [0: 0] : FORWARD_OUT_ZONES - [0: 0] : FORWARD_OUT_ZONES_SOURCE - [0: 0] : FORWARD_direct - [0: 0] : FWDI_public - [0: 0] : FWDI_public_allow - [0: 0] : FWDI_public_deny - [0: 0] : FWDI_public_log - [0: 0] : FWDO_public - [0: 0] : FWDO_public_allow - [0: 0] : FWDO_public_deny - [0: 0] : FWDO_public_log - [0: 0] : INPUT_ZONES - [0: 0] : INPUT_ZONES_SOURCE - [0: 0] : INPUT_direct - [0: 0] : IN_public - [0: 0] : IN_public_allow - [0: 0] : IN_public_deny - [0: 0] : IN_public_log - [0: 0] : OUTPUT_direct - [0: 0] -A ENTRADA -m conntrack --ctstate RELACIONADO, ESTABLECIDO -j ACEPTAR -A ENTRADA -i lo -j ACEPTAR -A INPUT -j INPUT_direct -A INPUT -j INPUT_ZONES_SOURCE -A INPUT -j INPUT_ZONES -A INPUT -m conntrack --ctstate INVALID -j DROP -A ENTRADA -j RECHAZO --rechazo-con icmp-host-prohibido -A HACIA ADELANTE -m conntrack --ctstate RELACIONADO, ESTABLECIDO -j ACEPTAR -A ADELANTE -i lo -j ACEPTAR -A FORWARD -j FORWARD_direct -A FORWARD -j FORWARD_IN_ZONES_SOURCE -A FORWARD -j FORWARD_IN_ZONES -A FORWARD -j FORWARD_OUT_ZONES_SOURCE -A FORWARD -j FORWARD_OUT_ZONES -A ADELANTE -m conntrack --ctstate NO VÁLIDO -j DROP -A ADELANTE -j RECHAZO --rechazo-con icmp-host-prohibido -A OUTPUT -j OUTPUT_direct -A FORWARD_IN_ZONES -i eth0 -g FWDI_public -A FORWARD_IN_ZONES -g FWDI_public -A FORWARD_OUT_ZONES -o eth0 -g FWDO_public -A FORWARD_OUT_ZONES -g FWDO_public -A FWDI_public -j FWDI_public_log -A FWDI_public -j FWDI_public_deny -A FWDI_public -j FWDI_public_allow -A FWDI_public -p icmp -j ACEPTAR -A FWDO_public -j FWDO_public_log -A FWDO_public -j FWDO_public_deny -A FWDO_public -j FWDO_public_allow -A ZONAS DE ENTRADA -i eth0 -g IN_public -A INPUT_ZONES -g IN_public -A IN_public -j IN_public_log -A IN_public -j IN_public_deny -A IN_public -j IN_public_allow -A IN_public -p icmp -j ACCEPT -A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NUEVO -j ACCEPT COMETER # Completado el sáb 15 abr 01:40:57 2017
Nota # 2:
configuré un servidor web Apache en un host separado al que solo el servidor local tiene acceso. Ejecuté tcpdump en el servidor web escuchando en el puerto 80. Cuando ejecuto
telnet webserver 80capturo los siguientes paquetes. Este es el comportamiento esperado ya que se establece la conexión TCP (S, S-Ack, Ack).
[usuario @ servidor web ~] $ sudo tcpdump -nn -vv 'puerto no 22 y 80' -i eth0
tcpdump: escucha en eth0, tipo de enlace EN10MB (Ethernet), tamaño de captura 65535 bytes
07: 17: 30.411474 IP (tos 0x10, ttl 64, id 34376, offset 0, banderas [DF], proto TCP (6), longitud 60)
local.server.46710> web.server.80: Flags [S], cksum 0x8412 (incorrecto -> 0x6d96), seq 3018586542, win 29200, opciones [mss 1460, sackOK, TS val 3047398 ecr 0, nop, wscale 7] , longitud 0
07: 17: 30.411557 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), longitud 60)
web.server.80> local.server.46710: Flags [S.], cksum 0x8412 (incorrecto -> 0x9114), seq 2651711943, ack 3018586543, win 28960, opciones [mss 1460, sackOK, TS val 37704524 ecr 3047398, nop , escala 7], longitud 0
07: 17: 30.411725 IP (tos 0x10, ttl 64, id 34377, offset 0, banderas [DF], proto TCP (6), longitud 52)
local.server.46710> web.server.80: Flags [.], cksum 0x840a (incorrecto -> 0x301c), seq 1, ack 1, win 229, opciones [nop, nop, TS val 3047398 ecr 37704524], longitud 0
Cuando intento conectarme al servidor web desde el servidor remoto a través del servidor local, tcpdump en el servidor web no captura ningún paquete (ni siquiera la sincronización inicial), pero el servidor local captura el paquete de sincronización que se envía al servidor web (ver más abajo). Esto me hace creer que algo impide que los paquetes se envíen al servidor web, tal vez una configuración incorrecta o un firewall.
[usuario @ local ~] $ sudo tcpdump -nn -vv 'puerto no 22 y 80' -i cualquiera
tcpdump: escucha en cualquier, tipo de enlace LINUX_SLL (Linux cocinado), tamaño de captura 65535 bytes
02: 24: 09.135842 IP (tos 0x10, ttl 64, id 38062, offset 0, banderas [DF], proto TCP (6), longitud 60)
10.0.2.2.50558> web.server.80: Banderas [S], cksum 0x668d (correcto), seq 69756226, win 29200, opciones [mss 1460, sackOK, TS val 4780524 ecr 0, nop, wscale 7], longitud 0
IMPORTANTE: los paquetes no se enrutan a través de eth0, sino que se intenta enviar los paquetes al servidor web a través de tun0 (que falla). Puedo confirmar esto ejecutando tcpdump en la interfaz tun0:
[usuario @ local ~] $ sudo tcpdump -nn -vv 'puerto no 22 y 80' -i tun0
tcpdump: escucha en tun0, tipo de enlace RAW (Raw IP), tamaño de captura 65535 bytes
02: 28: 10.295972 IP (tos 0x10, ttl 64, id 46976, offset 0, flags [DF], proto TCP (6), longitud 60)
10.0.2.2.50560> servidor web.80: Banderas [S], cksum 0xd560 (correcto), seq 605366388, win 29200, opciones [mss 1460, sackOK, TS val 5021684 ecr 0, nop, wscale 7], longitud 0
Nota # 3:
Apagué firewalld en la computadora local y el servidor web recibió los paquetes de sincronización.
[usuario @ local ~] $ sudo systemctl stop firewalld
[usuario @ servidor web ~] $ sudo tcpdump -nn -vv 'puerto no 22 y 80' -i eth0
tcpdump: escucha en eth0, tipo de enlace EN10MB (Ethernet), tamaño de captura 65535 bytes
08: 25: 17.390912 IP (tos 0x10, ttl 63, id 61767, offset 0, banderas [DF], proto TCP (6), longitud 60)
10.0.2.2.50580> web.server.80: Banderas [S], cksum 0x30dc (correcto), seq 2601927549, win 29200, opciones [mss 1460, sackOK, TS val 7123514 ecr 0, nop, wscale 7], longitud 0
08: 25: 17.391003 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), longitud 60)
web.server.80> 10.0.2.2.50580: Flags [S.], cksum 0x4e23 (incorrecto -> 0xa316), seq 959115533, ack 2601927550, win 28960, opciones [mss 1460, sackOK, TS val 41771503 ecr 7123514, nop , escala 7], longitud 0
08: 25: 17.391192 IP (tos 0x0, ttl 128, id 60032, offset 0, flags [none], proto TCP (6), longitud 40)
10.0.2.2.50580> web.server.80: Flags [R], cksum 0x7339 (correcto), seq 2601927550, win 8192, longitud 0
08: 25: 18.393794 IP (tos 0x10, ttl 63, id 61768, offset 0, banderas [DF], proto TCP (6), longitud 60)
10.0.2.2.50580> web.server.80: Flags [S], cksum 0x2cf1 (correcto), seq 2601927549, win 29200, opciones [mss 1460, sackOK, TS val 7124517 ecr 0, nop, wscale 7], longitud 0
08: 25: 18.393898 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), longitud 60)
web.server.80> 10.0.2.2.50580: Flags [S.], cksum 0x4e23 (incorrecto -> 0x7e71), seq 974785773, ack 2601927550, win 28960, opciones [mss 1460, sackOK, TS val 41772506 ecr 7124517, nop , escala 7], longitud 0
08: 25: 18.394003 IP (tos 0x0, ttl 128, id 60033, offset 0, flags [none], proto TCP (6), longitud 40)
10.0.2.2.50580> web.server.80: Flags [R], cksum 0x566a (correcto), seq 2601927550, win 8192, longitud 0
Ahora claramente, la IP de origen debe actualizarse para que coincida con la dirección IP del servidor local antes de que el paquete se envíe al servidor web. Como sugirió @xin, NAT debe configurarse en el servidor local.
Nota # 4:
Una vez que intento conectarme con el servidor web, puedo ver que el conteo de pkts para la regla 9 aumenta en 1 (como se ve a continuación).
[usuario @ local ~] $ sudo iptables -nvL --line-numbers .......... Chain FORWARD (política ACEPTAR 0 paquetes, 0 bytes) num pkts bytes objetivo prot opt opt out destino de origen 1 0 0 ACEPTAR todo - * * 0.0.0.0/0 0.0.0.0/0 ctstate RELACIONADO, ESTABLECIDO 2 0 0 ACEPTAR todo - lo * 0.0.0.0/0 0.0.0.0/0 3 1 60 FORWARD_direct all - * * 0.0.0.0/0 0.0.0.0/0 4 1 60 FORWARD_IN_ZONES_SOURCE all - * * 0.0.0.0/0 0.0.0.0/0 5 1 60 FORWARD_IN_ZONES all - * * 0.0.0.0/0 0.0.0.0/0 6 1 60 FORWARD_OUT_ZONES_SOURCE all - * * 0.0.0.0/0 0.0.0.0/0 7 1 60 FORWARD_OUT_ZONES all - * * 0.0.0.0/0 0.0.0.0/0 8 0 0 DROP all - * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID 9 1 60 RECHAZAR todo - * * 0.0.0.0/0 0.0.0.0/0 rechazar con icmp-host-prohibido .......... [usuario @ local ~] $ sudo iptables -D ADELANTE 9
Una vez que se elimina la regla 9 de la cadena FORWARD (desde arriba, como sugirió @xin), puedo conectarme al servidor web.
[usuario @ local ~] $ sudo iptables -nvL --line-numbers .......... Cadena HACIA ADELANTE (política ACEPTA 1 paquetes, 60 bytes) num pkts bytes objetivo prot opt opt out destino de origen 1 12 5857 ACEPTAR todo - * * 0.0.0.0/0 0.0.0.0/0 ctstate RELACIONADO, ESTABLECIDO 2 0 0 ACEPTAR todo - lo * 0.0.0.0/0 0.0.0.0/0 3 2 120 FORWARD_direct all - * * 0.0.0.0/0 0.0.0.0/0 4 2 120 FORWARD_IN_ZONES_SOURCE all - * * 0.0.0.0/0 0.0.0.0/0 5 2120 FORWARD_IN_ZONES all - * * 0.0.0.0/0 0.0.0.0/0 6 2120 FORWARD_OUT_ZONES_SOURCE all - * * 0.0.0.0/0 0.0.0.0/0 7 2120 FORWARD_OUT_ZONES all - * * 0.0.0.0/0 0.0.0.0/0 8 0 0 DROP all - * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID ..........