Un gateway VPN richiede l'inoltro IP: cosa controllare

Il vostro client può fare ping all'indirizzo del gateway mentre ogni risorsa dietro di esso resta irraggiungibile. Questa coppia di osservazioni descrive un host che vi parla e un router che non instrada, due ruoli diversi sulla stessa macchina. L'inoltro è l'interruttore tra i due.

I due ruoli sono indipendenti, e così le due famiglie di indirizzi.

Rispondere al proprio indirizzo non dimostra nulla

Quando un pacchetto è indirizzato al gateway stesso, lo stack locale lo consuma e non avviene alcuna decisione di inoltro. Per questo un ping riuscito all'indirizzo del tunnel o a un'interfaccia di gestione vi dice che il demone è vivo e il tunnel è attivo, senza dire nulla sul traffico destinato a una rete dietro la scatola. Il kernel consulta il proprio percorso di inoltro solo per i pacchetti che non sono indirizzati a lui.

Leggete il requisito come un ruolo, non come un'impostazione: questo host deve spostare pacchetti tra due interfacce. Un portatile che deve solo raggiungere una rete remota non assume mai quel ruolo, e un endpoint sito-a-sito lo assume sempre. Leggere il requisito in questo modo spiega perché una configurazione client funzionante fallisce quando viene spostata su un gateway.

La stessa frase vale per il firewall davanti alla decisione di inoltro, che ha una propria politica su ciò che può essere inoltrato.

Controllate ogni famiglia di indirizzi separatamente

L'inoltro IPv4 è un interruttore, e l'inoltro IPv6 è un altro con il proprio comportamento per interfaccia. Abilitare il primo non dice nulla sul secondo, e un client dual-stack può raggiungere metà di una rete mentre il resto resta al buio. Due client di famiglie diverse possono quindi non essere d'accordo sullo stesso gateway. Chiedete quale famiglia ha usato il client che fallisce prima di modificare l'una o l'altra impostazione. Confermate entrambe prima di concludere che il progetto di instradamento è sbagliato.

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

Su molte distribuzioni il valore che leggete a runtime è stato messo lì da un servizio o da un file di configurazione, quindi una modifica fatta con un comando una tantum può sparire al riavvio. Trovate il file che possiede l'impostazione prima di modificare il valore a runtime.

L'inoltro è uno dei quattro requisiti

Un flusso inoltrato funzionante richiede quattro cose insieme: il client deve sapere che la destinazione è dietro il tunnel, il gateway deve avere una rotta in avanti, le risposte devono avere un percorso di ritorno e il firewall deve consentire il traffico. La traduzione di sorgente fa parte di quel progetto come opzione e non come regola, perché una rete instradata privata con percorsi simmetrici non ne ha bisogno e una asimmetrica di solito sì. Ciascuna delle quattro fallisce in modo indipendente, per questo ripararne una raramente sposta il sintomo. Scrivete tutte e quattro prima di cambiarne una.

Le piattaforme cloud aggiungono una quinta considerazione. Alcune applicano controlli di origine e destinazione alle istanze, il che scarta i pacchetti inoltrati indipendentemente da come è configurato il kernel dell'ospite. La documentazione di rete della piattaforma stessa è l'autorità in materia, non l'output di sysctl dentro la VM.

Provate dal client, non dal gateway

Un test eseguito nella shell del gateway stesso non attraversa nessuna parte del percorso di inoltro che avete appena abilitato. Generate il traffico dal client che ha il problema e confermate che raggiunge qualcosa dietro il gateway e non il gateway stesso. È l'unico test che esercita il ruolo che avete cambiato.

Tenete separate le regole di ascolto e le regole di inoltro nella testa e nel registro delle modifiche. Aprire la porta VPN ammette i client al servizio; non concede loro nulla sulla rete dietro, e le due cose sembrano identiche in un elenco del firewall cresciuto negli anni.

Se i pacchetti arrivano e il servizio rifiuta poi l'utente, siete andati oltre la rete. Continuate con l'autorizzazione applicativa invece di allargare di nuovo la politica di inoltro.