Racoon no Linux - Perda inicial de pacotes

Question

Configurei duas caixas Linux para que elas usem automaticamente uma conexão IPSec no nível de transporte sempre que precisarem se comunicar. A configuração é baseada no Racoon com autenticação X509 e a opção bundle_complex definida como on , bem como políticas que exigem o ESP e o AH entre as duas caixas.

Enquanto a configuração funciona, em geral, os primeiros pacotes são sempre perdidos, por exemplo:

$ ping -c 3 A.B.C.D
PING A.B.C.D (A.B.C.D) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
64 bytes from A.B.C.D: icmp_req=3 ttl=64 time=0.497 ms

Existe alguma maneira de evitar isso, por exemplo, "atrasando" os pacotes até que o transporte IPSec tenha sido negociado?

    

Answer 1

O primeiro pacote (e todos os outros até que a negociação seja concluída) é sempre descartado.

Isso é verdade para todas as implementações do ISAKMP com as quais lidei. Eu não acredito que haja necessariamente qualquer razão que não pudesse armazenar em buffer os pacotes que estão sendo descartados; em vez disso, não deveria .

Esta é uma extensão de uma decisão de design consciente que é usada em toda a infraestrutura de roteamento da Internet: Não segure os pacotes .

Os sistemas de roteamento na Internet sempre descartarão um pacote em vez de atrasá-lo, quando não conseguirem (quase) direcioná-lo imediatamente. A perda de pacotes na Internet como um todo poderia ser facilmente reduzida a níveis muito mais baixos simplesmente mantendo um pacote em buffer até que haja espaço para isso. Mas é aí que reside o problema; um roteador sobrecarregado executando 200ms em uma fila first-in-first-out atrasaria cada pacote por 200ms.

Trazendo isso de volta para a situação do ISAKMP; segurar um par de pings até que o caminho esteja pronto para carregá-los é ótimo, mas e se for um fluxo constante de centenas de milhares de pacotes UDP? E se o sistema remoto estiver inacessível, então o ISAKMP fica lá esperando por uma mensagem de negociação do ISAKMP 2 por 60 segundos?

Embora esses não sejam problemas de engenharia intransponíveis, a sabedoria convencional na comunidade de engenharia da Internet é que é muito mais simples e fácil ter sistemas clientes lidando com problemas de perda de pacotes, principalmente por meio do uso de protocolos tolerantes a perdas como o TCP. / p>     

Answer 2

Você pode iniciar automaticamente o túnel IPSEC antes que qualquer tráfego comece a fluir (geralmente os primeiros pacotes descartados iniciam a negociação IKE). Aqui está como fazer isso com StrongSwan:

   auto = ignore | add | route | start
          what operation, if any, should be done  automatically  at  IPsec
          startup;  currently-accepted  values  are  add, route, start and
          ignore (the default).  add loads a connection  without  starting
          it.   route  loads  a  connection  and installs kernel traps. If
          traffic is detected between leftsubnet and rightsubnet , a  con‐
          nection  is established.  start loads a connection and brings it
          up immediatly.  ignore ignores the connection. This is equal  to
          delete  a  connection  from  the  config  file.   Relevant  only
          locally, other end need not agree on it (but in general, for  an
          intended-to-be-permanent   connection,   both  ends  should  use
          auto=start to ensure that any reboot causes immediate renegotia‐
          tion).

Embora eu ainda não tenha descoberto como fazer a mesma coisa com o racoon, mas eu acho que deveria haver algo similar também.