Un client VPN con indirizzo LAN non è sulla LAN

Il client si connette, riceve 10.50.0.200 e non riesce a raggiungere il server su 10.50.0.20 anche se entrambi i numeri stanno nella stessa /24. La convinzione dietro quella configurazione è che un indirizzo del prefisso LAN renda il client parte della LAN. Non lo fa. Il client è su un collegamento punto a punto, il server ritiene la destinazione locale, e il pezzo mancante è una risposta di vicino che nessuno invia.

Il mito: stesso prefisso significa stesso segmento

Un prefisso di indirizzo dice a un host quali destinazioni può raggiungere direttamente e quali richiedono un router. Non dice all’host come la destinazione sia fisicamente collegata, e di certo non garantisce che la destinazione possa rispondere a una richiesta a livello di collegamento. Sono domande diverse, a cui rispondono tabelle diverse sull’host. La maschera risponde alla prima e la tabella dei vicini alla seconda, e solo la prima è sotto il tuo controllo dal lato della VPN.

Quando il server invia a 10.50.0.200, confronta la destinazione con la propria maschera, decide che l’indirizzo è on-link e chiede al segmento locale l’indirizzo hardware che lo possiede. Quella richiesta esce sull’interfaccia Ethernet, e il client VPN non è lì per sentirla.

Niente nella configurazione del client può risolvere questo dal suo lato. Il percorso di risposta dipende dal fatto che un dispositivo sulla LAN risponda per conto del client, o che il client abbia un indirizzo che il server non considera locale.

Che cosa fa davvero l’host locale con l’indirizzo

Il comportamento è facile da osservare e vale la pena osservarlo prima di cambiare qualcosa. Guarda la tabella dei vicini su un host della LAN dopo che ha provato a raggiungere il client: una voce incompleta o fallita è tutta la diagnosi in una riga. Quella riga ti dice anche che il guasto è locale al segmento e non da qualche parte dentro il tunnel.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

La ricerca di rotta segnalerà la destinazione come on-link attraverso l’interfaccia Ethernet, ed è esattamente il problema. Se la voce del vicino resta incompleta mentre la sessione VPN è attiva, hai confermato che il pezzo mancante è la risoluzione a livello di collegamento e non l’instradamento o la politica del firewall.

Esegui lo stesso controllo da un host in un’altra sottorete e confronta. Un host che raggiunge il client attraverso un router non ha affatto bisogno di una voce di vicino, e quella differenza è la decisione di progettazione in miniatura.

Come il proxy ARP fornisce un prossimo salto

Il proxy ARP fa sì che il gateway risponda alla richiesta a livello di collegamento per conto di una destinazione che può raggiungere attraverso un’altra interfaccia. L’host della LAN riceve un indirizzo hardware, invia il frame al gateway, e il gateway inoltra il pacchetto nella sessione VPN. Dal punto di vista dell’host il client sembra semplicemente essere dietro il gateway. Nulla della configurazione del client cambia.

La documentazione ARP di RouterOS di MikroTik descrive questo uso per i client dial-in che prendono in prestito lo spazio di indirizzi della LAN collegata. Il meccanismo è una riparazione della risoluzione dei vicini, e funziona perché il gateway è davvero su entrambi i percorsi.

Non è la stessa cosa che portare il client in bridge nella LAN. Il gateway deve comunque inoltrare il pacchetto alla sessione attiva corretta, e il suo instradamento e la sua politica del firewall devono comunque consentire il servizio. Il proxy ARP cambia chi risponde alla richiesta del vicino, non chi ha il permesso di parlare.

Leggi con attenzione i nomi delle modalità della piattaforma. RouterOS separa proxy-arp da local-proxy-arp, e la seconda gestisce il traffico che entra ed esce dalla stessa interfaccia. Non sono grafie intercambiabili, e attivare entrambe senza criterio non è una scorciatoia.

Che cosa il proxy ARP non ti dà

Non fornisce il rilevamento tramite broadcast o multicast. Un client che deve trovare un servizio tramite broadcast fallirà comunque, perché il gateway inoltra l’unicast alla sessione e non rende il client membro del dominio broadcast della LAN. I protocolli di rilevamento che si basano sul broadcast sono una fonte frequente di segnalazioni che funziona per una cosa e non per un’altra nei progetti con indirizzi presi in prestito.

Non riserva l’indirizzo. Se il numero preso in prestito sta anche in un pool DHCP o in un’assegnazione statica, due dispositivi possono finire con lo stesso indirizzo e il comportamento risultante dipende dal momento. Un accesso riuscito non è una prenotazione.

E non elimina la necessità di coordinarsi con chi possiede la LAN. Una voce proxy ARP che sorprende il proprietario del piano di indirizzamento è un incidente di supporto in attesa di una settimana tranquilla.

Confronto con un pool instradato a parte

L’alternativa è dare ai client VPN un proprio prefisso e lasciare che gli host della LAN instradino verso di esso. Il server invia allora risposte off-link al proprio gateway, il gateway instrada il prefisso verso l’endpoint VPN, e sul segmento LAN non serve alcuna risoluzione dei vicini. Sono meno parti mobili di un indirizzo preso in prestito più una risposta proxy.

Quel progetto è più facile da ragionare e da verificare, perché l’intervallo dei client è visibilmente separato da quello della LAN. Costa una rotta, un percorso di ritorno e una regola di accesso, le stesse cose che il progetto con proxy ARP richiede in un punto meno evidente.

Scegli tra i modelli deliberatamente e non per caso. Il proxy ARP ripara una relazione precisa; un pool instradato evita di aver bisogno di quella riparazione. Annota quale hai scelto e perché, e la persona successiva non dovrà riscoprirlo da una voce di vicino fallita.