Relay DHCP dell’ASA su una VPN site-to-site: guida passo passo

Il relay funziona in tre fasi e solo quella centrale attraversa la VPN. Un client trasmette in broadcast sul segmento della sede, l’ASA trasforma quel broadcast in una richiesta unicast al server DHCP, e il server risponde all’indirizzo del relay anziché al client. Percorrete le fasi in quest’ordine e la maggior parte dei casi «il relay è rotto» si riduce a una politica mancante o a una riga setroute letta male.

Prima fase: abilitate il relay sull’interfaccia lato client

Sull’ASA della sede il relay è una proprietà dell’interfaccia rivolta ai client. Il server può essere dichiarato globalmente con la sua interfaccia raggiungibile, oppure sotto quella interfaccia lato client perché la tabella di routing scelga l’uscita. Queste due forme non sono intercambiabili, e copiare quella sbagliata è il primo punto in cui una guida deraglia.

Controllate la configurazione in esecuzione prima di cambiare qualcosa: quale interfaccia ha il relay abilitato, quale forma di server è presente e se setroute è associato all’interfaccia del client. Se l’ASA esegue anche un server DHCP per un altro segmento, fermatevi e leggete l’elenco delle restrizioni; server e relay non possono essere abilitati insieme sullo stesso apparato.

Il relay inserisce il proprio indirizzo lato client nel campo dell’indirizzo del gateway. È quell’indirizzo che il server servirà, quindi deve essere raggiungibile dalla sede remota attraverso il tunnel, non solo localmente.

Seconda fase: portate il traffico generato dall’ASA attraverso il tunnel

Questo è il passaggio che le persone saltano. Una VPN site-to-site basata su politiche è di solito costruita per il traffico tra subnet, e la richiesta di relay la genera l’ASA stessa. Se la lista di accesso del tunnel e la mappa crittografica corrispondono solo ai flussi da host della sede alla subnet del server, il pacchetto di relay potrebbe non entrare mai nel tunnel. Controllate la lista di accesso in entrambe le direzioni, non solo la riga dalla sede al server.

Confermate che il traffico interessante copra l’origine del relay dell’ASA e l’indirizzo del server, e che anche la direzione di ritorno sia consentita. In un progetto basato su VTI la decisione di routing è più semplice, ma il supporto del relay su VTI è arrivato in una versione specifica; la guida DHCP dell’ASA indica la 9.14(1), quindi controllate l’immagine prima di copiare un esempio VTI su un apparato più vecchio.

Un ping dall’ASA al server dimostra poco da solo. Può riuscire attraverso un altro percorso, con un altro indirizzo sorgente o sotto una politica che i pacchetti del relay non soddisfano.

Terza fase: leggete la risposta e l’opzione setroute

La RFC 2131 afferma che il server invia la risposta all’indirizzo nel campo giaddr quando quel campo non è zero. Quindi il percorso di ritorno deve essere instradato verso l’indirizzo del relay, e la politica del tunnel deve consentire la direzione dal server al relay. Se la richiesta è passata ma l’offerta non arriva mai, è qui che bisogna guardare.

Poi separate due cose che suonano simili. La parola chiave setroute modifica o aggiunge l’opzione di router predefinito che l’ASA consegna al client. Non installa una rotta sull’ASA e non crea politica VPN. Un client che ottiene un indirizzo ma non raggiunge nulla spesso ha un problema di setroute o di ambito, non di tunnel. Provatelo con un client senza gateway statico e osservate quale router predefinito compare nell’offerta.

Leggete l’offerta dall’inizio alla fine: indirizzo offerto, maschera, router predefinito, DNS e durata del lease. Poi lasciate che il lease si rinnovi. Un relay che funziona una volta e fallisce al rinnovo ha di solito un problema di ambito, di lease o di percorso di ritorno che il primo scambio ha nascosto.

Cosa controllo prima di dire che è risolto

Partite dal client e catturate il broadcast, poi confermate che l’ASA lo ha inoltrato con il proprio indirizzo come giaddr. Sul lato remoto confermate che il server ha visto quella richiesta e ha scelto un ambito che corrisponde alla sede. Tornati in sede, confermate che il client ha accettato l’offerta e raggiunge il proprio gateway.

Se qualche fase è silenziosa, controllate la politica o la rotta corrispondente invece di aggiungere un’altra istruzione di relay. La configurazione del relay di solito è già corretta nel momento in cui qualcuno escala il caso; quello che è cambiato è la politica del tunnel o la rotta di ritorno.

Scrivete le tre fasi nel registro delle modifiche: interfaccia lato client, politica VPN che copre il traffico di relay e rotta di ritorno del server verso giaddr. È quel registro che rende la successiva realizzazione di una sede un lavoro ripetibile invece di una sessione di debug. Dice anche all’ingegnere successivo quale output di comando raccogliere per primo.