CIDR di gruppo in Access Server: indirizzi dei membri o rete di risorse

In un gruppo Access Server due campi accettano un CIDR e a prima vista sembrano lo stesso tipo di input: uno descrive gli indirizzi assegnati ai membri della VPN, l'altro descrive le reti che quei membri possono raggiungere. Compilare il campo sbagliato viene accettato senza errori, ed è proprio questo che rende l'errore costoso. Il primo cambia il piano di indirizzamento del tunnel, il secondo decide quali destinazioni sono consentite, e nessuno dei due implica l'altro. C è anche un terzo oggetto che le persone confondono con questi due, la sottorete dietro il gateway di una sede, e non appartiene a nessuno dei due campi.

Stessa sintassi, domande diverse

Chiediti che cosa nomina il valore. Un CIDR di indirizzi dei membri risponde alla domanda su quali indirizzi interni ricevono i client che si collegano, e la macchina di assegnazione lo consuma prima che scorra qualsiasi traffico. Un CIDR di risorsa risponde su quali destinazioni questo gruppo può usare, e le regole di accesso lo consumano quando un pacchetto viene valutato. Uno è la definizione di un pool, l'altro è un permesso.

Le conseguenze della confusione sono opposte. Una LAN di destinazione incollata nel campo del pool può distribuire indirizzi che esistono già su quella LAN, producendo un comportamento da indirizzi duplicati, oppure spostare il pool al punto da rompere silenziosamente tutte le regole del firewall scritte per la vecchia gamma. Un pool incollato in una regola di accesso non concede nulla di utile, perché lì non abita alcuna destinazione. Entrambi gli errori si presentano allo stesso modo: il tunnel è attivo ma qualcosa non va.

Assegnazione: lo spazio di indirizzi dei membri

Il pool non deve sovrapporsi a nessuna LAN raggiungibile da un membro né a nessun altro pool VPN della distribuzione. È un vincolo di progettazione, non un'impostazione del prodotto: con due sedi che usano entrambe 10.90.40.0/24 per i membri, un membro di una sede non può instradare verso l'altra senza traduzione, e nessuna regola di accesso lo risolve.

Anche la modalità di assegnazione conta. Un pool dinamico assegna a ogni membro il prossimo indirizzo libero, mentre un'assegnazione statica per utente lo fissa. L assegnazione statica è quella che vuoi quando le regole del firewall o il monitoraggio si riferiscono a singoli membri, e rende anche visibile un cambio del piano di indirizzamento: l'indirizzo fissato rientra ancora nel nuovo pool oppure no. Leggi l'indirizzo del tunnel di un membro connesso prima e dopo ogni modifica di questo campo.

Permesso: le reti di destinazione stanno nelle regole di accesso

La raggiungibilità si esprime nelle regole di accesso, che nominano il gruppo o gli utenti, una rete o un servizio di destinazione e il metodo di accesso. Quest ultima parte è dove muoiono la maggior parte delle configurazioni a metà: una regola può instradare il traffico verso la destinazione o applicargli NAT, e le due cose chiedono alla rete cose diverse. Un percorso instradato richiede che il lato destinazione sappia restituire il traffico al pool VPN, mentre un percorso NAT nasconde i membri dietro un'indirizzo di cui la destinazione si fida già. La documentazione dei gruppi Access Server tiene la rete del gruppo separata dalle regole di accesso del gruppo, e le etichette si sono spostate tra le versioni.

Una destinazione consentita ha comunque bisogno di un percorso utilizzabile. La regola permette, la rotta consegna, il percorso di ritorno risponde e il servizio sull host accetta. Quattro cose, quattro posti da guardare, e solo la prima vive nella regola di accesso. Un permesso verde con un traceroute morto di solito significa che manca la rotta di ritorno sul gateway della destinazione, non che la regola sia sbagliata.

Il terzo oggetto: una sottorete di sede dietro un gateway

Dichiarare che un determinato client possiede una sottorete è un'affermazione di routing su una sede, non un'assegnazione di indirizzi e non un permesso. In termini Access Server è la configurazione del gateway supportata per una rete che si collega, ed esiste perché un router di sede può annunciare la LAN che ha dietro. I membri ricevono comunque indirizzi dal pool e hanno comunque bisogno di una regola di accesso per usare quella LAN di sede.

Tenere i tre separati ripaga in fase di revisione. Una sottorete di sede registrata come spazio di indirizzi dei membri del gruppo sembra corretta in uno screenshot e rompe l'assegnazione per tutti quelli del gruppo. La stessa sottorete annotata solo in una regola di accesso concede l'accesso senza la dichiarazione di proprietà, così il traffico di ritorno non ha dove andare. Metti ogni oggetto nella propria colonna del progetto e l'errore non è più possibile.

Come capire quale stai guardando

Leggi l'etichetta insieme ai suoi vicini. Un campo accanto a una modalità di assegnazione, a una dimensione del pool o a un'override per utente riguarda l'assegnazione. Un campo accanto a un selettore di gruppo, a un servizio o porta e a un metodo di routing riguarda il permesso. Le versioni rinominano le cose, ma i vicini restano più o meno al loro posto, ed è per questo che la formulazione di uno screenshot vecchio è una cattiva guida alla navigazione.

Poi verifica con un solo membro invece che con tutto il gruppo: il suo gruppo effettivo, l'indirizzo del tunnel assegnato e la regola che autorizza la destinazione prevista. Conferma la rotta, il NAT o il percorso instradato, il traffico di ritorno e il permesso del servizio in quest'ordine, e cambia solo il campo che corrisponde alla discrepanza dimostrata. Tieni poi separati i registri di assegnazione e di permesso, così che un cambio successivo del pool non venga letto come un cambio in ciò che il gruppo può raggiungere.