Esse endereço L2TP é IPCP, não uma concessão DHCP na LAN

A conexão sobe e o adaptador mostra um endereço na faixa do escritório, então a conclusão natural é que a VPN deu a você um endereço LAN e, portanto, colocou você na LAN. Nenhuma das duas metades está totalmente certa. L2TP transporta uma sessão PPP, e PPP negocia o endereço IPv4 interno com IPCP. Esse endereço é um parâmetro de sessão acordado entre dois pares, não uma concessão entregue pelo servidor DHCP do escritório, e tê-lo não faz de você um vizinho no cabo do escritório.

Dois endereços em uma conexão

Há duas negociações independentes em uma conexão L2TP. A externa estabelece um caminho protegido entre o seu dispositivo e o ponto final da VPN sobre a rede que já tiver. A interna é a sessão PPP, e é onde se acordam o endereço da sua sessão e o do outro extremo. O tráfego de Internet pode sair sob um terceiro endereço por completo, o público do ponto final, e é por isso que uma página de verificação de VPN e o endereço do adaptador raramente coincidem.

Manter esses três papéis separados responde à maioria das perguntas que as pessoas trazem a esta camada. Um número privado na interface VPN é normal e esperado. Ele não diz nada sobre se o ponto final mudou a sua saída pública, e por si só não decide quais destinos o seu tráfego alcança.

O que IPCP faz exatamente

IPCP é o protocolo de controle de IPv4 para PPP. Cada lado envia mensagens Configure-Request que descrevem as opções que quer, e a opção de endereço é uma delas. Um cliente que ainda não tem endereço costuma perguntar com 0.0.0.0, e o servidor responde com um Configure-Nak que leva o endereço que quer que o cliente use. Depois o cliente pede esse endereço e a sessão sobe com um endereço local e um remoto.

Essa troca está documentada nas especificações de PPP e IPCP, e explica um detalhe que parece um bug: o endereço é escolhido pelo servidor segundo a própria política, que pode ser um pool, um ajuste por usuário ou um endereço ligado à identidade autenticada. Quando o pool se esgota, ou a política entra em conflito com o pedido, a autenticação pode ter sucesso enquanto a negociação de endereço falha, e o cliente relata uma conexão que nunca se estabiliza.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

Uma linha do registro do pppd que nomeia um endereço local e um remoto é o fim bem-sucedido dessa negociação. A ausência dela, ao lado de uma autenticação bem-sucedida, aponta para a etapa de endereço e não para as credenciais.

Por que a LAN não pode responder a você

Um endereço da faixa do lado remoto cria a expectativa de que os hosts daquela LAN podem alcançá-lo, e na maioria das vezes não podem, a menos que o servidor encaminhe o endereço da sua sessão de volta ao túnel. Estar dentro de um pool é uma afirmação sobre alocação, não sobre topologia. O servidor de arquivos do escritório não tem rota para o endereço da sua sessão a menos que o servidor VPN o encaminhe, e talvez nem sequer seja permitido mesmo que encaminhe.

Também por isso as faixas sobrepostas causam problemas desproporcionais ao seu tamanho aparente. Se o pool se sobrepõe a uma LAN que o cliente já usa, a tabela de rotas do cliente agora tem duas reivindicações sobre o mesmo prefixo, e a incorreta costuma ganhar por motivos que nada têm a ver com o túnel.

Verifique a sessão e depois a rota

Verifique primeiro a interface, depois as rotas e depois um destino que importe. Cada passo tem o seu próprio modo de falha, e testar os três ao mesmo tempo produz uma conclusão que depois você não conseguirá defender.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

Se a verificação pública mostra o endereço do ponto final enquanto um destino privado expira, o túnel leva a sua rota padrão e o lado remoto não responde por esse destino. Se o destino privado responde mas a verificação pública não muda, o perfil usa túnel dividido e apenas parte do tráfego utiliza a sessão.

Mantenha as três etapas separadas

A autenticação, a negociação de endereço e o encaminhamento falham de formas diferentes, e cada uma tem um responsável diferente. As credenciais são um problema de identidade, o esgotamento do IPCP é um problema de política do servidor e uma rota de retorno ausente é um problema de desenho de rede. Relatar as três como “a VPN está quebrada” garante uma correção lenta.

Anote o endereço atribuído, o pool de onde veio e se a LAN deve alcançá-lo. Essa única nota impede que a próxima pessoa presuma uma concessão DHCP e procure um escopo que nunca esteve envolvido.