Perché i client di Access Server non sono raggiungibili dalla LAN

Il portatile si connette, il tunnel è attivo e le richieste verso un servizio interno si bloccano al collegamento. Sul servizio stesso la richiesta arriva da un indirizzo come 10.90.0.25, la risposta esce verso il gateway predefinito e nulla torna indietro, perché quel gateway non ha idea di dove si trovi 10.90.0.25. Dall’altra estremità lo stesso guasto appare come un host interno che non riesce a fare ping a un client connesso. Entrambi sono un solo oggetto mancante: una rotta di ritorno verso il pool di client VPN, che solo la rete privata può aggiungere.

Leggi l’indirizzo di origine che vede il servizio

Quel singolo campo decide tutto il resto. Se il servizio interno vede l’indirizzo del pool, Access Server instrada invece di nascondere il traffico dei client, e ogni risposta deve essere instradata verso il pool. Se invece vede l’indirizzo privato del server stesso, il server fa masquerade e il percorso di ritorno già funziona, al costo di perdere qualsiasi identità per client nei log e nelle regole di accesso del servizio.

Confronta entrambe le estremità prima di cambiare qualcosa. Sul server elenca le interfacce del tunnel e i loro indirizzi; sul client verifica quale di questi indirizzi detiene davvero; sull’host interno guarda una connessione attiva.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

L’ultimo comando è quello che fallisce nel caso rotto: o segnala il prefisso del tunnel come irraggiungibile o, peggio, restituisce il gateway predefinito, ed è così che le risposte finiscono su internet.

Non dare per scontato un solo pool. Un server può avere un intervallo dinamico più assegnazioni statiche per utente, e l’indirizzo statico può trovarsi del tutto fuori dal prefisso dinamico. Se instradi solo l’intervallo che ricordi, gli utenti con indirizzi fissi restano rotti e tutti gli altri segnalano il problema come risolto.

Aggiungi la rotta dove si decide la risposta

La rotta appartiene al gateway che il servizio interno già usa, non al servizio, a meno che non instradi il proprio traffico. Puntala all’indirizzo privato raggiungibile di Access Server, che è un valore diverso dall’indirizzo del tunnel che ha un client.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

In una rete cloud la stessa affermazione diventa una voce della tabella di routing il cui target è l’istanza o l’interfaccia di rete su cui gira il server, con il controllo di origine e destinazione disattivato su quell’interfaccia. Nota cosa non fa quella voce: una rotta non è una concessione di accesso, quindi i gruppi di sicurezza, le ACL di rete e il firewall dell’host devono comunque consentire il traffico.

Rendila persistente e mantieni onesti i dimensionamenti dei pool. Due pool non contigui richiedono due rotte, e un pool che cresce oltre il prefisso configurato produce silenziosamente client le cui risposte non hanno dove andare. Se controlli gli intervalli dei pool, scegli un riepilogo che puoi instradare una volta e lasciare stare.

L’inoltro e i filtri devono concordare con la rotta

L’instradamento è solo metà del percorso. Al server deve essere permesso inoltrare tra il tunnel e l’interfaccia privata, che su Linux significa net.ipv4.ip_forward più una catena di inoltro che consenta la coppia di interfacce, e su un host rafforzato di solito una regola esplicita per ogni direzione.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Il filtraggio con stato spiega un sintomo che porta le persone sulla strada sbagliata. Una risposta dentro un flusso stabilito non ha bisogno di una nuova regola in ingresso, quindi una connessione che si blocca dopo il SYN-ACK non è bloccata da una regola di accettazione mancante; viene scartata o instradata male. Mantieni questa distinzione, perché separa un cambio di routing da un cambio di firewall.

I percorsi di ritorno asimmetrici sono la versione più silenziosa dello stesso problema. Se due rotte raggiungono il pool e la risposta prende quella che esce da un’interfaccia diversa da quella su cui è arrivata la richiesta, il filtraggio rigoroso del percorso inverso la scarta e il flusso fallisce solo per alcuni client.

Instradato o mascherato: scegli consapevolmente

La modalità instradata conserva l’indirizzo del pool del client sul servizio, il che rende possibili logging e policy per client, e in cambio ogni rete interna che deve rispondere a un client ha bisogno della rotta del pool. La modalità mascherata elimina questo requisito perché le risposte tornano al server, ma il servizio non distingue più un client dall’altro e non può avviare nulla verso un client specifico.

Cambiare questo comportamento su un server in produzione interrompe le sessioni esistenti, quindi prova prima con un client e un flusso. Se il passaggio è la risposta giusta, è una decisione di configurazione sul server, non qualcosa da aggirare aggiungendo rotte che diventeranno inutili.

Una sottorete dietro il client è un compito a parte

Raggiungere un dispositivo sulla LAN del portatile stesso non è la stessa cosa che raggiungere l’indirizzo del tunnel del portatile. Richiede che il client agisca come gateway di sottorete: una rete dichiarata sul lato client, l’inoltro abilitato nel sistema operativo del client e una rotta su quella LAN verso il client. Aggiungere una rotta di rete privata per l’intervallo domestico del portatile non lo fa, e crea conflitti quando due utenti hanno lo stesso intervallo domestico.

Anche la direzione è una questione di policy. Il permesso per un client di aprire una connessione verso un servizio interno non consente automaticamente a un host interno di aprire una connessione verso quel client. Controlla la policy di accesso del server e il firewall dell’host client prima di concludere che il percorso è rotto.

Verifica con un flusso e una cattura

Dimostra il percorso con una sola connessione invece di un test di raggiungibilità generico. Osserva lo stesso flusso alle due estremità: la richiesta che arriva al servizio e la risposta che lo lascia.

tcpdump -ni any host 10.90.0.25 and port 443

Prima della correzione la cattura mostra la risposta che esce verso un gateway che non la instraderà. Dopo la correzione la risposta esce verso il server e il flusso si completa. Poi conferma la rotta che il gateway userebbe per un secondo indirizzo client, così un pool che non hai coperto emerge adesso e non tra una settimana.

Chiudi con i quattro controlli che risolvono la questione: l’indirizzo di origine sul servizio corrisponde alla modalità prevista, il gateway ha una rotta per ogni pool in uso, l’inoltro e i filtri consentono entrambe le direzioni, e un flusso reale si completa da un capo all’altro. Domande frequenti sul routing di Access Server enuncia lo stesso principio per la versione installata, la cui interfaccia di configurazione supportata può differire dalle guide più vecchie.