ipipou: mais do que apenas um túnel não criptografado

O que dizemos ao deus IPv6?





É verdade, e para o deus da criptografia, diremos o mesmo hoje.



Aqui, será sobre um túnel IPv4 não criptografado, mas não sobre uma "lâmpada quente", mas sobre uma moderna "LED". E então os soquetes brutos estão piscando e há trabalho com pacotes no espaço do usuário.



Existem protocolos de tunelamento N para todos os gostos e cores:

• WireGuard elegante, moderno e jovem
• , , OpenVPN SSH
• GRE
• , , IPIP
• GENEVE
• .

Mas eu sou um programador, então aumentarei N apenas uma fração e deixarei o desenvolvimento de protocolos reais para os desenvolvedores b.



Em outro projeto que ainda não nasceu , no qual estou envolvido no momento, preciso acessar os hosts por trás do NAT de fora. Usando protocolos com criptografia adulta para isso, nunca deixei a sensação de que era como uma bala de canhão. Porque o túnel é usado em sua maior parte apenas para abrir uma brecha no NAT-e, o tráfego interno geralmente é criptografado também, embora seja bloqueado por HTTPS.



Enquanto pesquisava vários protocolos de tunelamento, a atenção do meu perfeccionista interno foi atraída para o IPIP vez após vez por causa de sua sobrecarga mínima. Mas tem uma desvantagem e meia significativa para minhas tarefas:

• requer IPs públicos em ambos os lados,
• e nenhuma autenticação para você.

Portanto, o perfeccionista foi empurrado de volta para o canto escuro do crânio, ou onde quer que ele se sente.



E uma vez, ao ler artigos sobre túneis com suporte nativo no Linux, me deparei com FOU (Foo-over-UDP), ou seja, tanto faz, envolto em UDP. Até agora, apenas IPIP e GUE (encapsulamento UDP genérico) são suportados de qualquer outra coisa.



“Aqui está uma bala de prata! Eu e um simples IPIP para os olhos. " Eu pensei.



Na verdade, a bala não era inteiramente de prata. O encapsulamento em UDP resolve o primeiro problema - você pode se conectar a clientes por trás do NAT de fora usando uma conexão pré-estabelecida, mas aqui metade da próxima desvantagem do IPIP surge sob uma nova luz - qualquer pessoa da rede privada pode se esconder atrás do IP público visível e da porta do cliente (em IPIP puro não há problema).



Para resolver esse problema e meio, nasceu o utilitário ipipou . Ele implementa um mecanismo feito pelo próprio para autenticar um host remoto, sem interromper a operação de uma FOU vigorosa, que processará pacotes de forma rápida e eficiente no espaço do kernel.

Não precisa do seu script!

Ok, se você conhece a porta pública e o IP do cliente (por exemplo, todos seus, onde quer que vá, o NAT tenta mapear as portas 1 para 1), você pode criar um túnel IPIP-over-FOU com os seguintes comandos, sem nenhum script.



no servidor:

#    FOU
modprobe fou

#  IPIP     FOU.
#  ipip  .
ip link add name ipipou0 type ipip \
    remote 198.51.100.2 local 203.0.113.1 \
    encap fou encap-sport 10000 encap-dport 20001 \
    mode ipip dev eth0

#       FOU   
ip fou add port 10000 ipproto 4 local 203.0.113.1 dev eth0

#  IP  
ip address add 172.28.0.0 peer 172.28.0.1 dev ipipou0

#  
ip link set ipipou0 up

no cliente:

modprobe fou

ip link add name ipipou1 type ipip \
    remote 203.0.113.1 local 192.168.0.2 \
    encap fou encap-sport 10001 encap-dport 10000 encap-csum \
    mode ipip dev eth0

#  local, peer, peer_port, dev     ,   .
# peer  peer_port        FOU-listener-.
ip fou add port 10001 ipproto 4 local 192.168.0.2 peer 203.0.113.1 peer_port 10000 dev eth0

ip address add 172.28.0.1 peer 172.28.0.0 dev ipipou1

ip link set ipipou1 up

Onde

• ipipou* - o nome da interface de rede do túnel local
• 203.0.113.1 - IP público do servidor
• 198.51.100.2 - IP público do cliente
• 192.168.0.2 - IP do cliente atribuído à interface eth0
• 10001 - porta do cliente local para FOU
• 20001 - porta cliente pública para FOU
• 10000 - porta do servidor público para FOU
• encap-csum — UDP UDP ; noencap-csum, , ( )
• eth0 — ipip
• 172.28.0.1 — IP ()
• 172.28.0.0 — IP ()

Enquanto a conexão UDP estiver ativa, o túnel estará em um estado de funcionamento, e como ele quebra, que sorte - se o IP: porta do cliente permanecer o mesmo - ele viverá, mudará - ele irá quebrar.



A maneira mais fácil de mudar as coisas é descarregando os módulos do kernel: modprobe -r fou ipip



Mesmo que a autenticação não seja necessária, o IP público e a porta do cliente nem sempre são conhecidos e geralmente são imprevisíveis ou alteráveis ​​(dependendo do tipo de NAT). Se você omiti-lo encap-dportno lado do servidor, o túnel não funcionará, não é inteligente o suficiente para usar a porta de conexão remota. Nesse caso, ipipou também pode ajudar, bem, ou WireGuard e outros como ele podem ajudá-lo.

Como funciona?

O cliente (que geralmente está por trás do NAT) configura um túnel (como no exemplo acima) e envia um pacote autenticado ao servidor para que ele possa configurar o túnel por seu lado. Dependendo das configurações, pode ser um pacote vazio (apenas para que o servidor veja o IP público: porta de conexão), ou com dados pelos quais o servidor possa identificar o cliente. Os dados podem ser uma frase-senha simples de texto simples (uma analogia com HTTP Basic Auth) ou dados especialmente formatados assinados com uma chave privada (por analogia com HTTP Digest Auth, só que mais forte, veja a função client_authno código).



No servidor (ao lado do IP público), quando o ipipou é iniciado, ele cria um manipulador de fila nfqueue e configura o netfilter para que os pacotes necessários sejam enviados para onde devem ir: os pacotes que inicializam a conexão com a fila nfqueue e [quase] todo o resto direto para o ouvinte FOU.



Quem não está no assunto, nfqueue (ou NetfilterQueue) é algo especial para amadores que não sabem desenvolver módulos de kernel , que por meio de netfilter (nftables / iptables) permite redirecionar pacotes de rede para o espaço do usuário e processá-los com meios improvisados ​​primitivos : modificar (opcional ) e devolver ao kernel ou descartar.



Para algumas linguagens de programação existem ligações para trabalhar com nfqueue, para bash não havia (heh, não é surpresa), eu tive que usar python: ipipou usa NetfilterQueue .



Se o desempenho não for crítico, com a ajuda disso você pode preparar sua própria lógica de maneira relativamente rápida e fácil para trabalhar com pacotes em um nível bastante baixo, por exemplo, esculpir protocolos de transferência de dados experimentais ou rastrear serviços locais e remotos com comportamento não padrão.



Os soquetes brutos funcionam lado a lado com o nfqueue, por exemplo, quando o túnel já está configurado e a FOU está escutando na porta desejada, não funcionará da maneira usual para enviar um pacote da mesma porta - está ocupado, mas você pode pegar e disparar um pacote gerado aleatoriamente diretamente na rede interface usando um socket raw, embora a geração de tal pacote exija um pouco mais de trabalho. É assim que os pacotes com autenticação são criados no ipipou.



Como o ipipou processa apenas os primeiros pacotes da conexão (bem, aqueles que conseguiram vazar para a fila antes de a conexão ser estabelecida), o desempenho dificilmente é afetado.



Assim que o servidor ipipou recebe um pacote autenticado, um túnel é criado e todos os pacotes subsequentes na conexão já são processados ​​pelo kernel ignorando nfqueue. Se a conexão estiver ruim, o primeiro pacote do próximo será enviado para a fila nfqueue, dependendo das configurações, se não for um pacote de autenticação, mas do último IP lembrado e porta do cliente, ele pode ser transmitido ou descartado. Se um pacote autenticado vier de um novo IP e porta, o túnel será reconfigurado para usá-los.



O IPIP-over-FOU usual tem outro problema ao trabalhar com NAT - você não pode criar dois túneis IPIP encapsulados em UDP com o mesmo IP, porque os módulos FOU e IPIP estão bastante isolados um do outro. Essa. um par de clientes atrás de um IP público não será capaz de se conectar simultaneamente ao mesmo servidor desta forma. No futuro, pode ser resolvido no nível do kernel, mas isso não é certo. Enquanto isso, problemas de NAT podem ser resolvidos por NAT - se acontecer de um par de endereços IP já estar ocupado por outro túnel, ipipou fará o NAT do IP público para um IP privado alternativo, voila! - você pode criar túneis até que as portas se esgotem.



Porque nem todos os pacotes na conexão são assinados, então essa proteção simples é vulnerável ao MITM, então se um vilão se esconde no caminho entre o cliente e o servidor, que pode ouvir e controlar o tráfego, ele pode redirecionar os pacotes autenticados por outro endereço e criar um túnel a partir de um host não confiável ...



Se alguém tiver alguma ideia sobre como consertar isso, mantendo a maior parte do tráfego no núcleo, sinta-se à vontade para falar.



A propósito, o encapsulamento UDP se provou muito bem. Comparado ao encapsulamento sobre IP, é muito mais estável e geralmente mais rápido, apesar da sobrecarga adicional do cabeçalho UDP. Isso se deve ao fato de que a maioria dos hosts na Internet funciona razoavelmente bem apenas com os três protocolos mais populares: TCP, UDP, ICMP. A parte perceptível geralmente pode descartar todo o resto, ou processar mais lentamente, porque é otimizada apenas para esses três.



Por exemplo, portanto, QUICK, com base no qual HTTP / 3 foi criado, foi criado por UDP, e não por IP.



Bem, palavras suficientes, é hora de ver como funciona no "mundo real".

Batalha

Usado para emular o mundo real iperf3. Em termos de grau de proximidade com a realidade, trata-se da emulação do mundo real no Minecraft, mas por enquanto servirá.



A competição envolve:

• canal mestre de referência
• o herói deste artigo é ipipou
• OpenVPN com autenticação, mas sem criptografia
• OpenVPN All Inclusive
• WireGuard sem PresharedKey, com MTU = 1440 (para IPv4 apenas)

resultados

canal para 20 Mbps











canal para 1 Gbps otimista











Em todos os casos o ipipou está bem próximo em termos de desempenho do canal base, e isso é ótimo!



O túnel openvpn não criptografado se comportou de maneira bastante estranha em ambos os casos.



Se alguém for testá-lo, será interessante ouvir o feedback.



Que o IPv6 e o ​​NetPrickle estejam conosco!