regras de iptables não funcionam para permitir um IP específico

Question 1

Se você estiver usando um cliente VPN neste host para criar a segunda interface, não se esqueça de tambémpermitir conexões com o servidor VPN, caso contrário, seu IP local 10.147.18.192não estará mais acessível.

Você precisará permitir pelo menos o tráfego de entrada e saída de/para o servidor VPN na interface 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á udpou tcp, e $vpn_server_ip: $vpn_porto endereço IP ou intervalo e porta do(s) servidor(es) VPN

Não posso ajudar muito em adivinhar esses valores, mas sua documentação da VPN ou tcpdump/wireguard com uma conexão estabelecida e funcional ao túnel VPN deve fornecer essas informações.

Answer

Se você estiver usando um cliente VPN neste host para criar a segunda interface, não se esqueça de tambémpermitir conexões com o servidor VPN, caso contrário, seu IP local 10.147.18.192não estará mais acessível.

Você precisará permitir pelo menos o tráfego de entrada e saída de/para o servidor VPN na interface 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á udpou tcp, e $vpn_server_ip: $vpn_porto endereço IP ou intervalo e porta do(s) servidor(es) VPN

Não posso ajudar muito em adivinhar esses valores, mas sua documentação da VPN ou tcpdump/wireguard com uma conexão estabelecida e funcional ao túnel VPN deve fornecer essas informações.

Question 2

Esses dois comandos que você menciona na sua pergunta:

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

Eles anexam essas regras ao final das cadeias. -Aopção anexa a regra ao final. Se você usar -Ia opção, colocará a regra no topo da cadeia.

A questão aqui é que você provavelmente já possui uma regra DROPou REJECT, antes da ACCEPTregra em uma das cadeias que interrompe o tráfego antes que ele chegue ao final da cadeia. Como, por exemplo, uma regra que descarta o tráfego de ou para uma sub-rede inteira que contém o IP 10.147.18.80.

Se você tiver uma regra em uma cadeia que descarta/rejeita o tráfego para esse IP, ou desse IP, dependendo se for uma cadeia INPUT ou OUTPUT, antes da regra ACCEPT, então se a regra especifica apenas esse IP ou toda a sub-rede, o tráfego é descartado e todas as outras regras da cadeia não são mais processadas.

DROP, REJECT, ACCEPTsão destinos finais, uma vez que o iptables corresponde a essa regra, ele para de processar outras regras na cadeia e não prossegue para a próxima regra.

Tentar

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

Isso colocará essas regras no topo das cadeias para que sejam as primeiras regras a serem atingidas, e outras regras não serão processadas para o tráfego nessas cadeias.

Você pode listar todas as regras em uma cadeia com algo como

iptables -nvL

ou se você quiser ver apenas cadeias específicas

iptables -nvL INPUT 
iptables -nvL OUTPUT

EDITAR

Dada a saída que você colou e o fato de você poder executar ping se alterar as ações padrão para ACCEPTisso, não parece ser o problema.

Você pode usar algo como tcpdump para ver se o tráfego está indo e sendo retornado.

Comando como este fornecerá todos os pacotes icmp enviados ou recebidos pela máquina

tcpdump -nnvvi any icmp

Se você obtiver algo assim na saída

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

Então seus pacotes de ping estão sendo enviados e retornados, mas sendo rejeitados por alguma outra regra.

Você pode verificar se possui outras regras em outras tabelas, como nat ou mingle table, se talvez algumas das regras estejam em conflito com o tráfego.

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

Você também pode ver se os pacotes estão passando pela regra ACCEPT na cadeia OUTPUT pelo número abaixo pktsna listagem. Se esse número estiver aumentando depois que você tentar fazer ping, mas o número na cadeia INPUT permanecer 0, o problema está nas regras de tráfego de entrada.

Verifique também suas rotas, com ip rcomando ou algo semelhante, se talvez o tráfego não esteja saindo pela interface na mesma sub-rede, então o IP de origem dos pacotes retornados pode ser alterado devido a algumas regras NAT ao longo do caminho.

Answer