Come pianificare un pool di indirizzi per client VPN che regga

Iniziate dal campo del pool sul server VPN, non da un foglio di calcolo. Quello che digitate lì diventa lo spazio di indirizzi interno per ogni client che si collega in seguito, e deve convivere con la LAN che quei client raggiungono, con i siti instradati dietro di essa e con qualsiasi indirizzo che il client possiede già a casa. Collegate un client appena il pool viene salvato, perché quella prima connessione vi dice se il valore funziona in pratica. Da lì la passeggiata si sposta verso l'esterno: l'indirizzo che il client ha ricevuto, il percorso che compie una risposta e la nota che lasciate dietro di voi.

Iniziate dal campo del pool, prima che si colleghi qualsiasi client

Ogni prodotto lo espone in modo diverso, quindi trovate l'oggetto che assegna davvero gli indirizzi. OpenVPN ha una direttiva pool lato server che distribuisce il prossimo indirizzo libero, un gateway IKEv2 ha una sezione pool legata alla configurazione del peer, e WireGuard non ha nessuna delle due perché ogni peer porta il proprio indirizzo nel suo file di configurazione. Una direttiva pool e un indirizzo per peer non sono intercambiabili, e modificare quella sbagliata spreca il resto della passeggiata.

Una volta ottenuto il campo, elencate gli intervalli che esistono già: la LAN dell'ufficio, ogni sito instradato, la VPC del cloud e qualsiasi altro pool ancora in servizio. La sovrapposizione si decide con l'aritmetica del prefisso, non con il fatto che i numeri host sembrino familiari, quindi confrontate l'aggregato con ciascuno di quegli intervalli. Due intervalli che sembrano entrambi 10.x sono innocui quando i loro aggregati non si intersecano e un incidente di supporto quando si intersecano.

Poi decidete se l'indirizzo è funzione di chi si collega o di quando si collega. L'assegnazione dinamica distribuisce ciò che è libero, mentre l'assegnazione per identità lega un indirizzo fisso a una credenziale. Annotate la scelta, perché cambia l'aspetto che una riconnessione deve avere in seguito.

Leggete l'indirizzo che il client ha effettivamente ricevuto

Collegate un client e leggete quello che riporta il tunnel, non quello che il pool aveva promesso. Il client mostra il proprio indirizzo interno nello stato della connessione, e su Linux l'interfaccia lo porta direttamente.

Confrontate quell'indirizzo con l'intervallo che avete salvato. Se è fuori dall'intervallo, state guardando un percorso di assegnazione diverso da quello che avete modificato. Controllate anche la lunghezza del prefisso, perché un client con un /32 non ha alcun peer on-link e invia ogni destinazione attraverso la sua rotta predefinita.

ip -4 addr show tun0
ip route get 192.168.50.20

Un client che si collega da un router domestico che usa lo stesso intervallo si collegherà e poi non raggiungerà quasi nulla. Il client conserva la sua rotta locale per quel prefisso, quindi l'indirizzo del tunnel entra in collisione con la rete dietro di esso e il traffico esce dall'interfaccia sbagliata. Quel caso non si può riparare sul server; il rimedio documentato è rinumerare la rete domestica o scegliere un intervallo del pool abbastanza lontano perché le collisioni restino rare. Annotate sia il guasto sia il rimedio, perché l'help desk lo incontrerà di nuovo.

Ricollegate lo stesso client e osservate l'indirizzo. Un pool dinamico può restituire lo stesso valore o uno diverso ed entrambi sono corretti, mentre un pool per identità che cambia l'indirizzo non rispetta il legame. Quel controllo richiede secondi e stabilisce se la modalità annotata nella prima sezione è quella in vigore.

Seguite una risposta al ritorno dal servizio

Il pool funziona solo quando le risposte possono viaggiare indietro fino a esso. Un servizio sulla LAN risponde all'indirizzo interno, quindi il suo gateway ha bisogno di una rotta per il pool o di una traduzione davanti al servizio. Quando una richiesta arriva dal tunnel e la risposta esce da un percorso diverso, un firewall stateful o un controllo di reverse path la scarta, e il client vede un servizio che si collega e poi si blocca. Mettete il pool nel progetto di routing come un unico blocco riassumibile invece di aggiungere rotte per host.

La traduzione cambia ciò che vede il resto del sistema. Quando l'origine viene riscritta, l'indirizzo nel firewall dell'host e nel registro dell'applicazione è quello tradotto, quindi una regola scritta contro l'indirizzo del pool non corrisponde a nulla e una riga di registro non è riconducibile a un client. La documentazione di strongSwan sull'inoltro copre la metà lato server di quel percorso per un gateway IKEv2. Il DNS porta lo stesso vincolo, perché un nome che risolve in un indirizzo che il client non può raggiungere fallisce più tardi e altrove.

Due client, poi una revoca

Collegate due client contemporaneamente e leggete entrambi gli indirizzi. Devono essere distinti, utilizzabili e dentro il pool, e ciascuno deve raggiungere il servizio a cui è destinato. Un pool che distribuisce indirizzi duplicati di solito si mostra qui e non nel primo test con un solo client.

Revocate una credenziale mentre l'altro client resta collegato, poi provate il servizio dal client sopravvissuto. Una revoca che disturba l'altra sessione indica stato condiviso, molto spesso una credenziale o un indirizzo riutilizzato tra dispositivi. Ricollegate il client revocato e confermate che viene rifiutato invece di ricevere l'indirizzo liberato.

Chiudete con una destinazione che dovrebbe essere negata. Un client che raggiunge tutto è stato collegato, non provato.

Scrivete i quattro valori dove il prossimo cambiamento li troverà

La nota è breve: l'intervallo e il prefisso del pool, la modalità di assegnazione, il percorso di ritorno o la traduzione in uso e l'ambito DNS che risponde per quelle destinazioni. Mettetela accanto alla configurazione del server invece che in un ticket, e datela. Chi modifica uno dei quattro più avanti ha bisogno degli altri tre davanti, perché un ridimensionamento del pool rompe la rotta e un cambio di rotta rompe la risposta DNS.

Teneteci insieme la nota di proprietà: l'intervallo del tunnel appartiene al server VPN, e una prenotazione fatta nell'ambito DHCP della LAN non prenota nulla per un client dentro il tunnel. Quella singola riga evita la rilavorazione più comune, in cui qualcuno aggiunge una prenotazione e si aspetta che l'indirizzo del tunnel la segua.