Las reglas de iptables no funcionan para permitir una IP específica

Question 1

Si está utilizando un cliente VPN en este host para crear la segunda interfaz, no olvide tambiénpermitir conexiones al servidor VPN10.147.18.192; de lo contrario, ya no será posible acceder a su IP local .

Deberá permitir al menos el tráfico entrante y saliente hacia/desde el servidor VPN en la interfaz wlp0s20f3:

iptables -I OUTPUT -d $vpn_server_ip -p $proto --dport $vpn_port -j ACCEPT
iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

$proto será udpo tcp, y $vpn_server_ip: $vpn_portla dirección IP o rango y puerto de los servidores VPN

No puedo ayudar mucho a adivinar estos valores, pero su documentación de VPN o tcpdump/wireguard con una conexión establecida y funcional al túnel VPN deberían brindarle esta información.

Answer

Si está utilizando un cliente VPN en este host para crear la segunda interfaz, no olvide tambiénpermitir conexiones al servidor VPN10.147.18.192; de lo contrario, ya no será posible acceder a su IP local .

Deberá permitir al menos el tráfico entrante y saliente hacia/desde el servidor VPN en la interfaz wlp0s20f3:

iptables -I OUTPUT -d $vpn_server_ip -p $proto --dport $vpn_port -j ACCEPT
iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

$proto será udpo tcp, y $vpn_server_ip: $vpn_portla dirección IP o rango y puerto de los servidores VPN

No puedo ayudar mucho a adivinar estos valores, pero su documentación de VPN o tcpdump/wireguard con una conexión establecida y funcional al túnel VPN deberían brindarle esta información.

Question 2

Estos dos comandos que mencionas en tu pregunta:

iptables -A INPUT -s 10.147.18.80 -j ACCEPT
iptables -A OUTPUT -d 10.147.18.80 -j ACCEPT

Añaden esas reglas al final de las cadenas. -ALa opción agrega la regla al final. Si usa -Ila opción, pondrá la regla en la parte superior de la cadena.

El problema aquí es que probablemente ya tenga una regla DROPo REJECT, antes de la ACCEPTregla en una de las cadenas, que elimina el tráfico antes de que llegue al final de la cadena. Como, por ejemplo, una regla que reduce el tráfico hacia o desde una subred completa que contiene la IP 10.147.18.80.

Si tiene una regla en una cadena que descarta/rechaza el tráfico a esa IP, o desde esa IP, dependiendo de si es una cadena de ENTRADA o SALIDA, antes de la regla ACEPTAR, entonces, si la regla especifica solo esa IP o toda la subred, el tráfico se elimina y todas las demás reglas de la cadena ya no se procesan.

DROP, REJECT, ACCEPTson objetivos finales, una vez que iptables coincide con esa regla, deja de procesar otras reglas en la cadena y no pasa a la siguiente regla.

Intentar

iptables -I INPUT -s 10.147.18.80 -j ACCEPT
iptables -I OUTPUT -d 10.147.18.80 -j ACCEPT

Esto colocará esas reglas en la parte superior de las cadenas, de modo que sean las primeras reglas en ser alcanzadas, y luego no se procesarán otras reglas para ese tráfico en esas cadenas.

Puedes enumerar todas las reglas en una cadena con algo como

iptables -nvL

o si quieres ver solo cadenas específicas

iptables -nvL INPUT 
iptables -nvL OUTPUT

EDITAR

Dado el resultado que pegó y el hecho de que puede hacer ping si cambia las acciones predeterminadas a ACCEPTesto, no parece ser el problema.

Puede usar algo como tcpdump para ver si el tráfico va y se devuelve.

Un comando como este le proporcionará todos los paquetes icmp que envía o recibe la máquina

tcpdump -nnvvi any icmp

Si obtienes algo como esto en la salida

10:13:48.866598 IP (tos 0x0, ttl 255, id 30625, offset 0, flags [DF], proto ICMP (1), length 84)
    10.147.18.192 > 10.147.18.80: ICMP echo request, id 26621, seq 4, length 64
10:13:48.867771 IP (tos 0x0, ttl 53, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    10.147.18.80 > 10.147.18.192: ICMP echo reply, id 26621, seq 4, length 64

Luego, sus paquetes de ping se envían y devuelven, pero alguna otra regla los rechaza.

Puede verificar si tal vez tenga otras reglas en otras tablas como nat o mingle table, si tal vez algunas de las reglas allí estén en conflicto con el tráfico.

iptables -t nat -nvL
iptables -t mingle -nvL

También puede ver si los paquetes pasan por la regla ACEPTAR en la cadena de SALIDA mediante el número que aparece a continuación pktsen el listado. Si ese número aumenta después de intentar hacer ping, pero el número en la cadena INPUT permanece en 0, entonces el problema está en las reglas de tráfico entrante.

También verifique sus rutas, con ip run comando o algo similar, si tal vez el tráfico no sale a través de la interfaz en la misma subred, por lo que la IP de origen de los paquetes que devuelven puede cambiar debido a algunas reglas NAT en el camino.

Answer