WireGuard, configurando vários clientes para NAT, e para onde vai o STUN?

No momento, estamos lançando o acesso a servidores baseados no WireGuard e hoje quero falar sobre como configurar clientes que estão por trás do NAT, embora também não nos esqueçamos da configuração do servidor.

Primeiro, sobre as vantagens do WireGuard e o verso da moeda, sobre as dificuldades que surgem junto com as vantagens. O WireGuard é uma implementação bastante jovem de um túnel entre dois pontos, pois o protocolo de transmissão é usado pelo UDP. É por isso que, e também porque a própria implementação do Linux é implementada como um módulo do kernel, os testes mostram uma vantagem de velocidade decente sobre os concorrentes. Isso não pode ser considerado uma rede ponto a ponto, embora os nós finais sejam chamados de ponto . A essência de uma rede ponto a ponto não é apenas a possibilidade de conectar dois nós arbitrários. Obviamente, com este kit de ferramentas, você pode construir uma infraestrutura de rede muito complexa, mas eu não tenho esse objetivo. Consideraremos conectar-se a um nó do servidor e acessar a Internet através dele.

Obviamente, se dois nós, o servidor e um cliente tiverem IPs brancos , nesse caso, não haverá dificuldades na configuração. Mas geralmente os clientes estão atrás do NAT e, nesse caso, ao configurar o servidor, você deve especificar o endereço IP errado que é emitido / registrado no dispositivo. Nesse sentido, o protocolo STUN pode ajudar. Este protocolo é frequentemente usado ao trabalhar com VoIP, especialmente quando os dois clientes estão atrás do NAT. Mas, no nosso caso, também ajudará. A julgar pelas informações da Wikipedia, o STUN não funciona com todos os tipos de NATs; em um dos quatro tipos de NATs, um cliente (simétrico) pode ter um IP diferente daquele que pode ser definido externamente usando o cliente STUN.

Os clientes STUN existem em todos os sistemas operacionais populares, exceto no iOS. Sob esse sistema operacional, não consegui encontrar o cliente STUN. Vou dar um exemplo para o macOS. Primeiro, você precisa instalar o próprio cliente STUN.

$ brew install stunman 

Existem vários servidores STUN na Internet e não é difícil encontrar nenhum servidor para o teste. Vou usar stun.ekiga.net . Para o teste, você precisará usar a porta local, aquela que usaremos para configurar:

 $ stunclient --localport 51820 stun.ekiga.net 

Com um teste bem-sucedido, obtemos aproximadamente a seguinte conclusão:

 Binding test: success Local address: 192.168.88.23:51820 Mapped address: 82.207.27.3:51820 

O endereço mapeado é exatamente o IP que você precisará usar ao configurar o servidor. De fato, este é o endereço IP que, no meu caso, fornecerá qualquer serviço para determinar o IP externo. Portanto, você pode usar seu serviço favorito para determinar a IP, mas é claro, vale a pena considerar que esse teste será indireto e não há garantia de que tudo funcione conforme o esperado.

Para conectar, no lado do cliente, ao servidor, você deve fornecer: IP, porta e chave pública. Para configuração no lado do cliente, você precisa exatamente da mesma lista fornecida no lado do servidor. Em seguida, vou sugerir opções para configurações, se você as usar como exemplos, é recomendável regenerar as chaves.

No Linux, isso pode ser feito na linha de comando, no macOS, por meio da interface do usuário oficial do cliente.

 $ wg genkey | tee privatekey | wg pubkey > publickey 

Nesse caso, no local da chamada, a chave privada será criada no arquivo privatekey, public in in publickey, respectivamente.

Primeiro, considere a configuração do cliente:

 #       [Interface] #       PrivateKey = YPuKo2QXndQ2Vc3S/y90oKT7AJ0Swhq/HWKiF7GwS04= #         ListenPort = 51820 #  IP   ,        #    Address = 10.8.0.2/24 # DNS   ,      DNS = 8.8.8.8 #     [Peer] #   ,     PublicKey = nFjDIkgsAh1RMZuaCJ+AKs7JmbMxxthhZ0POjUSTvkc= #     ,       # IP  ,          #     ,      #     WireGuard . IP   , #   . AllowedIPs = 0.0.0.0/0 #  IP    Endpoint = 46.101.122.130:51820 #  2 .  -    ,     , #    AllowedIPs         #   .  -     # ,    -  25 . PersistentKeepalive = 25 

Agora é hora da configuração do servidor:

 #       [Interface] # IP      Address = 10.8.0.1/24 #     ListenPort = 51820 #  ,      PrivateKey = MNnxOy79xtXtSQ3UySWtdlOMbG7ff9dXGjeSTPEByn8= #  2 ,      wg0  PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE #     [Peer] #   ,    PublicKey = TdRtYd6XXI+ynPDXU6FF5TT3L5t/YlQVZswr2xsou34= #   IP ,     , #     AllowedIPs = 10.8.0.2/32 #  IP ,   ,     STUN  EndPoint = 82.207.27.3:51820 

Ao usar essas configurações como exemplos, é recomendável excluir comentários em russo, o servidor e o cliente no caso de comentários não são garantidos.

Usei os seguintes recursos para configurar: o site oficial , ArchWiki, e este tutorial .

No final, também gostaria de esclarecer algumas questões possíveis:

1. É possível criar várias seções do mesmo ponto no servidor, que diferem apenas no EndPoint ?

Sim, é possível e pode até ser útil se você usar o serviço em locais diferentes, por exemplo, no trabalho e em casa. Mas podem surgir problemas se esses pares ficarem on-line simultaneamente, nesse caso, haverá um conflito de endereços IP.

2. Qual IP e porta externos serão determinados pelo protocolo STUN para vários clientes por NAT?

O mesmo para todos os clientes, será o mesmo. Isso seria um problema? Tudo depende das configurações do seu provedor / roteador, mas fundamentalmente não devem surgir problemas, uma vez que o roteador deve transmitir pacotes UDP dentro da rede pela máscara de rede local, respectivamente, aqueles que recebem as mensagens que podem descriptografar os pacotes devem recebê-los com êxito. Realizamos testes em nossos equipamentos, os testes foram bem-sucedidos.

O objetivo do artigo não era escrever um tutorial completo sobre como configurar o WireGuard, não é difícil fazer isso usando a documentação oficial. Queríamos mostrar como o WireGuard pode funcionar para o NAT.

Se você quiser experimentar o WireGuard nos negócios, entre em contato conosco , temos acesso no modo de teste.

UPD:
Como corretamente apontado pelo habitante do aborouhin , apenas um IP branco é suficiente para o canal de dados funcionar sem problemas. Consequentemente, o EndPoint for Peer pode ser omitido da configuração do servidor, e isso facilita a configuração. E o manual descrito pode ser útil se os dois nós estiverem atrás do NAT.

Source: https://habr.com/ru/post/pt481838/


All Articles