Eu tenho algo muito estranho acontecendo que não consigo encontrar nenhuma referência depois de muito pesquisar no Google. Parece que não tenho iptables. Não que as cadeias sejam liberadas ou que todas sejam regras ACCEPT ou algo assim, as tabelas em si parecem não existir. Aqui está o que quero dizer:
A história é que meu estivador parou de funcionar em algum momento nos últimos meses e finalmente consegui consertá-lo. O erro estava sendo causado pelo seguinte comando:
$ iptables -A DOCKER-ISOLATION-STAGE-1 -j RETURN
iptables: No chain/target/match by that name.
Qual docker é executado como parte de sua inicialização e qual tentei executar manualmente para depurar.
Então comecei a mexer tentando adicionar correntes e regras diferentes em lugares diferentes, e tudo dava aquele erro. Então, finalmente, tentei apenas listar tudo
$sudo iptables -S
iptables: No chain/target/match by that name.
$ sudo iptables -L
iptables: No chain/target/match by that name.
$ sudo iptables --list
iptables: No chain/target/match by that name.
nada. Então eu tentei olhar para cada uma das tabelas
# iptables -vL -t filter
iptables: No chain/target/match by that name.
# iptables -vL -t nat
iptables: No chain/target/match by that name.
# iptables -vL -t mangle
iptables: No chain/target/match by that name.
# iptables -vL -t raw
iptables: No chain/target/match by that name.
# iptables -vL -t security
iptables: No chain/target/match by that name.
Mais nada, é como se as próprias tabelas tivessem desaparecido. Mesmo algo tão simples quanto
# iptables -P INPUT ACCEPT
iptables: Bad built-in chain name.
não funciona.
Alguém viu isso antes? Existe alguma maneira de recuperar as mesas?
Meu sistema é Ubuntu 18.10 com Kernel 5.1.8
Atualizações
Desde então, adicionei todos os módulos iptables ao meu /etc/modules
e reconstruí o initramfs. Os módulos agora são carregados na inicialização, mas isso não resolveu o problema.
Descobri que o iptables-save
comando não dá erro, mas também só imprime o seguinte:
# Generated by iptables-save v1.6.1 on Tue Jun 11 17:35:52 2019
*nat
COMMIT
# Completed on Tue Jun 11 17:35:52 2019
# Generated by iptables-save v1.6.1 on Tue Jun 11 17:35:52 2019
*mangle
COMMIT
# Completed on Tue Jun 11 17:35:52 2019
# Generated by iptables-save v1.6.1 on Tue Jun 11 17:35:52 2019
*raw
COMMIT
# Completed on Tue Jun 11 17:35:52 2019
# Generated by iptables-save v1.6.1 on Tue Jun 11 17:35:52 2019
*security
COMMIT
# Completed on Tue Jun 11 17:35:52 2019
# Generated by iptables-save v1.6.1 on Tue Jun 11 17:35:52 2019
*filter
COMMIT
# Completed on Tue Jun 11 17:35:52 2019
Também descobri que o ip6tables parece estar funcionando normalmente, é apenas o iptables que está quebrado.
Em seguida, tentei executar alguns dos comandos iptables no modo detalhado.
# iptables -S -vv
libiptc vlibxtables.so.12. 0 bytes.
Table `filter'
Hooks: pre/in/fwd/out/post = 7f68/9f6085dd/5616/9f60a8e0/5616
Underflows: pre/in/fwd/out/post = 36e4540/7fff/36e48e8/7fff/0
iptables: No chain/target/match by that name.
# iptables -N DOCKER-ISOLATION-STAGE-1 -vv
No modo detalhado, este comando não é concluído, a saída é enorme. Tentei despejá-lo em um arquivo, mas o matei quando o arquivo atingiu 8,5 GB de tamanho. A saída é todas as repetições do seguinte padrão:
libiptc vlibxtables.so.12. 1032595540 bytes.
Table `filter'
Hooks: pre/in/fwd/out/post = 7ffe/92c0b5dd/55a7/92c0d8e0/55a7
Underflows: pre/in/fwd/out/post = 3d8c10f0/7ffe/3d8c1498/7ffe/3d8c2854
Entry 0 (0):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 0 packets, 0 bytes
Cache: 00000000
Target name: `' [0]
verdict=0
Entry 0 (0):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 0 packets, 0 bytes
Cache: 00000000
Target name: `' [0]
verdict=0
Espero que isso faça sentido para alguém, não faz sentido para mim.
Pesquisando na internet descobri que é possível restaurar o iptables no Linux usando o seguinte comando
iptables-restore < /root/working.iptables.rules
No entanto, existem alguns guias técnicos que sugerem que, se usar o proxy kubernetes, as regras do iptables serão perdidas após reiniciar o iptables+node.
Os seguintes arquivos fornecem informações úteis sobre isso:
https://www.cyberciti.biz/faq/how-to-save-restore-iptables-firewall-config-ubuntu/
https://github.com/openshift/origin/issues/1922
https://www.linuxquestions.org/questions/linux-security-4/iptables-no-chain-tarjet-match-by-that-name-941406/
Espero que isso possa ajudar!
Já tentou reinstalar manualmente o iptables?
Tirado daqui .
Isso acabou sendo um problema de configuração do kernel. Normalmente, quando aplico meu patch e construo um novo kernel, copio a configuração que estava usando da versão anterior (em retrospectiva, talvez uma má ideia). Depois de mesclar minha configuração com a configuração mais recente do kernel do Ubuntu e reconstruí o kernel, minha saída do iptables parecia normal novamente.