Dois locais em ligações móveis têm o mesmo problema em ambos os sentidos: nenhum pode aceitar uma ligação IPv4 não solicitada, por isso nenhum pode desempenhar o papel de servidor num túnel direto. A arquitetura que funciona coloca um terceiro acessível no meio: cada local liga-se para fora e o meio só reenvia o tráfego que aprovas. Esse meio pode ser um router que operas tu ou um produto que apresenta os pares, e não são a mesma coisa. Os passos abaixo estão ordenados para que cada um produza provas antes de o seguinte depender delas.

Não é possível ligar a nenhum dos locais, por isso ambos têm de ligar para fora

Confirma a restrição antes de desenhar à volta dela. Se o operador atribuir um endereço privado à interface WAN, nenhum reencaminhamento de porta no router do próprio local a tornará acessível, porque a tradução acontece mais acima. Um endereço IPv6 público pode existir na mesma ligação e mudar o desenho por completo, e é por isso que a verificação abrange as duas famílias. Anota a resposta por local, porque os dois raramente têm restrições idênticas mesmo quando partilham operador.

O caso móvel comum parece um endereço do intervalo traduzido do operador com uma rota predefinida a atravessá-lo. Não é uma avaria a reparar; é a razão pela qual o concentrador existe. O que procuras é qualquer endereço a que um terceiro consiga chegar sem que o local tenha falado primeiro.

Dois comandos respondem à pergunta de endereçamento do local que tens à frente. Executa-os no router do local, não num portátil atrás dele:

ip -4 addr show scope global
ip -6 addr show scope global

Quem apresenta os pares e quem transporta os pacotes

Apresentação e transporte são tarefas separadas que os produtos costumam agrupar sem tornar a fronteira visível. Um mecanismo de encontro ajuda dois pares a encontrar um caminho candidato; um relé transporta os pacotes deles quando não existe caminho direto. Comprar um serviço que apresenta pares não te dá um router, e essa diferença decide se o desenho precisa de um concentrador.

A travessia tem o seu próprio vocabulário, e as palavras descrevem papéis, não garantias. A especificação ICE descreve candidatos e verificações de conectividade, o STUN descreve uma forma de saber sobre a tradução de endereços, e o TURN descreve transporte retransmitido para aplicações que o implementam. Nenhum desses mecanismos aparece numa gateway convencional porque a apontaste para um endereço de descoberta. Verifica a travessia como capacidade do produto e assume relé até um teste mostrar o contrário.

Uma rota por local, na posse de um par

O concentrador precisa de um túnel por local, um prefixo LAN distinto atrás de cada um e uma rota para cada prefixo que nomeie o seu dono. No exemplo o concentrador é 10.61.0.1, o local A é 10.61.0.11 com LAN 10.60.10.0/24, e o local B é 10.61.0.12 com LAN 10.60.20.0/24. Cada rota abaixo aponta para o par que detém o prefixo, não para a interface do túnel:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

O reenvio tem de estar ativo, senão os pacotes param no concentrador sem qualquer erro que indique a causa. O último comando responde à pergunta real, porque pergunta que caminho tomaria um pacote da LAN do local A para a LAN do local B com a origem incluída na consulta. Trata uma consulta que nomeia a interface do túnel como prova e uma que recai na rota predefinida como uma rota em falta, não como um mistério. Depois restringe o trânsito de propósito, porque um concentrador que reenvia entre todos os pares transforma dois locais numa rede plana e a política de acesso que julgavas ter deixa de se aplicar.

Decide também onde termina a cifra. Quando o concentrador detém ambas as extremidades do túnel, o operador dessa máquina e a sua carga de trabalho entram no modelo de confiança e disponibilidade, e a sua largura de banda passa a fazer parte do caminho.

Mantém cada mapeamento vivo através do operador

Cada local inicia o seu próprio túnel, e cada um tem de manter o mapeamento de tradução vivo, senão o operador esquece-o. Um keepalive do lado que inicia preserva esse mapeamento entre os apertos de mão. Limita os prefixos permitidos ao endereço do concentrador e à LAN remota, para que um par comprometido não possa reclamar um prefixo que não possui:

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

Reflete o bloco no outro local com o seu próprio prefixo remoto, e resiste à vontade de permitir todo o intervalo do túnel. Um aperto de mão que pára e retoma a partir de uma nova porta de origem é a assinatura de um mapeamento expirado, e as marcas temporais do aperto de mão são a prova de que aconteceu. Um intervalo mais curto do que o tempo limite do operador evita a expiração em vez de a reparar depois. Quando o operador altera o seu comportamento de tradução, espera que esses tempos mudem com ele.

Prova ambos os sentidos, depois prova a recuperação

A verificação é direcional, portanto um ping de A para B prova metade do desenho e nada sobre a rota de regresso. Verifica o caminho de resposta com a mesma consulta consciente da origem no concentrador, e repete depois o teste do outro lado. Os apertos de mão novos também fazem parte da prova, porque um túnel inativo durante uma hora pode estar a testar um mapeamento antigo:

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

Depois testa a falha que esperas, não o sucesso que queres. Reinicia a ligação de um local e confirma que o túnel regressa sem que nenhuma pessoa toque em qualquer extremo, porque um desenho que precisa de um operador após cada alteração do operador está inacabado. Regista o caminho principal, a alternativa IPv6 quando existir e o comportamento quando o concentrador não está disponível. O concentrador é agora parte do teu modelo de disponibilidade, por isso escreve-o em vez de o descobrires durante uma queda.

Artigos relacionados