Quell’indirizzo L2TP è IPCP, non un lease DHCP sulla LAN

La connessione si alza e l’adattatore mostra un indirizzo nell’intervallo dell’ufficio, quindi la conclusione naturale è che la VPN vi abbia dato un indirizzo LAN e vi abbia così messo sulla LAN. Nessuna delle due metà è del tutto giusta. L2TP trasporta una sessione PPP, e PPP negozia l’indirizzo IPv4 interno con IPCP. Quell’indirizzo è un parametro di sessione concordato tra due peer, non un lease rilasciato dal server DHCP dell’ufficio, e possederlo non vi rende vicini sul cavo dell’ufficio.

Due indirizzi in una connessione

Ci sono due negoziazioni indipendenti in una connessione L2TP. Quella esterna stabilisce un percorso protetto tra il dispositivo e l’endpoint VPN sulla rete che già avete. Quella interna è la sessione PPP, ed è dove si concordano l’indirizzo della sessione e quello dell’altra estremità. Il traffico Internet può uscire del tutto sotto un terzo indirizzo, quello pubblico dell’endpoint, ed è per questo che una pagina di verifica VPN e l’indirizzo dell’adattatore raramente coincidono.

Tenere separati questi tre ruoli risponde alla maggior parte delle domande che le persone portano a questo livello. Un numero privato sull’interfaccia VPN è normale e atteso. Non dice nulla sul fatto che l’endpoint abbia cambiato l’uscita pubblica, e da solo non decide quali destinazioni raggiunge il traffico.

Cosa fa esattamente IPCP

IPCP è il protocollo di controllo IPv4 per PPP. Ogni lato invia messaggi Configure-Request che descrivono le opzioni desiderate, e l’opzione indirizzo è una di queste. Un client che non ha ancora un indirizzo di solito chiede con 0.0.0.0, e il server risponde con un Configure-Nak che porta l’indirizzo che vuole che il client usi. Poi il client richiede quell’indirizzo e la sessione si alza con un indirizzo locale e uno remoto.

Questo scambio è documentato nelle specifiche PPP e IPCP, e spiega un dettaglio che sembra un bug: l’indirizzo è scelto dal server secondo la propria politica, che può essere un pool, un’impostazione per utente o un indirizzo legato all’identità autenticata. Quando il pool è esaurito, o la politica entra in conflitto con la richiesta, l’autenticazione può riuscire mentre la negoziazione dell’indirizzo fallisce, e il client segnala una connessione che non si stabilizza mai.

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

Una riga del registro di pppd che nomina un indirizzo locale e uno remoto è il finale riuscito di quella negoziazione. La sua assenza, accanto a un’autenticazione riuscita, indica la fase dell’indirizzo e non le credenziali.

Perché la LAN non può rispondervi

Un indirizzo dell’intervallo del lato remoto crea l’aspettativa che gli host di quella LAN possano raggiungervi, e per lo più non possono, a meno che il server instradi l’indirizzo della sessione nel tunnel. Essere dentro un pool è un’affermazione sull’assegnazione, non sulla topologia. Il file server dell’ufficio non ha alcuna rotta verso l’indirizzo della vostra sessione a meno che il server VPN lo inoltri, e forse non è nemmeno consentito anche se lo fa.

È anche per questo che gli intervalli sovrapposti causano problemi sproporzionati rispetto alla loro dimensione apparente. Se il pool si sovrappone a una LAN che il client già usa, la tabella di routing del client ha ora due pretese sullo stesso prefisso, e quella sbagliata spesso vince per motivi che non hanno nulla a che vedere con il tunnel.

Verificate la sessione, poi la rotta

Controllate prima l’interfaccia, poi le rotte, poi una destinazione che conta. Ogni passo ha il proprio modo di fallire, e testare tutti e tre insieme produce una conclusione che poi non potrete difendere.

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

Se il controllo pubblico mostra l’indirizzo dell’endpoint mentre una destinazione privata va in timeout, il tunnel porta la vostra rotta predefinita e il lato remoto non risponde per quella destinazione. Se la destinazione privata risponde ma il controllo pubblico non cambia, il profilo usa il tunnel diviso e solo una parte del traffico usa la sessione.

Tenete separate le tre fasi

Autenticazione, negoziazione dell’indirizzo e inoltro falliscono in modi diversi, e ciascuna ha un responsabile diverso. Le credenziali sono un problema di identità, l’esaurimento di IPCP è un problema di politica del server e una rotta di ritorno mancante è un problema di progettazione della rete. Segnalare tutte e tre come «la VPN è rotta» garantisce una correzione lenta.

Annotate l’indirizzo assegnato, il pool da cui proviene e se la LAN dovrebbe raggiungerlo. Quella singola nota impedisce alla persona successiva di supporre un lease DHCP e cercare un ambito che non è mai stato coinvolto.