Utente gateway in Access Server: instradare la LAN della sede di un client

Potete fare ping all’indirizzo di tunnel di un client OpenVPN e comunque non raggiungere nessun host sulla LAN che sta dietro. Access Server assegna al client un indirizzo dal pool VPN, e l’indirizzo del pool è tutto ciò che il server sa di possedere. Il prefisso della sede è un fatto separato che va dichiarato, e anche allora la sede ha bisogno di un inoltro e la direzione centrale di una rotta di ritorno. Una rotta scritta nel posto sbagliato sembra una correzione e non cambia nulla.

Due indirizzi, due rivendicazioni di proprietà diverse

Quando un client si connette, Access Server gli assegna un indirizzo dal pool VPN configurato, per esempio 10.90.0.0/24. Quell’assegnazione è un lease per un solo host. Nulla nella connessione dice che lo stesso client sia anche davanti a 10.60.0.0/24, e il server non indovina: un prefisso LAN è raggiungibile tramite un client preciso solo se un amministratore lo dichiara.

Per questo una rotta statica su un’altra macchina non serve. La rotta dice invia 10.60.0.0/24 a questo indirizzo, ma se l’indirizzo appartiene a un client mai marcato come gateway, il server non ha motivo di consegnare quei pacchetti lì, e lo stack del client può scartarli. La dichiarazione e la rotta sono due metà dello stesso meccanismo.

Cosa installa davvero l’impostazione gateway

Nell’interfaccia di amministrazione la dichiarazione è una proprietà utente: abilitate Configure VPN gateway sull’utente connettore e inserite il prefisso reale della sede in Network on the VPN client side. Quell’utente si autentica come gli altri, quindi serve una politica di credenziali adatta a un dispositivo senza sorveglianza, e il suo profilo di accesso automatico è un segreto, non un file di comodità.

Dietro quella casella il server tratta il prefisso come raggiungibile tramite l’indirizzo di pool di quel client, e la configurazione di routing sotto Access Controls decide cosa viene annunciato agli altri client: le rotte inviate ai client ordinari e le regole di accesso che consentono il traffico dalle reti della direzione verso indirizzi e sottoreti dei client. Abilitate il routing per le reti che devono raggiungere la sede e mantenete corta la lista consentita.

Una direttiva in stile Community incollata in un file generato non partecipa a questo modello. Il prodotto possiede la tabella di routing che invia; una riga modificata a mano viene sovrascritta alla generazione successiva o ignorata.

Completate le rotte di ritorno di entrambe le reti

Un piano concreto: direzione 10.40.0.0/24, sede 10.60.0.0/24, pool VPN 10.90.0.0/24, e Access Server raggiungibile su un indirizzo privato lato direzione. Il router della direzione ha bisogno di rotte per il prefisso della sede e per il pool, entrambe verso Access Server. Senza di esse il tunnel porta la richiesta e la risposta esce dal gateway predefinito, producendo la classica connessione semiaperta.

Nella sede il connettore deve inoltrare i pacchetti non indirizzati a sé: inoltro IP nel sistema operativo più un’autorizzazione di inoltro limitata alle interfacce del tunnel e della LAN; su Linux è net.ipv4.ip_forward=1 con le regole della catena forward, su Windows è routing and remote access. Poi gli host della sede hanno bisogno di una rotta di ritorno: o il connettore è il loro gateway predefinito, o il gateway esistente porta rotte specifiche per i prefissi della direzione e del pool.

La tabella di routing del connettore non riconfigura ogni host della LAN della sede. Se gli host puntano a un altro router, le rotte di ritorno appartengono a quello, e deve accettare che l’indirizzo di origine che vede non sia un vicino della sottorete locale.

Leggete un guasto come un percorso, non come un permesso

Provate in un ordine fisso. Prima un servizio consentito da Access Server verso un host della sede, poi lo stesso servizio da un host ordinario della direzione, poi la direzione inversa se la politica lo consente. Se il primo passa e il secondo no, il problema sono le rotte inviate o le regole di accesso. Se entrambi passano ma non arrivano risposte, esaminate l’inoltro nella sede e la rotta di ritorno nella direzione.

Il firewall dell’host è il sospetto successivo, perché con accesso instradato la destinazione vede come origine un indirizzo della direzione o del pool. Una regola scritta per la sottorete locale non corrisponderà e il pacchetto viene scartato dopo che il routing ha funzionato perfettamente.

Due progetti richiedono di più. Prefissi sovrapposti tra sedi rendono ambigua la destinazione e richiedono rinumerazione o traduzione, e un Access Server in cluster richiede che ogni nodo abbia un percorso funzionante verso il connettore della sede, non un solo nodo che tiene la rotta. Applicate le modifiche tramite il normale percorso di salvataggio e aggiornamento, ricollegate il connettore e verificate di nuovo da entrambi i lati; un riavvio completo di ogni macchina non fa parte della procedura.

Il tutorial site-to-site di Access Server elenca le stesse impostazioni nell’ordine del prodotto; vale la pena seguirlo una volta prima di adattare il progetto ai vostri prefissi.