Perché un host della LAN invia ARP per l’indirizzo di un client OpenVPN

I problemi di raggiungibilità tra un host della LAN e un client VPN risalgono spesso al piano di indirizzamento stesso. Assegna a quell’host un’interfaccia su 10.0.100.0/22 e tratterà ogni indirizzo da 10.0.100.0 a 10.0.103.255 come direttamente connesso, incluso un pool di client collocato in silenzio su 10.0.101.0/24. La risposta non passa mai da un router, perché dal punto di vista dell’host nessun router è coinvolto. Il pacchetto è indirizzato a un vicino e richiesto sul cavo.

Questo meccanismo sta dietro a un’intera famiglia di segnalazioni: il tunnel è attivo, il server ha una rotta e l’host della LAN non riesce comunque a raggiungere il client.

Il /22 che inghiotte il /24

Leggi il prefisso come un intervallo, non come una stringa. Un /22 contiene 1024 indirizzi, e 10.0.100.0/22 copre da 10.0.100.0 a 10.0.103.255, quindi un pool su 10.0.101.0/24 si trova interamente al suo interno. L’errore sopravvive alla revisione perché i primi ottetti del pool sembrano diversi dai primi ottetti della LAN e solo il terzo ottetto rivela la sovrapposizione. Scrivi entrambi gli intervalli in cifre prima di dichiararli separati.

La stessa sovrapposizione può comparire al contrario. Un pool che sembra libero perché al momento nulla lo usa può comunque ricadere in un prefisso annunciato da un router di sede, e il piano di indirizzamento è l’unico documento che lo mostra.

Collegamento diretto significa ARP, non routing

Quando un host con un’interfaccia /22 invia verso 10.0.101.25, il kernel confronta la destinazione con il prefisso dell’interfaccia e trova una corrispondenza. Il pacchetto diventa una risoluzione di vicino invece di un pacchetto instradato, e su Ethernet la risoluzione di vicino è una richiesta ARP per quell’indirizzo. Se l’indirizzo appartiene a un client VPN dietro un gateway instradato, nessun host della LAN lo possiede, quindi la richiesta resta senza risposta e i pacchetti vengono scartati. Il tunnel non ha colpe, e il client non vede mai il traffico.

Per questo il guasto appare asimmetrico e a volte intermittente. L’host VPN riesce spesso a raggiungere la LAN perché le sue rotte puntano nella direzione giusta, mentre l’host della LAN non può rispondere, e qualsiasi cache di una voce ARP obsoleta fa lampeggiare il sintomo.

TUN, TAP e ciò che ciascuno trasporta

Un dispositivo TUN trasporta pacchetti IP, e un dispositivo TAP trasporta frame Ethernet. Un collegamento TUN instradato non deve trasportare ARP per fornire raggiungibilità IP, ed è esattamente per questo che la richiesta senza risposta qui sopra è attesa e non guasta. TAP con un bridge deliberato può estendere il dominio di broadcast e far funzionare ARP, ma cambia ciò che il client può vedere, richiede estremità che supportino lo stesso incapsulamento ed è una riprogettazione del modello di rete anziché una riparazione per un prefisso sovrapposto. Passare un deployment instradato a TAP per curare un errore di piano di indirizzamento scambia un problema piccolo con uno più grande.

Annota dove è comparsa la richiesta ARP e quale sistema l’ha emessa prima di trarre conclusioni. Il mittente ti dice ciò che crede sulla destinazione, non ciò che fa il tunnel.

Progetta un pool che non possa sovrapporsi

Scegli un pool fuori da ogni prefisso connesso e da ogni prefisso di sede annunciato, poi aggiungi le rotte che lo rendono raggiungibile in entrambe le direzioni. Un intervallo come 10.8.0.0/24 in una parte inutilizzata del piano è facile da ragionare, e una LAN che deve raggiungerlo riceve una rotta statica che punta al server VPN. Modifica insieme l’assegnazione, le rotte annunciate, gli indirizzi sorgente consentiti e le regole del firewall, perché descrivono un unico progetto e non quattro impostazioni.

Il NAT sorgente sul server può nascondere il pool dietro un indirizzo instradabile dalla LAN, ed è uno strumento di migrazione legittimo. Riscrive anche la sorgente, quindi la LAN perde la capacità di attribuire le connessioni ai singoli client e di applicare regole per client.

Per il collaudo usa l’indirizzo realmente assegnato al client reale e una vera richiesta applicativa da un host della LAN, poi conferma che la risposta segua il gateway previsto anziché il cavo.