Date agli host della LAN una rotta di ritorno VPN con l'opzione 121 di DHCP

I client VPN remoti si connettono, il server della LAN risponde e la risposta esce dal router internet ordinario e muore lì. Un server si può sistemare con una rotta statica, ma un'intera sottorete di server è meglio gestirla dove ricevono già la loro configurazione di rete. L'opzione 121 di DHCPv4 distribuisce esattamente quel tipo di rotta di destinazione, ed è la parte che di solito si sbaglia nel momento in cui si dimentica la predefinita. Il sintomo è traffico a senso unico: le richieste arrivano e le risposte svaniscono.

Nominate prima i tre indirizzi

Prendete una LAN concreta: 192.168.50.0/24 con il normale router predefinito su 192.168.50.1 e un gateway VPN separato su 192.168.50.2. I client remoti autenticati occupano 10.90.0.0/24.

La rotta che serve a ogni host partecipante è 10.90.0.0/24 via 192.168.50.2. La destinazione è il pool di client e il salto successivo è l'indirizzo LAN del gateway, non il suo indirizzo di tunnel.

Codificatela come rotta statica senza classi

L'opzione 121 trasporta coppie di prefisso e salto successivo, e RFC 3442 definisce sia la codifica sia il comportamento del client che ne deriva. Per un'istanza dnsmasq esistente che serve solo questa LAN illustrativa, la forma della configurazione è:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

È un frammento, non un nuovo servizio DHCP. Su un server che gestisce più segmenti, limitate l'opzione con i tag o la politica di rete che già usate. Tenete a portata di mano la configurazione precedente, perché tornare indietro significa un altro rinnovo del lease, non un riavvio.

Non perdete la rotta predefinita

Questa è la trappola. Un client che riceve l'opzione 121 deve ignorare l'opzione Router ordinaria, quindi annunciare solo la rotta del pool VPN può lasciare quell'host senza alcuna rotta predefinita. La macchina sembra ancora configurata e perde silenziosamente internet. Gli utenti lo descrivono come rete in avaria mentre ogni interfaccia è attiva.

Includete la predefinita voluta nello stesso elenco, come fa il frammento qui sopra. Mantenete anche l'opzione Router ordinaria per i client che non implementano rotte senza classi; è la gestione delle opzioni del server a decidere che cosa viene inviato a chi.

Verificate che cosa accetterà il client

Un host con indirizzo manuale non lo recepisce mai, perché non chiede un lease. Anche il supporto dei client varia, quindi provate sul sistema operativo che usate davvero invece di dare per scontato che ogni dispositivo rispetti l'opzione 121. Verificate con chi possiede quei server quali hanno indirizzo statico. Quegli host hanno bisogno delle proprie voci di rotta, altrimenti semplicemente non parteciperanno.

I servizi DHCP gestiti sono un altro limite. Alcune reti cloud non consentono agli amministratori di pubblicare opzioni arbitrarie, e un server DHCP concorrente sullo stesso segmento è peggio di nessuna opzione.

Verificate il lease, poi la ricerca

Fate applicare la modifica al proprietario del DHCP, poi rinnovate il lease su un client. I lease esistenti mantengono la vecchia configurazione finché non vengono rinnovati, quindi i risultati immediati non sono garantiti.

Su un client Linux, leggete le rotte reali e confermate entrambe le voci:

ip -4 route
ip -4 route get 10.90.0.23

La ricerca contestuale dovrebbe mostrare la rotta del pool tramite 192.168.50.2 e la predefinita tramite 192.168.50.1. Se manca la predefinita, avete riprodotto la trappola qui sopra.

Poi provate lo scambio reale

La distribuzione delle rotte non è tutto il percorso. Il gateway separato ha ancora bisogno di inoltro, proprietà dei peer remoti e una politica di accesso che consenta il server, e DHCP non autentica nessuno.

Infine, tenete un piano di rimozione. Una rotta statica appresa non si ritira da sola quando la VPN cade, quindi un salto successivo obsoleto può trasformare quel prefisso in un buco nero molto tempo dopo che il tunnel è sparito.