Ese enderezo L2TP é IPCP, non un arrendamento DHCP na LAN

A conexión levanta e o adaptador mostra un enderezo dentro do rango da oficina, así que a conclusión natural é que a VPN lle deu un enderezo da LAN e, por tanto, o puxo na LAN. Ningunha das dúas metades é do todo certa. L2TP transporta unha sesión PPP, e PPP negocia o enderezo IPv4 interno con IPCP. Ese enderezo é un parámetro de sesión acordado entre dous pares, non un arrendamento entregado polo servidor DHCP da oficina, e telo non o converte en veciño no cable da oficina.

Dous enderezos nunha conexión

Hai dúas negociacións independentes nunha conexión L2TP. A externa establece unha ruta protexida entre o seu dispositivo e o punto final da VPN sobre a rede que xa teña. A interna é a sesión PPP, e é onde se acordan o enderezo da súa sesión e o do outro extremo. O tráfico de Internet pode saír baixo un terceiro enderezo por completo, o público do punto final, e por iso unha páxina de comprobación de VPN e o enderezo do adaptador raramente coinciden.

Manter eses tres papeis separados responde á maioría das preguntas que a xente trae a esta capa. Un número privado na interface VPN é normal e esperable. Non di nada sobre se o punto final cambiou a súa saída pública, e por si só non decide que destinos alcanza o seu tráfico.

Que fai exactamente IPCP

IPCP é o protocolo de control de IPv4 para PPP. Cada lado envía mensaxes Configure-Request que describen as opcións que quere, e a opción de enderezo é unha delas. Un cliente que aínda non ten enderezo adoita preguntar con 0.0.0.0, e o servidor responde cun Configure-Nak que leva o enderezo que quere que use o cliente. Despois o cliente pide ese enderezo e a sesión levanta cun enderezo local e un remoto.

Ese intercambio está documentado nas especificacións de PPP e IPCP, e explica un detalle que parece un erro: o enderezo é elixido polo servidor segundo a súa propia política, que pode ser un grupo, un axuste por usuario ou un enderezo ligado á identidade autenticada. Cando o grupo se esgota, ou a política entra en conflito coa petición, a autenticación pode ter éxito mentres a negociación de enderezo falla, e o cliente informa dunha conexión que nunca se estabiliza.

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

Unha liña do rexistro de pppd que nomee un enderezo local e un remoto é o final correcto desa negociación. A súa ausencia, xunto a unha autenticación correcta, apunta á etapa de enderezo e non ás credenciais.

Por que a LAN non pode responderlle

Un enderezo do rango do lado remoto crea a expectativa de que os equipos desa LAN poden alcanzalo, e case nunca poden agás que o servidor encamiñe o enderezo da súa sesión de volta ao túnel. Estar dentro dun grupo é unha afirmación sobre a asignación, non sobre a topoloxía. O servidor de ficheiros da oficina non ten ruta cara ao enderezo da súa sesión agás que o servidor VPN o reenvíe, e pode que nin sequera estea permitido aínda que o faga.

Tamén por iso os rangos solapados causan problemas desproporcionados respecto ao seu tamaño aparente. Se o grupo se solapa cunha LAN que o cliente xa usa, a táboa de rutas do cliente ten agora dúas pretensións sobre o mesmo prefixo, e a incorrecta adoita gañar por motivos que nada teñen que ver co túnel.

Verifique a sesión e despois a ruta

Comprobe primeiro a interface, despois as rutas e despois un destino que importe. Cada paso ten o seu propio modo de fallo, e probar os tres á vez produce unha conclusión que despois non poderá 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 comprobación pública mostra o enderezo do punto final mentres un destino privado esgota o tempo, o túnel leva a súa ruta por defecto e o lado remoto non responde para ese destino. Se o destino privado responde pero a comprobación pública non cambia, o perfil usa túnel dividido e só parte do tráfico utiliza a sesión.

Manteña as tres etapas separadas

A autenticación, a negociación de enderezo e o reenvío fallan de forma distinta, e cada unha ten un responsable distinto. As credenciais son un problema de identidade, o esgotamento de IPCP é un problema de política do servidor e unha ruta de retorno ausente é un problema de deseño de rede. Informar das tres como “a VPN está rota” garante unha solución lenta.

Anote o enderezo asignado, o grupo do que veu e se se supón que a LAN debe alcanzalo. Esa única nota evita que a seguinte persoa supoña un arrendamento DHCP e busque un ámbito que nunca estivo implicado.