Duas LAN no NetBird: quais pares encaminham e quem pode falar

Uma estação de trabalho na LAN oeste abre um navegador, escreve o endereço de uma aplicação na LAN leste e espera até expirar o tempo. Todos os ecrãs do NetBird dizem que os pares estão ligados, o que é verdade e irrelevante: estar numa rede sobreposta não é o mesmo que ter as duas sub-redes locais numa só rede. O percurso abaixo começa nessa estação de trabalho e termina com um pedido que o projeto recusa de propósito, e cada paragem é algo que se lê de um dispositivo em vez de se adivinhar. Espere que a peça em falta seja uma rota ou uma política, não a sobreposição.

Leia primeiro a falha a partir da estação de trabalho

Antes de abrir a consola de gestão, determine o que a estação de trabalho envia realmente. A sua própria tabela de encaminhamento decide se o pacote vai para o gateway do site, para uma interface local ou para nenhum lado, e essa decisão é visível sem qualquer ferramenta de sobreposição. Uma máquina sem rota para o prefixo remoto falhará, por muito saudável que pareça a lista de pares. O intervalo da sobreposição e o prefixo do próprio site são espaços de endereços diferentes, e o registo configurou apenas um deles.

Depois separe a resolução de nomes da acessibilidade, porque o navegador relata ambas como o mesmo tempo esgotado. Repita o pedido por endereço a partir de uma máquina com o cliente NetBird e depois de uma estação de trabalho normal sem ele. Se a máquina registada tiver êxito e a normal falhar, a lacuna está no encaminhamento local; se ambas falharem, continue a ler antes de mudar uma rota.

Escolha um par de encaminhamento por site

Um par de encaminhamento é um anfitrião que representa a sua LAN na sobreposição, por isso escolha uma máquina Linux com acessibilidade estável à sub-rede em vez da estação de trabalho de alguém. Registe-a pelo processo normal e coloque-a num grupo com o nome da função, porque o recurso de rede e a política vão ambos referir esse grupo. Um representante por site continua legível; uma multidão de voluntários a anunciar o mesmo prefixo transforma cada pergunta posterior numa sessão de depuração. O endereço do par no segmento local importa tanto como a sua identidade na sobreposição, porque esse endereço torna-se o próximo salto que é dito a cada dispositivo normal.

Escreva o plano antes de tocar na consola, porque os nomes e os prefixos são onde estes projetos derivam: prefixo, gateway, endereço do par e grupo, por site. O oeste é 10.52.0.0/24 servido por 10.52.0.5 e o leste é 10.63.0.0/24 servido por 10.63.0.5; os dois grupos são west-routers e east-routers, e nenhum prefixo pode sobrepor-se ao outro, ao intervalo da sobreposição ou a outro destino encaminhado.

Crie o recurso, mantenha o mascaramento

No painel implementado, crie um recurso de rede por site e anexe-lhe o grupo de pares de encaminhamento desse site. O recurso é o prefixo e o grupo é o anfitrião que responde por ele, e ambos têm de existir antes de se anunciar algo. Confirme que a versão autoalojada implementada tem o fluxo de trabalho Redes, porque uma interface mais antiga com um objeto de rota de nome semelhante é outra funcionalidade.

Deixe o mascaramento ativo. O guia do NetBird para site a site exige-o nesta disposição, e desativá-lo para manter visível cada endereço original não é o mesmo projeto com um salto menos; muda o que as verificações de origem e as políticas da sobreposição observam. A consequência merece ser dita sem rodeios: o serviço recetor regista o par de encaminhamento como origem, não a estação de trabalho individual. Se a lista de permitidos ou a auditoria desse serviço espera endereços de estações de trabalho, ou muda a expectativa ou a identidade tem de ser imposta na fronteira do site antes da tradução.

Autorize os iniciadores, não os prefixos

Uma rota torna um endereço alcançável e uma política decide quem o pode usar; são dois objetos separados com proprietários separados. Escreva a política a partir da carga de trabalho para trás: que grupo inicia, que recurso aponta e que serviço TCP precisa. Uma rede que anuncia ambos os prefixos a cada par registado criou alcance e não resolveu nada.

Depois leia o que mais já é permitido, porque uma regra nova estreita não revoga uma ampla antiga que está por cima. Quando o leste também tiver de iniciar ligações para oeste, escreva essa direção como política própria; o tráfego de retorno de uma sessão aberta pelo oeste é uma pergunta diferente de permitir sessões novas para leste. Se só algumas estações de trabalho oeste devem chegar à aplicação leste, selecione-as na fronteira do site antes da tradução e mantenha a autenticação própria da aplicação. O par de encaminhamento transporta o tráfego da LAN como o site inteiro e não como identidade de sobreposição por utilizador, por isso a contabilidade por utilizador tem de vir de outro lugar.

Ensine a cada gateway o próximo salto e depois teste uma recusa

Os dispositivos normais nunca veem a sobreposição, por isso o próprio gateway precisa de uma rota estática que aponte o prefixo remoto para o endereço LAN do par de encaminhamento. É este o passo que as pessoas saltam, porque tudo o que é visível dentro do NetBird já funciona enquanto as estações de trabalho normais ainda expiram. O gateway mantém a rota predefinida como estava; este prefixo é um acrescento, não uma substituição.

As duas descrições de rota pertencem à configuração do gateway de cada site, não a uma exceção no anfitrião. Ambas são rotas estáticas normais e nenhuma toca na rota predefinida:

west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5

Teste com a aplicação de que o projeto precisa de facto, a partir de uma estação de trabalho normal, e registe três coisas: o próximo salto escolhido no lado emissor, a política que coincidiu e o endereço de origem que o serviço registou. Teste também uma recusa, porque um projeto que nunca recusou nada tem arestas desconhecidas, e a recusa é a única prova de que é a política e não o encaminhamento que faz o trabalho. Quando o leste também tiver de iniciar, comece uma ligação nova desse lado em vez de supor que a segunda direção segue. Planeie também o reinício, a atualização e a substituição do par de encaminhamento, porque um anfitrião passou a ser uma dependência do site.

Os nomes privados precisam do seu próprio desenho de resolução, porque o alcance não cria registos DNS e um caminho IP funcional com um nome quebrado lê-se exatamente como um caminho quebrado. Se um par de encaminhamento correr dentro de uma rede de nuvem, reveja também as regras de reencaminhamento e de firewall do fornecedor, porque o registo não as anula. Guarde as observações do teste junto ao plano, porque a próxima pessoa que depurar isto vai querer a política coincidente e o endereço de origem registado, não uma descrição da topologia.