Jool: Mesclar Jool em nftables

O NAT64 mantém as informações de estado, etc. É difícil integrá-lo ao kernel principal. O NAT46 pode ser facilmente mesclado como um dispositivo de rede virtual e é improvável que mude muito com o passar dos anos. Os zeladores do kernel sempre o manteriam atualizado. Assim, Jool pode se concentrar no NAT64 e, por exemplo, no suporte a bpfilter ou o que quer que esteja por vir. Se o NAT64 de Jool também se tornasse um dispositivo de rede virtual e o design estivesse em conformidade com o do kernel (por exemplo, usando os próximos rhashtables etc.), também seria adequado para o kernel principal, mas é uma longa jornada até esse ponto. .

(por exemplo, usando os próximos rhashtables etc.)

Pergunta: Onde você ouve sobre esse tipo de coisa? LWN.net ?

Não tenho certeza se Jool se afastou muito do design do kernel. Provavelmente, preciso atualizar meu entendimento sobre isso.

Estou aprendendo o desenvolvimento do kernel Linux há alguns anos, porque gostaria de adicionar algumas funcionalidades ao mac80211, que é bastante difícil (MCCA). Portanto, li todos os livros da O'Reilly e, na verdade, muitos artigos da LWN.

Na verdade, ainda sou muito ruim nisso. No momento, estou trabalhando, por exemplo, em um dispositivo de camada 2 de rede virtual NAT4 (2) 6 fortemente modificado que faz o rastreamento de conexão para permitir roaming contínuo para clientes em redes mesh Babel. Eu fiz uma palestra no Battlemesh sobre isso, mas está um pouco desatualizado. A configuração se tornou ainda mais complexa, pois não quero que as conexões TCP sejam interrompidas e não confio no comportamento inteligente do cliente, o que significa que o módulo precisa fazer o rastreamento de conexão para falsificar um único gateway.

É por isso que conversei com alguns desenvolvedores de kernel sobre como um módulo de kernel precisa ter a aparência e "sensação" de ser mesclado com o kernel principal. Um dispositivo de rede virtual NAT46 simples, em conformidade com RFC, que seja compatível com NAPI e net-utils, provavelmente seria aceito upstream.

(Não é uma atualização muito boa, mas quero mesclar as duas conversas e responder a este e-mail ao mesmo tempo.)

Não há nada que me impeça de abrir algumas portas, a não ser as solicitações de recursos de maior prioridade ainda aguardando implementação. Dito isso, se eu tentasse fazer isso, esperaria encontrar alguns obstáculos:

1. Sempre que um novo recurso é adicionado ao kernel, entendo que precisa ser justificado e sou completamente incompetente como debatedor. Acho que seria difícil justificar a inclusão de Jool, especialmente considerando que pode ser (e atualmente está sendo) empacotado. A tradução de IP ainda tem um público de nicho e Jool pode ser muito grande para valer a pena ser enviado por padrão em todos os Debian, por exemplo.
2. nftables e modos de driver de dispositivo são provavelmente modernizações necessárias, mas ainda não foram implementados. (Apesar de a forma como a pesquisa está indo, isso não vai permanecer um obstáculo por muito tempo.)
3. @CodeFetch sugere (acima) que o SIIT e o MAP-T provavelmente seriam aceitos no kernel, mas o NAT64 não. Mesclar SIIT e MAP-T e deixar NAT64 como um módulo é mais trabalhoso.
4. O código tem muitos comentários em alguns lugares. Os desenvolvedores de kernel abominam que: p

Abordar 2, 3 e 4 é uma questão de tempo, mas gostaria de ouvir alguns argumentos para derrotar 1.

Para começar, aqui está uma razão técnica pela qual mesclar Jool com o kernel seria uma boa ideia:

1. lowest-ipv6-mtu seria muito mais fácil de implementar e substancialmente mais performante se os módulos do kernel fossem autorizados a informar ao fragmentador do Linux um tamanho máximo de fragmento. (Uma espécie de MTU associado a um pacote em vez de uma interface.) Se Jool fosse incorporado ao Linux, o último provavelmente ficaria tentado a incluir tal recurso.

(Não é uma atualização muito boa, mas quero mesclar as duas conversas e responder a este e-mail ao mesmo tempo.)

Não há nada que me impeça de abrir algumas portas, a não ser as solicitações de recursos de maior prioridade ainda aguardando implementação. Dito isso, se eu tentasse fazer isso, esperaria encontrar alguns obstáculos:

1. Sempre que um novo recurso é adicionado ao kernel, entendo que precisa ser justificado e sou completamente incompetente como debatedor. Acho que seria difícil justificar a inclusão de Jool, especialmente considerando que pode ser (e atualmente está sendo) empacotado. A tradução de IP ainda tem um público de nicho e Jool pode ser muito grande para valer a pena ser enviado por padrão em todos os Debian, por exemplo.

Eu posso ajudar nesse sentido. Estive envolvido um pouco com a discussão do RSBAC no início dos anos 2000 (e os problemas em torno dela) e vi a abordagem do wireguard.
Certamente levará algum tempo e provavelmente algumas modificações para se ajustar aos padrões atuais de design / código do kernel, mas isso não deve representar um problema real, eu presumo.

1. nftables e modos de driver de dispositivo são provavelmente modernizações necessárias, mas ainda não foram implementados. (Apesar de a forma como a pesquisa está indo, isso não vai permanecer um obstáculo por muito tempo.)

Isso parece muito promissor!

1. @CodeFetch sugere (acima) que o SIIT e o MAP-T provavelmente seriam aceitos no kernel, mas o NAT64 não. Mesclar SIIT e MAP-T e deixar NAT64 como um módulo é mais trabalhoso.

Acho que isso está sujeito a discussão e talvez uma conversa com o grupo netfilter seja uma boa coisa a se fazer. Se você quiser, posso entrar em contato e
comece a discussão geral na lista de e-mails do netfilter para ouvir sobre o sentimento de que o jool está indo para o upstream.

1. O código tem muitos comentários em alguns lugares. Os desenvolvedores de kernel abominam que: p

Abordar 2, 3 e 4 é uma questão de tempo, mas gostaria de ouvir alguns argumentos para derrotar 1.

Para começar, aqui está uma razão técnica pela qual mesclar Jool com o kernel seria uma boa ideia:

1. lowest-ipv6-mtu seria muito mais fácil de implementar e substancialmente mais performante se os módulos do kernel fossem autorizados a informar ao fragmentador do Linux um tamanho máximo de fragmento. (Uma espécie de MTU associado a um pacote em vez de uma interface.) Se Jool fosse incorporado ao Linux, o último provavelmente ficaria tentado a incluir tal recurso.

Vejo muitos argumentos convincentes para mesclá-lo na linha principal:

• IPv6 está ficando significativamente mais exposto
• O NAT64 está se tornando mais necessário / será uma coisa padrão a se fazer, junto com o MAP-E / T
• O OpenBSD já tem a funcionalidade no pf
• Habilitá-lo no upstream pode ajudar potencialmente a migração para IPv6 em todo o mundo

Se 2/3/4 forem fáceis da sua parte, posso apoiar um pouco com 1 e estender a mão lentamente e entender como é a atitude geral em relação ao jool no upstream.

Acho que isso está sujeito a discussão e talvez uma conversa com o grupo netfilter seja uma boa coisa a se fazer. Se você quiser, posso entrar em contato e
comece a discussão geral na lista de e-mails do netfilter para ouvir sobre o sentimento de que o jool está indo para o upstream.

OK. No momento, estou escrevendo uma mensagem que devo postar na lista de discussão de desenvolvedores do Netfilter amanhã.

Pelos arquivos, parece que houve algumas tentativas de levantar um pouco de exagero sobre o NAT64 muitos anos atrás, mas elas parecem não ter tido sucesso.

Portanto, sinta-se à vontade para intervir ou até mesmo antes de mim. Não consigo imaginar minha mensagem sendo persuasiva por si só.

https://marc.info/?l=netfilter-devel&m=157807496904032&w=2