user1404316's questions

Alguns meses atrás, eu migrei o firewall de um laptop debian de iptablespara nftables, usando o procedimento recomendado pelo debian, e tudo parece estar bem. Agora, meses depois, estou examinando o conjunto de regras criado por esse procedimento de migração, tentando aprender a nftablessintaxe e ver o que parecem ser várias regras baseadas em contadores que não entendo e suspeito que podem não estar corretas. Não encontrei o nftableswiki como um recurso educacional útil e não encontrei nenhum outro recurso educacional on-line que aborde esse tipo de pergunta:

O conjunto de regras padrão migrado automaticamente inclui o seguinte:

table inet filter {
  chain INPUT {
    type filter hook input priority 0; policy drop;
    counter packets 123 bytes 105891 jump ufw-before-logging-input                                                                                                                                
    counter packets 123 bytes 105891 jump ufw-before-input
    counter packets 0 bytes 0 jump ufw-after-input
    counter packets 0 bytes 0 jump ufw-after-logging-input
    counter packets 0 bytes 0 jump ufw-reject-input                                                                                                                                               
    counter packets 0 bytes 0 jump ufw-track-input                                                                                                                                                
  }

As duas primeiras counterdeclarações são exemplos do que me chamou a atenção. Estou certo de que eles estão dizendo "pule para as regras na seção ufw-before-foo, mas somente após os primeiros 123 pacotes e os primeiros 105891 bytes terem sido recebidos".

1. Por que não iniciar imediatamente do pacote 0 byte 0?
2. Por que não usar uma sintaxe >= que parece ser suportada por nftables?
3. Esses números são arbitrários? Possivelmente devido a uma falha na migração?

O conjunto de regras acima inclui um salto para a cadeia a seguir, com um problema possivelmente semelhante. Aqui está um trecho dele:

  chain ufw-before-input {
    iifname "lo" counter packets 26 bytes 3011 accept
    ct state related,established counter packets 64 bytes 63272 accept
    ct state invalid counter packets 0 bytes 0 jump ufw-logging-deny
    ct state invalid counter packets 0 bytes 0 drop
    ...
  }

4. Por que as decisões de aceitação são baseadas no recebimento de 26 ou 64 pacotes anteriores?
5. Um firewall pode ser liberado arbitrariamente a qualquer momento após a inicialização e a descoberta/conexão da rede, então por que descartar todos esses pacotes iniciais?

Como mencionei acima, essas regras estão em vigor há meses, então estou me perguntando que efeito negativo elas poderiam ter tido. O único candidato que encontrei é que o laptop às vezes pode ter dificuldade em fazer uma conexão wifi (especialmente depois de sair do modo de suspensão), enquanto um segundo laptop próximo não tem esse problema.

6. Essas regras que descartam pacotes podem ser as culpadas pela dificuldade de negociar uma conexão wifi?

Por que a seguinte printfdeclaração se comportaria de maneira diferente com base em ...? (GNU bash, versão 4.4.18(1)-release (x86_64-pc-linux-gnu))

printf "%s : %s : %s\n" $TERM  ${TERM//[^[:alnum:]]/_} ${TERM//[^[:alnum:]]/?}

Quando em uma sessão de terminal de usuário não privilegiado em tmux, a saída é:

screen-256color : screen_256color : screen?256color

No entanto, quando em um rootterminal, para a mesma tmuxsessão, a saída é:

xterm-256color : xterm_256color :

Fora de tmux, a saída é a mesma falha para todos os usuários:

xterm-256color : xterm_256color :

INFORMAÇÃO ADICIONAL:

Acabei de tentar a mesma linha de comando, mas substituindo o ponto de interrogação por um asterisco, e ocorrem as mesmas falhas e sucessos. Poderia ser um problema relacionado de alguma forma ao globbing? O campo deve ser tratado como um valor de string, não um glob. Em seguida, tentei escapar do caractere e obtive os seguintes resultados, para os seis casos de asterisco simples, com uma barra invertida e com duas barras invertidas, para xterm-256coloros screen-256-colorcasos mencionados acima:

printf "%s : %s : %s\n" $TERM  ${TERM//[^[:alnum:]]/_} ${TERM//[^[:alnum:]]/*}

screen-256color : screen_256color : screen*256color
xterm-256color : xterm_256color :

printf "%s : %s : %s\n" $TERM  ${TERM//[^[:alnum:]]/_} ${TERM//[^[:alnum:]]/\*}

screen-256color : screen_256color : screen*256color
xterm-256color : xterm_256color :

printf "%s : %s : %s\n" $TERM  ${TERM//[^[:alnum:]]/_} ${TERM//[^[:alnum:]]/\\*}

screen-256color : screen_256color : screen\*256color
xterm-256color : xterm_256color : xterm\*256color