Por que apenas um cliente VPN se liga atrás do mesmo router

Dois portáteis estão na mesma rede doméstica, e a VPN do escritório aceita exatamente um deles. O segundo ou esgota o tempo ou espera até o primeiro se desligar, e ninguém tocou numa definição do cliente entre as duas tentativas. As credenciais são as mesmas que funcionavam há um minuto, e é essa a pista de que a autenticação não é a falha. Três mecanismos produzem este padrão, e o próprio registo do servidor diz com qual está a lidar.

Leia o registo da gateway antes de tocar num cliente

O registo do servidor das duas tentativas responde à primeira pergunta, e fá-lo de uma de três formas. Se a segunda tentativa nunca aparecer nesse registo, o pacote nunca chegou ao ouvinte, e o problema é do router doméstico ou do caminho do fornecedor. Se o registo anota uma tentativa e a rejeita, o túnel chegou, pelo que a questão é de identidade, de licença ou de limite de sessões, e não algo no cabo. Se o registo anota uma sessão bem-sucedida enquanto o cliente ainda comunica uma falha, veja o caminho de retorno ou se está a ser dado o mesmo endereço de túnel a dois clientes.

Um hotspot do telemóvel separa essas famílias a baixo custo: execute o segundo cliente por dados móveis enquanto o primeiro continua ligado. O sucesso ali aponta para a rede doméstica, e a mesma falha ali aponta para a gateway, o que deixa o router inocente. Nenhum resultado é conclusivo sozinho, mas cada um elimina metade do espaço de procura numa única tentativa.

Anote o resultado antes de mudar seja o que for, porque as três saídas do registo levam a três reparações sem relação. Uma nota que nomeie qual das três viu vale mais do que uma captura de ecrã de um erro do cliente.

O que o router faz com GRE e NAT-T

O PPTP é o culpado clássico: o canal de controlo é TCP 1723, enquanto o caminho de dados é GRE, o protocolo IP 47. Muitos routers domésticos incluem um auxiliar PPTP que segue uma única ligação de controlo, pelo que um segundo cliente atrás do mesmo NAT abre o seu canal de controlo e depois não recebe qualquer caminho de dados. Reencaminhar uma porta TCP com o número 47 não faz nada pelo GRE, porque o GRE é um número de protocolo e não uma porta.

L2TP sobre IPsec comporta-se de forma diferente por conceção: o IKE usa UDP 500, a travessia NAT desloca a carga protegida para UDP 4500, e o encapsulamento existe precisamente para que vários clientes atrás de um endereço possam chegar à mesma gateway. Essa conceção não impede uma gateway ou uma caixa intermédia de impor um limite de sessões por endereço, e do sofá as duas falhas parecem idênticas. O protocolo nativo do SoftEther tem a mesma classe de problema: um router sem passagem funcional aceita o primeiro cliente da LAN e descarta o segundo. Teste o ALG ou o interruptor de passagem do router nas duas posições, porque um auxiliar escrito para um cliente antigo pode corromper pacotes que um atual envia.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

Limites de identidade que parecem limites de transporte

O router não é o único suspeito, e o registo distingue-o da alternativa. Quando um servidor OpenVPN fixa um nome comum a um endereço de túnel, ambos os equipamentos recebem esse endereço, e sem duplicate-cn a sessão mais recente expulsa a mais antiga. Ativar essa opção deixa ambos ligados mas deixa-os com uma identidade, um certificado e uma decisão de revogação, o que é pior do que parece. O segundo equipamento nunca mais poderá ser revogado sozinho, pelo que um interruptor de comodidade retira em silêncio um controlo de que pode precisar mais tarde.

Leia o diário do servidor e o ficheiro de estado em conjunto, porque um mostra a decisão de autenticação e o outro mostra quem está ligado neste momento. Duas entradas que partilham um nome comum e um endereço virtual confirmam uma colisão de identidade e não um limite do router. As gateways comerciais acrescentam limites próprios, como um plano que permite uma única sessão simultânea, uma contagem de licenças ou uma regra que permite uma sessão por endereço público, e nenhuma definição do router muda nada disso.

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

Faça corresponder a reparação à entrada do registo

Uma rejeição no registo exige credenciais separadas por equipamento, um limite mais alto de quem gere o serviço, ou um segundo ponto final de gateway para uma máquina. Se nenhuma segunda tentativa chegar alguma vez ao servidor, a reparação duradoura é um router que reencaminha o protocolo e mantém mais do que uma sessão, ou um transporte que o router trata bem, como um único fluxo TCP ou UDP. Escolher entre os dois é uma decisão sobre a vida do hardware, não sobre definições do cliente.

Não copie o perfil de um equipamento que funciona para a segunda máquina e dê o assunto por encerrado. Isso transforma um problema de ligação num problema de controlo de acesso, porque um portátil perdido deixa de se distinguir da cópia ainda em uso. Também esconde a falha original, que regressa no momento em que aparece um terceiro equipamento.

Verificar duas sessões ativas

Ligue os dois equipamentos ao mesmo tempo, execute a aplicação pretendida em cada um, depois volte a ligar um deles e repita. Um segundo ícone que aparece por instantes não prova nada sobre o tráfego, e uma sessão que cai ao fim de dez minutos é outra falha com outro responsável. Compare o que o servidor comunica no fim com o que os utilizadores viram, porque estes dois relatos muitas vezes não coincidem.

Se as duas sessões sobreviverem e transportarem tráfego, a correção mantém-se, e a nota que escreveu no início passa a ser o registo do que estava errado. Se sobreviver apenas uma, volte ao primeiro passo e verifique qual das três saídas do registo tem agora, porque a resposta pode ter mudado. Os auxiliares do router podem esconder um problema que reaparece noutra rede, ao passo que um limite por endereço segue o utilizador e não o equipamento. Testar a partir de uma segunda rede é a forma mais barata de descobrir qual deles corrigiu de facto.