L’adattatore VPN mostra /32: non significa una sola destinazione

Gli adattatori mostrano 255.255.255.255, e spesso si conclude che la VPN raggiunge esattamente un indirizzo. Questa lettura confonde l’indirizzo del client stesso con l’insieme delle destinazioni instradate nel tunnel. Su un’interfaccia punto a punto o instradata i due sono oggetti diversi, e solo uno dei due limita la raggiungibilità. Il mito sopravvive perché la maschera somiglia alla maschera di sottorete imparata su Ethernet.

Il mito: una maschera di host significa un solo host raggiungibile

Un’assegnazione /32 dice all’interfaccia quale indirizzo appartiene a questo estremo del collegamento, e su un collegamento punto a punto è tutto ciò che significa. L’indirizzo del peer è un campo separato, e le rotte che dicono cosa c’è oltre il peer sono ancora separate. Niente nella maschera descrive la rete remota, perché la maschera non è il luogo in cui si descrivono le reti remote. Leggerla come limite di raggiungibilità è come leggere il numero di casa propria come un elenco di tutti gli indirizzi che si possono visitare.

La confusione ha una radice reale: su Ethernet, una maschera di host significherebbe davvero un solo indirizzo su quel segmento. Un tunnel non è un segmento Ethernet, e ciò che vi passa è deciso dalla tabella di routing del client, non dalla maschera. Per questo lo stesso /32 può stare davanti a un intero centro dati.

Leggi l’indirizzo e le rotte come oggetti separati

Stampa l’interfaccia e la tabella insieme, poi leggile come due risposte a due domande. L’indirizzo risponde a chi è questo estremo; le rotte rispondono a dove può andare il traffico. Una terza domanda, quali destinazioni il gateway consente, non è affatto visibile sul client. La guida agli indirizzi di iproute2 descrive separatamente i campi indirizzo locale, peer e rotta di prefisso proprio per questo motivo.

ip addr show tun0
ip route show
ip route get 10.60.5.10

Su Windows la stessa separazione esiste tra l’elenco degli indirizzi e la tabella di routing, e il comando di ricerca è il modo più rapido per vedere quale vince per una destinazione specifica. Se la ricerca restituisce l’interfaccia del tunnel, il client invierà il pacchetto lì. Se restituisce l’adattatore fisico, il client non chiede mai alla VPN, e nessun permesso lato server lo cambierà. Controlla la destinazione che ti serve davvero, non un indirizzo pubblico generico.

Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10

Fermati se la ricerca punta all’interfaccia sbagliata. È un problema di routing del client, e si corregge sul client.

Perché allargare la maschera di solito peggiora le cose

Cambiare l’assegnazione in /24 per somigliare alla LAN dell’ufficio può creare un prefisso sul collegamento: il kernel ora crede che l’intero /24 sia collegato direttamente all’interfaccia del tunnel. Il traffico verso indirizzi che dovrebbero essere instradati tramite il gateway viene allora inviato come se un vicino fosse sul collegamento. Il risultato è un buco nero che sembra un guasto del server.

Nasconde anche il problema reale, cioè una rotta mancante o un permesso mancante sul gateway. Nessuno dei due è creato da una maschera più ampia, ed entrambi sopravvivono al cambiamento. Se il progetto richiede un prefisso più grande sull’interfaccia, è una decisione per il modello di interfaccia in uso, presa con la documentazione in mano. Copiare una maschera dagli screenshot di un altro prodotto non è quella decisione.

Se manca la rotta del prefisso remoto, correggi il suo approvvigionamento. Se è presente e la connessione viene ancora rifiutata, la maschera non è mai stata la diagnosi.

Quando la rotta è giusta e il flusso fallisce ancora

Una rotta corretta dimostra solo che il client invierà il pacchetto. Il gateway deve ancora accettare la destinazione, il percorso di ritorno deve esistere per l’indirizzo assegnato, e il servizio deve consentire il flusso. Prova questi tre punti separatamente: la ricerca sul client, l’ambito consentito del gateway e una richiesta a un server necessario. Che l’autenticazione riesca prima che tutti e tre siano a posto è normale, ed è per questo che un client connesso può comunque non raggiungere nulla.

ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null

Tieni gli oggetti di rete e i permessi di gruppo presso il loro proprietario su un servizio gestito da un apparato. Ciò che si dice al client di raggiungere e ciò che gli è consentito usare sono impostazioni diverse, spesso su schermate diverse. Cambiare una e testare l’altra è il modo in cui un ticket rimbalza tra due team.

Il mito da pensionare è che la maschera sia un limite di raggiungibilità. Leggi l’indirizzo, le rotte e la policy del gateway come tre fatti separati, e un /32 smette di sembrare una restrizione e inizia a sembrare una normale assegnazione di tunnel.