Quell’indirizzo del tunnel è un peer, non una sottorete che puoi esplorare

Il tuo client si connette e mostra una coppia di indirizzi, o un solo indirizzo con una 255.255.255.255 maschera, e la prima reazione è che il server abbia distribuito qualcosa di rotto. Niente è rotto: un’interfaccia incapsulata è un collegamento punto a punto, e la maschera descrive l’estremità remota di quell’unico collegamento, non un intervallo di vicini. Leggere la coppia come locale e peer spiega la maschera strana, la rotta di un solo host accanto e la tabella dei vicini assente. Ciò che la stessa lettura non giustifica è un piano di indirizzi che si sovrappone alla rete dell’ufficio.

Perché la maschera sembra sbagliata su un collegamento incapsulato

Su un’interfaccia Ethernet, un indirizzo e una maschera affermano due cose: questo host possiede l’indirizzo, e tutto ciò che sta dentro il prefisso è un vicino diretto. Il kernel ricava una rotta sul collegamento da questi due fatti e poi risolve gli indirizzi del collegamento per i vicini che ritiene presenti. Un’interfaccia punto a punto conserva la proprietà e scarta i vicini, quindi il secondo indirizzo nella riga del client è l’estremità remota e non un altro host su un segmento condiviso. Non ci sono indirizzamenti hardware, traffico di risoluzione né dominio di broadcast a cui unirsi, ed è per questo che l’interfaccia si comporta come un tubo con esattamente una destinazione.

È anche per questo che una rotta di un solo host accanto a una maschera ampia qui è normale e non un sintomo. La raggiungibilità su questo collegamento significa un solo indirizzo, e il kernel scrive esattamente quello. Leggi i due indirizzi insieme prima di concludere che la configurazione sia sbagliata, perché ciascuno da solo sembra un errore.

Due topologie, due forme di indirizzo

La topologia punto a punto più vecchia assegna a ogni client un blocco piccolo e usa i due indirizzi centrali, quindi la maschera sembra un frammento di rete e non un pool. La topologia a sottorete assegna un indirizzo dal pool con la maschera del pool e chiama l’indirizzo del tunnel del server il peer. Entrambe producono un collegamento valido, e differiscono solo per gli indirizzi che compaiono nel profilo e per la maschera che un utente probabilmente metterà in discussione.

Qualunque riga corrisponda al tuo client, leggi prima il peer, perché nomina l’estremità remota e quindi spiega la maschera. Un profilo copiato tra server che usano topologie diverse mostrerà la forma sbagliata per la sua nuova casa, e quella discrepanza viene facilmente scambiata per un guasto del server.

Quando il pool e la rete dell’ufficio rivendicano gli stessi bit

Poiché il collegamento è instradato, il pool ha bisogno di un prefisso che non compaia in nessuna delle reti che il server può raggiungere. Condividine uno e il client terrà una sola rotta per un intervallo che significa due luoghi, e la rotta installata più di recente decide quale luogo vince. Il guasto si presenta sul client anche se la decisione dietro appartiene al piano di indirizzi. Ciò che gli utenti segnalano è la scomparsa del router locale quando il tunnel sale, o che rispondono solo alcuni host dell’ufficio.

I prefissi che si somigliano soltanto sono un altro caso, e confrontare gli ottetti a occhio non è un confronto di prefissi. Scrivi entrambi e conta i bit mascherati: 192.168.4.0/24 contro 192.168.6.0/24 concordano fino al bit 22 e divergono al bit 23, perché il terzo ottetto si legge 00000100 contro 00000110, quindi quelle due reti sono davvero separate. Metti 10.8.0.0/24 accanto a un altro 10.8.0.0/24 e tutti i 24 bit mascherati concordano, il che significa che una rotta non può esprimere entrambi i luoghi. La lunghezza della maschera decide dove si ferma il confronto, e la rete installata per seconda è quella che perde.

Ciò che un collegamento instradato non può consegnare

Broadcast e multicast non attraversano un collegamento instradato, e diverse funzioni familiari sono costruite su di essi. Gli elenchi di esplorazione, gli annunci di nomi e la scoperta dei servizi presuppongono tutti un segmento condiviso, quindi un file server può rispondere a ogni richiesta per indirizzo e comunque non comparire mai in un elenco. La risoluzione dei nomi che dipende dal broadcast locale del collegamento fallisce per lo stesso motivo, e nessuna modifica del profilo cambia ciò che il tunnel può trasportare. Se questo conti è una questione di requisiti, non di instradamento.

Un client che ha davvero bisogno di quelle consegne richiede un’interfaccia bridge, che trasporta frame Ethernet e quindi conserva il dominio di broadcast. Il prezzo è un collegamento più rumoroso, la perdita dell’indirizzamento pulito descritto sopra e una superficie di guasto molto più grande quando compaiono anelli. Giustifica il requisito prima di cambiare, e preferisci un servizio di nomi che funzioni su collegamenti instradati quando il requisito riguarda solo i nomi.

Leggere l’interfaccia prima di modificare il profilo

Chiedi al kernel cosa ha installato, non cosa sembra dire il profilo. L’output degli indirizzi mostra il peer che spiega la maschera, e l’output delle rotte mostra se esiste un percorso verso di esso. Eseguire entrambi contro il dispositivo del tunnel richiede un momento e risolve la questione.

ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1

Se questi tre concordano, il profilo fa ciò per cui è stato configurato, e il problema rimanente è altrove. Cambia la topologia solo per un motivo che nomini una capacità mancante, perché una maschera sconosciuta non lo è.