Aquesta adreça L2TP és IPCP, no un arrendament DHCP a la LAN

La connexió s’aixeca i l’adaptador mostra una adreça dins del rang de l’oficina, així que la conclusió natural és que la VPN us ha donat una adreça de la LAN i, per tant, us ha posat a la LAN. Cap de les dues meitats no és del tot certa. L2TP transporta una sessió PPP, i PPP negocia l’adreça IPv4 interna amb IPCP. Aquesta adreça és un paràmetre de sessió acordat entre dos iguals, no un arrendament lliurat pel servidor DHCP de l’oficina, i tenir-la no us converteix en veí al cable de l’oficina.

Dues adreces en una connexió

Hi ha dues negociacions independents en una connexió L2TP. L’externa estableix un camí protegit entre el vostre dispositiu i el punt final de la VPN sobre qualsevol xarxa que ja tingueu. La interna és la sessió PPP, i és on s’acorden l’adreça de la vostra sessió i l’adreça de l’altre extrem. El trànsit d’Internet pot sortir sota una tercera adreça completament, la pública del punt final, i per això una pàgina de comprovació de VPN i l’adreça de l’adaptador poques vegades coincideixen.

Mantenir aquests tres papers separats respon la majoria de preguntes que la gent porta a aquesta capa. Un número privat a la interfície VPN és normal i esperable. No diu res sobre si el punt final ha canviat la vostra sortida pública, i per si sol no decideix quines destinacions assoleix el vostre trànsit.

Què fa exactament IPCP

IPCP és el protocol de control d’IPv4 per a PPP. Cada costat envia missatges Configure-Request que descriuen les opcions que vol, i l’opció d’adreça és una d’elles. Un client que encara no té adreça normalment pregunta amb 0.0.0.0, i el servidor respon amb un Configure-Nak que porta l’adreça que vol que faci servir el client. Després el client demana aquesta adreça i la sessió s’aixeca amb una adreça local i una de remota.

Aquest intercanvi està documentat a les especificacions de PPP i IPCP, i explica un detall que sembla un error: l’adreça la tria el servidor segons la seva pròpia política, que pot ser un pool, un paràmetre per usuari o una adreça lligada a la identitat autenticada. Quan el pool s’esgota, o la política entra en conflicte amb la petició, l’autenticació pot tenir èxit mentre la negociació d’adreça falla, i el client informa d’una connexió que no s’estabilitza mai.

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

Una línia del registre de pppd que anomena una adreça local i una de remota és el final satisfactori d’aquesta negociació. La seva absència, al costat d’una autenticació correcta, apunta a l’etapa d’adreça i no a les credencials.

Per què la LAN no us pot respondre

Una adreça del rang del costat remot crea l’expectativa que els equips d’aquella LAN us poden abastar, i normalment no poden, tret que el servidor encamini l’adreça de la vostra sessió de tornada al túnel. Ser dins d’un pool és una afirmació sobre l’assignació, no sobre la topologia. El servidor de fitxers de l’oficina no té cap ruta cap a l’adreça de la vostra sessió tret que el servidor VPN la reenviï, i potser no li està permès fins i tot si ho fa.

També per això els rangs superposats causen problemes desproporcionats respecte a la seva mida aparent. Si el pool se superposa amb una LAN que el client ja fa servir, la taula d’encaminament del client té ara dues pretensions sobre el mateix prefix, i la incorrecta sovint guanya per motius que no tenen res a veure amb el túnel.

Verifiqueu la sessió i després la ruta

Comproveu primer la interfície, després les rutes i després una destinació que importi. Cada pas té el seu propi mode de fallada, i provar els tres alhora produeix una conclusió que després no podreu defensar.

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

Si la comprovació pública mostra l’adreça del punt final mentre una destinació privada esgota el temps, el túnel porta la vostra ruta per defecte i el costat remot no respon per a aquesta destinació. Si la destinació privada respon però la comprovació pública no canvia, el perfil fa túnel dividit i només part del trànsit utilitza la sessió.

Manteniu les tres etapes separades

L’autenticació, la negociació d’adreça i el reenviament fallen de maneres diferents, i cadascuna té un responsable diferent. Les credencials són un problema d’identitat, l’esgotament d’IPCP és un problema de política del servidor, i una ruta de retorn absent és un problema de disseny de xarxa. Informar de les tres com “la VPN està trencada” garanteix una solució lenta.

Anoteu l’adreça assignada, el pool d’on ve i si es presumeix que la LAN l’ha d’assolir. Aquesta única nota evita que la propera persona assumeixi un arrendament DHCP i busqui un àmbit que mai no hi va ser.