One place for hosting & domains

      Networking

      Getting Started with Software-Defined Networking and Creating a VPN with ZeroTier One


      Introdução

      Atualmente, cada vez mais os projetos de software são construídos por equipes cujos membros trabalham em conjunto em localidades geográficas diferentes. Embora este fluxo de trabalho tenha muitas vantagens claras, existem casos onde tais equipes podem querer vincular seus computadores na internet e tratá-los como se estivessem na mesma sala. Por exemplo, você pode estar testando sistemas distribuídos como o Kubernetes ou construindo um aplicativo multisserviço complexo. Às vezes, tratar as máquinas como se elas estivessem uma ao lado da outra ajuda na produtividade, já que não seria necessário arriscar expor seus serviços inacabados na internet. Este paradigma pode ser alcançado através da Rede Definida por Software (SDN), uma tecnologia relativamente nova que fornece uma estrutura de rede dinâmica cuja existência é totalmente composta por software.

      O ZeroTier One é um aplicativo de código aberto que usa alguns dos últimos desenvolvimentos em SDN para permitir que os usuários criem redes seguras, gerenciáveis e tratem dispositivos conectados como se estivessem no mesmo local físico. O ZeroTier fornece um console Web para o gerenciamento de rede e o software de terminal para os clientes. Trata-se de uma tecnologia criptografada ponto a ponto, o que significa que ao contrário de soluções tradicionais VPN, as comunicações não precisam passar por um servidor central ou roteador — as mensagens são enviadas diretamente de host para host. Como resultado, ela é muito eficiente e garante latência mínima. Outros benefícios incluem a implantação e o processo de configuração simples do ZeroTier, manutenção sem complicações, que permite o registro e gerenciamento centralizados de nós autorizados pelo Console Web.

      Ao seguir este tutorial, você irá conectar um cliente e servidor juntos em uma rede simples ponto a ponto. Como a Rede Definida por Software não utiliza o design tradicional cliente/servidor, não há servidor VPN central para instalar e configurar; isso simplifica a implantação da ferramenta e a adição de qualquer nó complementar. Assim que a conectividade for estabelecida, será possível usar a capacidade VPN do ZeroTier usando algumas funcionalidades inteligentes do Linux. Isso permite que o tráfego deixe sua rede do ZeroTier do seu servidor e instrua um cliente para enviar o tráfego naquela direção.

      Pré-requisitos

      Antes de trabalhar neste tutorial, você precisará dos seguintes recursos:

      • Um servidor executando o Ubuntu 16.04. Neste servidor, será necessário um usuário não raiz com privilégios sudo que pode ser configurado usando nosso guia de configuração inicial de servidor para o Ubuntu 16.04.

      • Uma conta com o ZeroTier One, que você pode configurar indo para o My ZeroTier. Para os fins deste tutorial, é possível usar a versão gratuita deste serviço que não tem custos ou compromissos.

      • Um computador local para se juntar ao seu SDN como um cliente. Nos exemplos neste tutorial, tanto o servidor como o computador local estão executando o Linux Ubuntu, mas qualquer sistema operacional listado na página de download do ZeroTier funcionará no cliente.

      Com esses pré-requisitos no lugar, você está pronto para configurar a rede definida por software para seu servidor e máquina local.

      Passo 1 — Criando uma rede definida por software usando o ZeroTier One

      A plataforma ZeroTier fornece o ponto central de controle para sua rede definida por software. Lá, você pode autorizar e desautorizar clientes, escolher um esquema de endereço e criar um ID de rede ao qual você pode dirigir seus clientes ao configurá-los.

      Logue na sua conta do ZeroTier, clique em Networks no topo da tela e, em seguida, clique em Create. Um nome de rede gerado automaticamente aparecerá. Clique nele para ver a tela de configuração da sua rede. Anote o Network ID mostrado em amarelo, já que você precisará usá-lo mais tarde.

      Se preferir alterar o nome da rede para algo mais descritivo, edite o nome no lado esquerdo da tela; você também pode adicionar uma descrição, caso queira. Qualquer alteração que você fizer será salva e aplicada automaticamente.

      Em seguida, escolha em qual intervalo de endereços IPv4 o SDN irá operar. No lado direito da tela, na área intitulada IPv4 Auto-Assign, selecione um intervalo de endereços em que seus nós irão se enquadrar. Para os fins deste tutorial, qualquer intervalo pode ser usado, mas é importante deixar a caixa Auto-Assign from Range marcada.

      Certifique-se de que o Access Control à esquerda permaneça definido como Certificate (Private Network). Isso garante que apenas máquinas aprovadas possam se conectar à sua rede, e não qualquer uma que saiba seu ID de rede!

      Assim que terminar, suas configurações devem ser semelhantes a estas:

      ZeroTier settings configuration

      Neste ponto, você instalou a fundação de uma Rede Definida por Software do ZeroTier com sucesso. Em seguida, você instalará o software ZeroTier no seu servidor e máquinas de cliente para permitir que eles se conectem ao seu SDN.

      Passo 2 — Instalando o cliente ZeroTier One no seu servidor e computador local

      Como o ZeroTier One é um software relativamente novo, ele ainda não foi incluído nos repositórios de software principais do Ubuntu. Por esse motivo, o ZeroTier fornece um script de instalação que vamos usar para instalar o software. Este comando é um script assinado por GPG, o que significa que o código que você baixa será verificado como publicado pelo ZeroTier. Este script tem quatro partes principais, e esta é uma explicação detalhada de cada uma delas:

      • curl -s 'https://pgp.mit.edu/pks/lookup?op=get&search=0x1657198823E52A61' – importa a chave pública do ZeroTier do MIT.
      • gpg --import – esta seção do comando adiciona a chave pública do ZeroTier ao seu conjunto de chaves local de autoridades para confiar em pacotes que tentar instalar. A próxima parte do comando será executada apenas se a importação GPG for concluída com sucesso.
      • if z=$(curl -s 'https://install.zerotier.com/' | gpg); then echo "$z" – existem algumas coisas acontecendo nesta seção, mas é essencialmente: “Se o script de instalação assinado criptografadamente baixado do ZeroTier.com passar pelo GPG e não for rejeitado como não assinado pelo ZeroTier, colar essa informação na tela.”
      • sudo bash; fi – esta seção recebe o script de instalação recentemente validado e executa-o antes de finalizar a rotina.

      Aviso: você nunca deve baixar algo da internet e canalizar em outro programa a menos que tenha certeza de que ele vem de uma fonte confiável. Se quiser, você pode inspecionar o software do ZeroTier revisando o código fonte na página oficial do projeto no GitHub.

      Use um Console SSH para se conectar ao seu servidor recém-criado e execute o seguinte comando como seu usuário normal (uma explicação do comando é fornecida abaixo). Certifique-se de que você não execute ele como raiz, já que o script solicita automaticamente sua senha para aumentar seu nível de privilégios e lembre-se de manter o console do ZeroTier aberto no seu navegador para que possa interagir com ele quando necessário.

      • curl -s 'https://pgp.mit.edu/pks/lookup?op=get&search=0x1657198823E52A61' | gpg --import && if z=$(curl -s 'https://install.zerotier.com/' | gpg); then echo "$z" | sudo bash; fi

      Assim que o script terminar, você verá duas linhas de resultado semelhantes às mostradas abaixo. Anote seu endereço ZeroTier (sem os colchetes) e o nome do sistema que gerou aquele endereço, ambos os quais serão necessários mais tarde:

      Output

      *** Waiting for identity generation... *** Success! You are ZeroTier address [ 916af8664d ].

      Repita este passo no seu computador local se usar o Ubuntu, ou siga os passos relevantes para seu sistema operacional na página de download do site do ZeroTier. Novamente, certifique-se de anotar o endereço do ZeroTier e a máquina que gerou aquele endereço. Você precisará dessas informações no próximo passo deste tutorial quando você ingressar seu servidor e cliente à rede.

      Passo 3 — Ingressando sua rede ZeroTier

      Agora que tanto o servidor como o cliente têm o software do ZeroTier em execução neles, você está pronto para conectá-los à rede que você criou no Web console do ZeroTier.

      Use o comando a seguir para instruir seu cliente a solicitar acesso à rede do ZeroTier através da sua plataforma. O pedido inicial do cliente será rejeitado e suspenso, mas vamos corrigir isso em breve. Certifique-se de substituir o NetworkID pelo ID da rede que você anotou mais cedo da janela de configuração da sua rede.

      • sudo zerotier-cli join NetworkID

      Output

      200 join OK

      Você receberá uma mensagem 200 join OK, confirmando que o serviço do ZeroTier no seu servidor entendeu o comando. Caso contrário, verifique novamente o ID da rede do ZeroTier que você digitou.

      Como não criou uma rede pública que qualquer um no mundo possa ingressar, você precisa agora autorizar seus clientes. Vá até o Console Web do ZeroTier e role para baixo até o fim, onde a seção Members está. Você deve ver duas entradas marcadas como Online, com os mesmos endereços que você mais cedo.

      Na primeira coluna marcada Auth?, marque as caixas para autorizá-los a participar da rede. O Controlador do Zerotier irá atribuir um endereço IP ao servidor e ao cliente do intervalo que você escolheu mais cedo na próxima vez que eles chamarem o SDN.

      A atribuição de endereços IP pode levar tempo. Enquanto espera, você pode fornecer um Short Name e Description para seus nós na seção Members.

      Com isso, você terá conectado dois sistemas à sua rede definida por software.

      Até agora, você ganhou uma familiarização básica com o painel de controle do ZeroTier, usou a interface da linha de comando para baixar e instalar o ZeroTier e, em seguida, anexou tanto o servidor quanto o cliente a essa rede. Em seguida, você irá verificar se tudo foi aplicado corretamente executando um teste de conectividade.

      Passo 4 — Verificando a conectividade

      Nesta fase, é importante validar que os dois hosts possam realmente conversar entre si. Há uma chance de que mesmo que os hosts aleguem ter ingressado na rede, eles não consigam se comunicar. Ao verificar a conectividade neste momento, você não terá que se preocupar com problemas básicos de interconectividade que poderiam causar problemas mais tarde.

      Uma maneira fácil de encontrar o endereço IP do ZeroTier de cada host é olhando na seção Members do Console Web do ZeroTier. Você pode precisar recarregá-lo após autorizar o servidor e cliente antes que seus endereços IP apareçam. De forma alternativa, você pode usar a linha de comando do Linux para encontrar esses endereços. Use o comando a seguir em ambas as máquinas — o primeiro endereço IP mostrado na lista é aquele a ser usado. No exemplo mostrado abaixo, esse endereço é 203.0.113.0.

      • ip addr sh zt0 | grep 'inet'

      Output

      inet 203.0.113.0/24 brd 203.0.255.255 scope global zt0 inet6 fc63:b4a9:3507:6649:9d52::1/40 scope global inet6 fe80::28e4:7eff:fe38:8318/64 scope link

      Para testar a conectividade entre os hosts, execute o comando ping de um host seguido do endereço IP do outro. Por exemplo, no cliente:

      E no servidor:

      Se as respostas estiverem sendo devolvidas do host oposto (como mostrado no resultado abaixo), então os dois nós estão se comunicando com sucesso pelo SDN.

      Output

      PING 203.0.113.0 (203.0.113.0) 56(84) bytes of data. 64 bytes from 203.0.113.0: icmp_seq=1 ttl=64 time=0.054 ms 64 bytes from 203.0.113.0: icmp_seq=2 ttl=64 time=0.046 ms 64 bytes from 203.0.113.0: icmp_seq=3 ttl=64 time=0.043 ms

      Você pode adicionar quantas máquinas quiser nesta configuração repetindo a instalação do ZeroTier e os processos de ingressão evidenciados acima. Lembre-se, essas máquinas não precisam de forma alguma estar próximas.

      Agora que você confirmou que seu servidor e cliente podem se comunicar entre si, continue lendo para aprender como ajustar a rede para fornecer um gateway de saída e construir seu próprio VPN.

      Passo 5 — Habilitando a capacidade VPN do ZeroTier

      Como mencionado na introdução, é possível usar o ZeroTier como uma ferramenta VPN. Se você não planeja usar o usuário ZeroTier como uma solução VPN, não será necessário que siga esse passo, podendo pular para o Passo 6.

      Ao usar um VPN, a fonte de suas comunicações com websites na internet fica escondida. Ele permite que você ignore os filtros e restrições que podem existir na rede que está usando. Para a internet como um todo, irá parecer que você está navegando a partir do endereço IP público do seu servidor. Para usar o ZeroTier como uma ferramenta VPN, será necessário fazer mais algumas alterações nas configurações do seu servidor e cliente.

      Como habilitar a Network Address Translation e o encaminhamento de IP

      O Network Address Translation, mais comumente conhecido como “NAT”, é um método pelo qual um roteador aceita pacotes em uma interface marcada com o endereço IP do remetente e, em seguida, troca aquele endereço pelo do roteador. Um registro desta troca é mantido na memória do roteador para que quando o tráfego de retorno volte na direção oposta, o roteador possa traduzir o IP de volta para seu endereço original. O NAT é normalmente usado para permitir que vários computadores operem por trás de um endereço IP exposto publicamente, o que acaba sendo útil para um serviço VPN. Um exemplo do NAT na prática é o roteador doméstico que seu provedor de serviço de internet deu a você para conectar todos os dispositivos em seu lar à Internet. Seu notebook, telefone, tablets e qualquer outro dispositivo que consiga se conectar à Internet. Todos parecem compartilhar o mesmo endereço IP público para a Internet, porque seu roteador está executando o NAT.

      Embora o NAT seja normalmente conduzido por um roteador, ele também pode ser executado por um servidor. Ao longo deste passo, você irá potencializar essa funcionalidade no seu servidor do ZeroTier para habilitar suas capacidades VPN.

      O encaminhamento de IP é uma função realizada por um roteador ou servidor na qual ele encaminha o tráfego de uma interface para outra como se esses endereços IP estivessem em diferentes zonas. Se um roteador estiver conectado a duas redes, o encaminhamento de IP permite que ele encaminhe o tráfego entre elas. Isso pode parecer simples, mas implementar isso com sucesso pode ser surpreendentemente complicado. No entanto, no caso deste tutorial, é apenas uma questão de editar alguns arquivos de configuração.

      Ao habilitar o encaminhamento de IP, o tráfego VPN do seu cliente na rede do ZeroTier chegará na interface do ZeroTier do servidor. Sem essas configurações, o Kernel Linux irá (por padrão) jogar fora qualquer pacote que não seja destinado para a interface em que eles chegam. Esse comportamento é normal para o Kernel Linux,já que normalmente qualquer pacote que esteja chegando em uma interface que tenha um endereço de destino para outra rede pode ter como causa um erro de configuração do roteamento em outro lugar na rede.

      É útil encaminhar o IP de forma a informar o Kernel Linux de que é aceitável encaminhar pacotes entre as interfaces. A configuração padrão é 0 — equivalente a “Desligado”. Você irá alterar isso para 1 — equivalente a “Ligado”.

      Para ver a configuração atual, execute o seguinte comando:

      • sudo sysctl net.ipv4.ip_forward

      Output

      net.ipv4.ip_forward = 0

      Para habilitar o encaminhamento de IP, modifique o arquivo /etc/sysctl.conf no seu servidor e adicione a linha necessária. Este arquivo de configuração permite que um administrador substitua as configurações padrão do kernel, e ele sempre será aplicado após as reinicializações, então não será necessário se preocupar em configurá-lo novamente. Use o nano ou seu editor de texto favorito para adicionar a seguinte linha ao final do arquivo.

      • sudo nano /etc/sysctl.conf

      /etc/sysctl.conf

      . . .
      net.ipv4.ip_forward = 1
      

      Salve, feche o arquivo e depois execute o próximo comando para fazer com que o kernel adote suas novas configurações.

      O servidor adotará quaisquer novas diretrizes de configuração dentro do arquivo e irá aplicá-las imediatamente, sem a necessidade de uma reinicialização. Execute o mesmo comando que você fez anteriormente e verá que o encaminhamento de IP está ativo.

      • sudo sysctl net.ipv4.ip_forward

      Output

      net.ipv4.ip_forward = 1

      Agora que o encaminhamento de IP está ativo, faça bom uso dele fornecendo algumas regras básicas de roteamento do servidor. Como o Kernel Linux já tem uma capacidade de roteamento de rede incorporada dentro dele, tudo o que terá que fazer é adicionar algumas regras para informar o firewall integrado e o roteador que o novo tráfego que estarão vendo é aceitável e para onde enviá-lo.

      Para adicionar essas regras da linha de comando, será necessário primeiro conhecer os nomes que o Ubuntu atribuiu tanto para sua interface Zerotier como sua interface ethernet comum de acesso a Internet. Normalmente, eles são zt0 e eth0 respectivamente, embora nem sempre esse seja o caso.

      Para encontrar os nomes dessas interfaces, utilize o comando ip link show. Este utilitário de linha de comando faz parte do iproute2, uma coleção de utilitários de userspace que vem instalada no Ubuntu por padrão:

      No resultado deste comando, os nomes das interfaces estão diretamente ao lado dos números que identificam uma interface única na lista. Estes nomes de interface estão destacados no seguinte exemplo de resultado. Se os seus nomes diferem dos nomes mostrados no exemplo, substitua seu nome de interface apropriadamente durante este guia.

      Output

      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 72:2d:7e:6f:5e:08 brd ff:ff:ff:ff:ff:ff 3: zt0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000 link/ether be:82:8f:f3:b4:cd brd ff:ff:ff:ff:ff:ff

      Com essas informações em mãos, utilize o iptables para habilitar o Network-Address-Translation e o mascaramento de IP:

      • sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

      Permita o encaminhamento de tráfego e rastreie conexões ativas:

      • sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

      Em seguida, autorize o encaminhamento de tráfego do zt0 para o eth0. Uma regra reversa não é necessária, já que neste tutorial supõe-se que o cliente sempre faça chamadas pelo servidor, e não o contrário:

      • sudo iptables -A FORWARD -i zt0 -o eth0 -j ACCEPT

      É importante lembrar que as regras do iptables que você definiu para o servidor não persistem automaticamente entre as reinicializações. Você precisará salvar essas regras para garantir que elas sejam trazidas de volta, caso o servidor seja alguma vez reinicializado. No seu servidor, execute os comandos abaixo, seguindo as breves instruções na tela para salvar as regras atuais do IPv4. O mesmo não é necessário para o IPv6.

      • sudo apt-get install iptables-persistent
      • sudo netfilter-persistent save

      Após executar o sudo netfilter-persistent save, pode ser vantajoso reiniciar seu servidor para validar o salvamento correto das regras do iptables. Uma maneira fácil de verificar é executando o sudo iptables-save, que irá transferir as configurações atuais carregadas em memória para o seu terminal. Se você ver regras semelhantes às que estão abaixo em relação ao mascaramento, encaminhamento e a interface zt0, então elas foram salvas corretamente.

      Output

      # Generated by iptables-save v1.6.0 on Tue Apr 17 21:43:08 2018 . . . -A POSTROUTING -o eth0 -j MASQUERADE COMMIT . . . -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i zt0 -o eth0 -j ACCEPT COMMIT . . .

      Agora que essas regras foram aplicadas no seu servidor, ele está pronto para manipular o tráfego entre a rede do ZeroTier e a internet pública. No entanto, o VPN não funcionará a menos que a rede do ZeroTier seja informada de que o servidor está pronto para ser usado como um gateway.

      Como habilitar seu servidor para gerenciar a rota global

      Para que seu servidor possa processar o tráfego de qualquer cliente, é preciso garantir que outros clientes na rede do ZeroTier saibam e enviem seus tráfegos à ele. Pode-se fazer isso configurando uma rota global no Console do ZeroTier. As pessoas que estão familiares com redes de computadores também podem descrever isso como uma Default Route. É onde qualquer cliente envia seu tráfego padrão, ou seja, qualquer tráfego que não deva ir para qualquer outro local específico.

      Vá até o lado direito superior da sua página da rede do ZeroTier e adicione uma nova rota com os seguintes parâmetros. Você pode encontrar o IP do ZeroTier para seu servidor na seção Members da sua página de configuração da rede do ZeroTier. No campo network/bits, digite 0.0.0.0/0, no campo (LAN), digite o endereço IP do seu servidor ZeroTier.

      Quando os detalhes estiverem no lugar, clique no símbolo “+” e você verá uma nova regra aparecer abaixo da existente. Haverá um globo laranja nela para informar que ela é, de fato, uma rota global:

      Global Route Rule

      Com sua rede do ZeroTier pronta para funcionar, há apenas uma configuração a ser feita para que o VPN funcione: a dos clientes.

      Configurando clientes Linux

      Nota: os comandos nesta seção são aplicáveis apenas aos clientes Linux. As instruções para configurar os clientes Windows ou macOS são fornecidas na próxima seção.

      Se seu cliente estiver executando o Linux, será necessário fazer uma alteração manual no seu arquivo /etc/sysctl.conf. Esta mudança de configuração é necessária para alterar a visualização do kernel sobre o qual é um caminho de volta aceitável para o tráfego do seu cliente. Devido ao modo como o VPN do ZeroTier é configurado, o tráfego que volta do seu servidor para seu cliente pode, por vezes, parecer vir de um endereço de rede diferente daquele para o qual foi enviado. Por padrão, o Kernel Linux as vê como inválidas e as elimina, tornando necessário sobrepor esse comportamento.

      Abra o /etc/sysctl.conf na sua máquina do cliente:

      • sudo nano /etc/sysctl.conf

      Então, adicione a seguinte linha:

      Output

      . . . net.ipv4.conf.all.rp_filter=2

      Salve, feche o arquivo e depois execute o sudo sysctl -p para adotar as alterações.

      Em seguida, diga ao software de cliente do ZeroTier que sua rede tem permissão para transportar o tráfego da rota padrão. Isso altera o roteamento do cliente e, portanto, é considerado uma função privilegiada, razão pela qual deve ser habilitada manualmente. O comando imprimirá uma estrutura de configuração na saída. Verifique-a para confirmar que mostra o allowDefault=1 no topo:

      • sudo zerotier-cli set NetworkID allowDefault=1

      Se em qualquer momento você quiser parar de usar o ZeroTier como um VPN com todo seu roteamento de tráfego passando por ele, defina allowDefault de volta para 0:

      • sudo zerotier-cli set NetworkID allowDefault=0

      Cada vez que o serviço do ZeroTier no cliente for reiniciado, o valor allowDefault=1 retorna para 0, portanto lembre-se de executá-lo novamente para ativar a funcionalidade VPN.

      Por padrão, o serviço do ZeroTier é definido para iniciar automaticamente na inicialização para tanto o cliente Linux quanto o servidor. Se você não quiser que isso aconteça, desative a rotina de inicialização com o seguinte comando.

      • sudo systemctl disable zerotier-one

      Se quiser usar outros sistemas operacionais na sua rede do ZeroTier, continue lendo na próxima seção. Caso contrário, pule para a seção Como gerenciar fluxos.

      Como configurar clientes não Linux

      O software de cliente do ZeroTier está disponível para muitos sistemas e não apenas para o SO do Linux — até os smartphones são suportados. Os clientes existem para sistemas Windows, macOS, Android, iOS e até mesmo sistemas operacionais especializados como o QNAP, Synology e sistemas NAS da WesternDigital.

      Para ingressar clientes baseados em macOS e Windows na rede, inicie a ferramenta do ZeroTier (que você instalou no Passo 1) e digite sua NetworkID no campo fornecido antes de clicar em Join. Lembre-se de voltar no console do ZeroTier para marcar o botão Allow para autorizar um novo host na sua rede.

      Certifique-se de marcar a caixa rotulada Route all traffic through ZeroTier. Se não o fizer, seu cliente estará anexado à sua rede do ZeroTier, mas não tentará enviar seu tráfego de internet através dela.

      Use uma ferramenta de verificação de IP como a ICanHazIP para verificar se seu tráfego está aparecendo na internet a partir do IP do seu servidor. Para verificar isso, cole o seguinte URL na barra de endereço do seu navegador. Este site mostrará o endereço IP que seu servidor (e o resto da Internet) vê você usando para acessar o site:

      http://icanhazip.com
      

      Com esses passos concluídos, você pode começar a utilizar seu VPN como quiser. A próxima seção opcional aborda uma tecnologia integrada ao SDN do ZeroTier conhecida como “regras de fluxo”, mas não são de forma alguma necessárias para que a funcionalidade VPN funcione.

      Passo 6 — Gerenciando fluxos (Opcional)

      Um dos benefícios de uma rede definida por software é o controle centralizado. No que diz respeito ao ZeroTier, o controle centralizado é a interface do usuário Web que fica no topo do serviço geral SDN do ZeroTier. A partir dessa interface, é possível escrever regras conhecidas como flow rules, que especificam o tráfego que uma rede pode ou não pode fazer. Por exemplo, você pode especificar uma proibição geral em certas portas de rede que transportam tráfego na rede, limitar os hosts que podem conversar uns com os outros e até mesmo redirecionar o tráfego.

      Esta é uma capacidade extremamente poderosa que entra em vigor quase instantaneamente, já que quaisquer alterações feitas na tabela de fluxo são enviadas aos membros da rede e produzem efeitos após alguns instantes. Para editar as regras de fluxo, volte para a Interface do usuário Web do ZeroTier, clique na aba Networking e role para baixo até ver uma caixa chamada Flow Rules (pode estar recolhida e precisar ser expandida) Isso abre um campo de texto onde você pode digitar as regras que quiser. Um manual completo está disponível dentro do console do ZeroTier em uma caixa abaixo da caixa de entrada Flow Rules, intitulado Rules Engine Help.

      Aqui estão algumas regras para servir de exemplo para ajudar você a explorar essa funcionalidade.

      Para bloquear qualquer tráfego que seja ligado ao servidor DNS do Google 8.8.8.8, adicione essa regra:

      drop
          ipdest 8.8.8.8/32
      ;
      

      Para redirecionar qualquer tráfego que seja ligado ao servidor DNS público do Google para um dos seus nós do ZeroTier, adicione a seguinte regra. Isso pode ser um excelente ponto de captura para substituir pesquisas de DNS:

      redirect NetworkID
          ipdest 8.8.8.8/32
      ;
      

      Se sua rede tiver requisitos especiais de segurança, você pode remover quaisquer atividades nas portas FTP, Telnet e HTTP não criptografada, adicionando essa regra:

      drop
          dport 80,23,21,20
      ;
      

      Quando terminar de adicionar as regras de fluxo, clique no botão Save Changes e o ZeroTier irá gravar suas alterações.

      Conclusão

      Neste tutorial, você deu um primeiro passo no mundo das Redes Definidas por Software. Trabalhar com o ZeroTier fornece alguns insights sobre os benefícios dessa tecnologia. Se seguiu o exemplo VPN, e embora a configuração inicial possa contrastar de outras ferramentas que você possa ter usado no passado, a facilidade em adicionar clientes adicionais pode ser uma razão convincente para usar a tecnologia em outro lugar.

      Para resumir, você aprendeu como usar o ZeroTier como um provedor SDN, além de configurar e anexar nós a essa rede. O elemento VPN fará você compreender mais profundamente como o roteamento dentro de uma rede dessas funciona e ambos os caminhos neste tutorial permitirão que utilize a poderosa tecnologias das regras de fluxo.

      Agora que uma rede ponto a ponto existe, é possível combiná-la com outra funcionalidade, como o Compartilhamento de arquivos. Se você tiver um NAS ou servidor de arquivos em casa, você pode vinculá-lo ao ZeroTier e acessá-lo fora de casa. Se quiser compartilhá-lo com seus amigos, mostre a eles como ingressar na sua rede do ZeroTier. Os funcionários que estão distribuídos em uma grande área poderiam até mesmo vincular-se ao mesmo espaço de armazenamento central. Para começar a construir o compartilhamento de arquivos para qualquer um desses exemplos, consulte Como configurar uma Samba Share para uma organização pequena no Ubuntu 16.04.



      Source link

      Kubernetes Networking Under the Hood


      Introduction

      Kubernetes is a powerful container orchestration system that can manage the deployment and operation of containerized applications across clusters of servers. In addition to coordinating container workloads, Kubernetes provides the infrastructure and tools necessary to maintain reliable network connectivity between your applications and services.

      The Kubernetes cluster networking documentation states that the basic requirements of a Kubernetes network are:

      • all containers can communicate with all other containers without NAT
      • all nodes can communicate with all containers (and vice-versa) without NAT
      • the IP that a container sees itself as is the same IP that others see it as

      In this article we will discuss how Kubernetes satisfies these networking requirements within a cluster: how data moves inside a pod, between pods, and between nodes.

      We will also show how a Kubernetes Service can provide a single static IP address and DNS entry for an application, easing communication with services that may be distributed among multiple constantly scaling and shifting pods.

      If you are unfamiliar with the terminology of Kubernetes pods and nodes or other basics, our article An Introduction to Kubernetes covers the general architecture and components involved.

      Let’s first take a look at the networking situation within a single pod.

      Pod Networking

      In Kubernetes, a pod is the most basic unit of organization: a group of tightly-coupled containers that are all closely related and perform a single function or service.

      Networking-wise, Kubernetes treats pods similar to a traditional virtual machine or a single bare-metal host: each pod receives a single unique IP address, and all containers within the pod share that address and communicate with each other over the lo loopback interface using the localhost hostname. This is achieved by assigning all of the pod’s containers to the same network stack.

      This situation should feel familiar to anybody who has deployed multiple services on a single host before the days of containerization. All the services need to use a unique port to listen on, but otherwise communication is uncomplicated and has low overhead.

      Pod to Pod Networking

      Most Kubernetes clusters will need to deploy multiple pods per node. Pod to pod communication may happen between two pods on the same node, or between two different nodes.

      Pod to Pod Communication on One Node

      On a single node you can have multiple pods that need to communicate directly with each other. Before we trace the route of a packet between pods, let’s inspect the networking setup of a node. The following diagram provides an overview, which we will walk through in detail:

      Networking overview of a single Kubernetes node

      Each node has a network interface – eth0 in this example – attached to the Kubernetes cluster network. This interface sits within the node’s root network namespace. This is the default namespace for networking devices on Linux.

      Just as process namespaces enable containers to isolate running applications from each other, network namespaces isolate network devices such as interfaces and bridges. Each pod on a node is assigned its own isolated network namespace.

      Pod namespaces are connected back to the root namespace with a virtual ethernet pair, essentially a pipe between the two namespaces with an interface on each end (here we’re using veth1 in the root namespace, and eth0 within the pod).

      Finally, the pods are connected to each other and to the node’s eth0 interface via a bridge, br0 (your node may use something like cbr0 or docker0). A bridge essentially works like a physical ethernet switch, using either ARP (address resolution protocol) or IP-based routing to look up other local interfaces to direct traffic to.

      Let’s trace a packet from pod1 to pod2 now:

      • pod1 creates a packet with pod2‘s IP as its destination
      • The packet travels over the virtual ethernet pair to the root network namespace
      • The packet continues to the bridge br0
      • Because the destination pod is on the same node, the bridge sends the packet to pod2‘s virtual ethernet pair
      • the packet travels through the virtual ethernet pair, into pod2‘s network namespace and the pod’s eth0 network interface

      Now that we’ve traced a packet from pod to pod within a node, let’s look at how pod traffic travels between nodes.

      Pod to Pod Communication Between Two Nodes

      Because each pod in a cluster has a unique IP, and every pod can communicate directly with all other pods, a packet moving between pods on two different nodes is very similar to the previous scenario.

      Let’s trace a packet from pod1 to pod3, which is on a different node:

      Networking diagram between two Kubernetes nodes

      • pod1 creates a packet with pod3‘s IP as its destination
      • The packet travels over the virtual ethernet pair to the root network namespace
      • The packet continues to the bridge br0
      • The bridge finds no local interface to route to, so the packet is sent out the default route toward eth0
      • Optional: if your cluster requires a network overlay to properly route packets to nodes, the packet may be encapsulated in a VXLAN packet (or other network virtualization technique) before heading to the network. Alternately, the network itself may be set up with the proper static routes, in which case the packet travels to eth0 and out the the network unaltered.
      • The packet enters the cluster network and is routed to the correct node.
      • The packet enters the destination node on eth0
      • Optional: if your packet was encapsulated, it will be de-encapsulated at this point
      • The packet continues to the bridge br0
      • The bridge routes the packet to the destination pod’s virtual ethernet pair
      • The packet passes through the virtual ethernet pair to the pod’s eth0 interface

      Now that we are familiar with how packets are routed via pod IP addresses, let’s take a look at Kubernetes services and how they build on top of this infrastructure.

      Pod to Service Networking

      It would be difficult to send traffic to a particular application using just pod IPs, as the dynamic nature of a Kubernetes cluster means pods can be moved, restarted, upgraded, or scaled in and out of existence. Additionally, some services will have many replicas, so we need some way to load balance between them.

      Kubernetes solves this problem with Services. A Service is an API object that maps a single virtual IP (VIP) to a set of pod IPs. Additionally, Kubernetes provides a DNS entry for each service’s name and virtual IP, so services can be easily addressed by name.

      The mapping of virtual IPs to pod IPs within the cluster is coordinated by the kube-proxy process on each node. This process sets up either iptables or IPVS to automatically translate VIPs into pod IPs before sending the packet out to the cluster network. Individual connections are tracked so packets can be properly de-translated when they return. IPVS and iptables can both do load balancing of a single service virtual IP into multiple pod IPs, though IPVS has much more flexibility in the load balancing algorithms it can use.

      Note: this translation and connection tracking processes happens entirely in the Linux kernel. kube-proxy reads from the Kubernetes API and updates iptables ip IPVS, but it is not in the data path for individual packets. This is more efficient and higher performance than previous versions of kube-proxy, which functioned as a user-land proxy.

      Let’s follow the route a packet takes from a pod, pod1 again, to a service, service1:

      Networking diagram between two Kubernetes nodes, showing DNAT translation of virtual IPs

      • pod1 creates a packet with service1‘s IP as its destination
      • The packet travels over the virtual ethernet pair to the root network namespace
      • The packet continues to the bridge br0
      • The bridge finds no local interface to route the packet to, so the packet is sent out the default route toward eth0
      • Iptables or IPVS, set up by kube-proxy, match the packet’s destination IP and translate it from a virtual IP to one of the service’s pod IPs, using whichever load balancing algorithms are available or specified
      • Optional: your packet may be encapsulated at this point, as discussed in the previous section
      • The packet enters the cluster network and is routed to the correct node.
      • The packet enters the destination node on eth0
      • Optional: if your packet was encapsulated, it will be de-encapsulated at this point
      • The packet continues to the bridge br0
      • The packet is sent to the virtual ethernet pair via veth1
      • The packet passes through the virtual ethernet pair and enters the pod network namespace via its eth0 network interface

      When the packet returns to node1 the VIP to pod IP translation will be reversed, and the packet will be back through the bridge and virtual interface to the correct pod.

      Conclusion

      In this article we’ve reviewed the internal networking infrastructure of a Kubernetes cluster. We’ve discussed the building blocks that make up the network, and detailed the hop-by-hop journey of packets in different scenarios.

      For more information about Kubernetes, take a look at our Kubernetes tutorials tag and the official Kubernetes documentation.



      Source link

      How To Inspect Kubernetes Networking


      Introduction

      Kubernetes is a container orchestration system that can manage containerized applications across a cluster of server nodes. Maintaining network connectivity between all the containers in a cluster requires some advanced networking techniques. In this article, we will briefly cover some tools and techniques for inspecting this networking setup.

      These tools may be useful if you are debugging connectivity issues, investigating network throughput problems, or exploring Kubernetes to learn how it operates.

      If you want to learn more about Kubernetes in general, our guide An Introduction to Kubernetes covers the basics. For a networking-specific overview of Kubernetes, please read Kubernetes Networking Under the Hood.

      Getting Started

      This tutorial will assume that you have a Kubernetes cluster, with kubectl installed locally and configured to connect to the cluster.

      The following sections contain many commands that are intended to be run on a Kubernetes node. They will look like this:

      • echo 'this is a node command'

      Commands that should be run on your local machine will have the following appearance:

      • echo 'this is a local command'

      Note: Most of the commands in this tutorial will need to be run as the root user. If you instead use a sudo-enabled user on your Kubernetes nodes, please add sudo to run the commands when necessary.

      Finding a Pod’s Cluster IP

      To find the cluster IP address of a Kubernetes pod, use the kubectl get pod command on your local machine, with the option -o wide. This option will list more information, including the node the pod resides on, and the pod’s cluster IP.

      Output

      NAME READY STATUS RESTARTS AGE IP NODE hello-world-5b446dd74b-7c7pk 1/1 Running 0 22m 10.244.18.4 node-one hello-world-5b446dd74b-pxtzt 1/1 Running 0 22m 10.244.3.4 node-two

      The IP column will contain the internal cluster IP address for each pod.

      If you don't see the pod you're looking for, make sure you're in the right namespace. You can list all pods in all namespaces by adding the flag --all-namespaces.

      Finding a Service's IP

      We can find a Service IP using kubectl as well. In this case we will list all services in all namespaces:

      • kubectl get service --all-namespaces

      Output

      NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE default kubernetes ClusterIP 10.32.0.1 <none> 443/TCP 6d kube-system csi-attacher-doplugin ClusterIP 10.32.159.128 <none> 12345/TCP 6d kube-system csi-provisioner-doplugin ClusterIP 10.32.61.61 <none> 12345/TCP 6d kube-system kube-dns ClusterIP 10.32.0.10 <none> 53/UDP,53/TCP 6d kube-system kubernetes-dashboard ClusterIP 10.32.226.209 <none> 443/TCP 6d

      The service IP can be found in the CLUSTER-IP column.

      Finding and Entering Pod Network Namespaces

      Each Kubernetes pod gets assigned its own network namespace. Network namespaces (or netns) are a Linux networking primitive that provide isolation between network devices.

      It can be useful to run commands from within a pod's netns, to check DNS resolution or general network connectivity. To do so, we first need to look up the process ID of one of the containers in a pod. For Docker, we can do that with a series of two commands. First, list the containers running on a node:

      Output

      CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 173ee46a3926 gcr.io/google-samples/node-hello "/bin/sh -c 'node se…" 9 days ago Up 9 days k8s_hello-world_hello-world-5b446dd74b-pxtzt_default_386a9073-7e35-11e8-8a3d-bae97d2c1afd_0 11ad51cb72df k8s.gcr.io/pause-amd64:3.1 "/pause" 9 days ago Up 9 days k8s_POD_hello-world-5b446dd74b-pxtzt_default_386a9073-7e35-11e8-8a3d-bae97d2c1afd_0 . . .

      Find the container ID or name of any container in the pod you're interested in. In the above output we're showing two containers:

      • The first container is the hello-world app running in the hello-world pod
      • The second is a pause container running in the hello-world pod. This container exists solely to hold onto the pod's network namespace

      To get the process ID of either container, take note of the container ID or name, and use it in the following docker command:

      • docker inspect --format '{{ .State.Pid }}' container-id-or-name

      Output

      14552

      A process ID (or PID) will be output. Now we can use the nsenter program to run a command in that process's network namespace:

      • nsenter -t your-container-pid -n ip addr

      Be sure to use your own PID, and replace ip addr with the command you'd like to run inside the pod's network namespace.

      Note: One advantage of using nsenter to run commands in a pod's namespace – versus using something like docker exec – is that you have access to all of the commands available on the node, instead of the typically limited set of commands installed in containers.

      Finding a Pod's Virtual Ethernet Interface

      Each pod's network namespace communicates with the node's root netns through a virtual ethernet pipe. On the node side, this pipe appears as a device that typically begins with veth and ends in a unique identifier, such as veth77f2275 or veth01. Inside the pod this pipe appears as eth0.

      It can be useful to correlate which veth device is paired with a particular pod. To do so, we will list all network devices on the node, then list the devices in the pod's network namespace. We can then correlate device numbers between the two listings to make the connection.

      First, run ip addr in the pod's network namespace using nsenter. Refer to the previous section Finding and Entering Pod Network Namespaces
      for details on how to do this:

      • nsenter -t your-container-pid -n ip addr

      Output

      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 10: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default link/ether 02:42:0a:f4:03:04 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.244.3.4/24 brd 10.244.3.255 scope global eth0 valid_lft forever preferred_lft forever

      The command will output a list of the pod's interfaces. Note the if11 number after eth0@ in the example output. This means this pod's eth0 is linked to the node's 11th interface. Now run ip addr in the node's default namespace to list out its interfaces:

      Output

      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever . . . 7: veth77f2275@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master docker0 state UP group default link/ether 26:05:99:58:0d:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet6 fe80::2405:99ff:fe58:db9/64 scope link valid_lft forever preferred_lft forever 9: vethd36cef3@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master docker0 state UP group default link/ether ae:05:21:a2:9a:2b brd ff:ff:ff:ff:ff:ff link-netnsid 1 inet6 fe80::ac05:21ff:fea2:9a2b/64 scope link valid_lft forever preferred_lft forever 11: veth4f7342d@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master docker0 state UP group default link/ether e6:4d:7b:6f:56:4c brd ff:ff:ff:ff:ff:ff link-netnsid 2 inet6 fe80::e44d:7bff:fe6f:564c/64 scope link valid_lft forever preferred_lft forever

      The 11th interface is veth4f7342d in this example output. This is the virtual ethernet pipe to the pod we're investigating.

      Inspecting Conntrack Connection Tracking

      Prior to version 1.11, Kubernetes used iptables NAT and the conntrack kernel module to track connections. To list all the connections currently being tracked, use the conntrack command:

      To watch continuously for new connections, use the -E flag:

      To list conntrack-tracked connections to a particular destination address, use the -d flag:

      • conntrack -L -d 10.32.0.1

      If your nodes are having issues making reliable connections to services, it's possible your connection tracking table is full and new connections are being dropped. If that's the case you may see messages like the following in your system logs:

      /var/log/syslog

      Jul 12 15:32:11 worker-528 kernel: nf_conntrack: table full, dropping packet.
      

      There is a sysctl setting for the maximum number of connections to track. You can list out your current value with the following command:

      • sysctl net.netfilter.nf_conntrack_max

      Output

      net.netfilter.nf_conntrack_max = 131072

      To set a new value, use the -w flag:

      • sysctl -w net.netfilter.nf_conntrack_max=198000

      To make this setting permanent, add it to the sysctl.conf file:

      /etc/sysctl.conf

      . . .
      net.ipv4.netfilter.ip_conntrack_max = 198000
      

      Inspecting Iptables Rules

      Prior to version 1.11, Kubernetes used iptables NAT to implement virtual IP translation and load balancing for Service IPs.

      To dump all iptables rules on a node, use the iptables-save command:

      Because the output can be lengthy, you may want to pipe to a file (iptables-save > output.txt) or a pager (iptables-save | less) to more easily review the rules.

      To list just the Kubernetes Service NAT rules, use the iptables command and the -L flag to specify the correct chain:

      • iptables -t nat -L KUBE-SERVICES

      Output

      Chain KUBE-SERVICES (2 references) target prot opt source destination KUBE-SVC-TCOU7JCQXEZGVUNU udp -- anywhere 10.32.0.10 /* kube-system/kube-dns:dns cluster IP */ udp dpt:domain KUBE-SVC-ERIFXISQEP7F7OF4 tcp -- anywhere 10.32.0.10 /* kube-system/kube-dns:dns-tcp cluster IP */ tcp dpt:domain KUBE-SVC-XGLOHA7QRQ3V22RZ tcp -- anywhere 10.32.226.209 /* kube-system/kubernetes-dashboard: cluster IP */ tcp dpt:https . . .

      Querying Cluster DNS

      One way to debug your cluster DNS resolution is to deploy a debug container with all the tools you need, then use kubectl to exec nslookup on it. This is described in the official Kubernetes documentation.

      Another way to query the cluster DNS is using dig and nsenter from a node. If dig is not installed, it can be installed with apt on Debian-based Linux distributions:

      First, find the cluster IP of the kube-dns service:

      • kubectl get service -n kube-system kube-dns

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 10.32.0.10 <none> 53/UDP,53/TCP 15d

      The cluster IP is highlighted above. Next we'll use nsenter to run dig in the a container namespace. Look at the section Finding and Entering Pod Network Namespaces for more information on this:

      • nsenter -t 14346 -n dig kubernetes.default.svc.cluster.local @10.32.0.10

      This dig command looks up the Service's full domain name of service-name.namespace.svc.cluster.local and specifics the IP of the cluster DNS service IP (@10.32.0.10).

      Looking at IPVS Details

      As of Kubernetes 1.11, kube-proxy can configure IPVS to handle the translation of virtual Service IPs to pod IPs. You can list the translation table of IPs with ipvsadm:

      Output

      IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 100.64.0.1:443 rr -> 178.128.226.86:443 Masq 1 0 0 TCP 100.64.0.10:53 rr -> 100.96.1.3:53 Masq 1 0 0 -> 100.96.1.4:53 Masq 1 0 0 UDP 100.64.0.10:53 rr -> 100.96.1.3:53 Masq 1 0 0 -> 100.96.1.4:53 Masq 1 0 0

      To show a single Service IP, use the -t option and specify the desired IP:

      • ipvsadm -Ln -t 100.64.0.10:53

      Output

      Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 100.64.0.10:53 rr -> 100.96.1.3:53 Masq 1 0 0 -> 100.96.1.4:53 Masq 1 0 0

      Conclusion

      In this article we’ve reviewed some commands and techniques for exploring and inspecting the details of your Kubernetes cluster's networking. For more information about Kubernetes, take a look at our Kubernetes tutorials tag and the official Kubernetes documentation.



      Source link