Mantieni l’SSH locale quando l’host usa una VPN in uscita

Un piccolo server Linux usa una VPN in uscita per l’applicazione che ospita, e l’amministratore vuole ancora raggiungerlo via SSH dalla scrivania accanto. È un requisito ragionevole, e di solito non richiede né port forwarding, né un indirizzo del fornitore, né un buco nel tunnel. Ciò che serve è un percorso di gestione progettato apposta invece che ereditato da ciò che il client VPN ha fatto alla tabella di routing.

I passaggi seguenti presuppongono che l’amministratore sia sulla stessa LAN.L’amministrazione remota è un altro problema con un’altra risposta.

Associa SSH all’indirizzo che usano gli amministratori

Inizia dal listener.ss -ltnp | grep :22 mostra a cosa è legato sshd, e un listener su 0.0.0.0 accetta connessioni da ogni interfaccia, incluso il tunnel. Legarsi all’indirizzo della LAN è più stretto e rende visibile l’intenzione:ListenAddress 192.168.10.20 in sshd_config, seguito da un test di configurazione e un ricaricamento. Un errore di battitura in quell’indirizzo è più visibile di un carattere jolly, perché sshd rifiuta di avviarsi quando l’indirizzo non esiste.

Mantieni il controllo della chiave dell’host e l’autenticazione per utente esattamente come sono. «È solo la rete locale» non è un metodo di autenticazione, e un canale di gestione che salta la verifica della chiave perché la rotta è corta è un canale di gestione in attesa di abuso. Una prenotazione DHCP o un indirizzo statico rende prevedibile l’obiettivo senza farne l’identità pubblica del server.

Tieni la rotta della LAN fuori dal tunnel

Un host con un indirizzo in 192.168.10.0/24 ha una rotta connessa per quel prefisso, e una rotta più specifica batte quella predefinita della VPN nella stessa tabella. Per questo l’SSH locale spesso continua a funzionare da solo quando il tunnel sale. Verificalo invece di darlo per scontato:ip route get 192.168.10.50 nomina l’interfaccia e l’indirizzo sorgente che il kernel userebbe, e la risposta dovrebbe essere il dispositivo della LAN, non il tunnel. Ripeti il controllo anche dalla macchina dell’amministratore, perché la sua tabella decide se i pacchetti arrivano davvero. Due host sullo stesso cavo possono non essere d’accordo su quale direzione sia raggiungibile.

L’ipotesi si rompe in due punti. Una regola di routing basata su policy può inviare traffico a una tabella la cui predefinita punta nel tunnel prima che venga consultata la tabella principale. Un client VPN con funzione di blocco o kill-switch può anche bloccare traffico che non entra nel tunnel, indipendentemente da ciò che dice la tabella di routing.

Le VLAN di gestione instradate sono l’altro caso. Se l’amministratore è su 192.168.50.0/24 dietro il router locale, il server ha bisogno di una rotta esplicita per quel prefisso attraverso 192.168.10.1, e quella rotta deve sopravvivere a una riconnessione. Mantieni l’eccezione specifica per il prefisso di gestione; un’eccezione ampia per gli intervalli privati annulla lo scopo del tunnel.

Rendi l’eccezione del firewall stretta quanto la regola

Se l’host esegue un firewall, consenti SSH solo dalla sorgente di gestione e solo sull’interfaccia della LAN. Una regola che consente la porta 22 da ovunque è più ampia del requisito e più difficile da giustificare in una revisione. Su un host nftables la regola va nella catena di input con interfaccia e sorgente abbinate; su un host iptables l’equivalente è una coppia di corrispondenze su -i e -s. Commenta la regola con il gruppo di amministratori a cui serve, così il prossimo audit non deve indovinare perché la porta 22 è aperta.

Controlla anche il filtro proprio del client VPN. Alcuni client installano regole che scartano il traffico locale per progetto, e una regola firewall corretta sopra uno scarto a livello di client non cambia nulla. Leggi la configurazione del client prima di modificare il firewall dell’host, perché due filtri in serie producono un guasto che non assomiglia a nessuno dei due.

Prova entrambi gli stati

Esegui il test due volte: una con il tunnel connesso e una con il tunnel disconnesso. In ogni stato, conferma il listener, la rotta e un accesso SSH reale dalla macchina dell’amministratore. Un percorso che funziona solo mentre il tunnel è attivo non è un percorso di gestione locale; è una coincidenza.

Poi riavvia il tunnel mentre una sessione SSH è aperta. Una sessione che sopravvive dimostra che il routing è stabile; una sessione che cade ti dice che il client riscrive rotte o filtri alla riconnessione, cosa che vale la pena sapere prima di un incidente più che durante.

Annota l’indirizzo sorgente da cui hai provato, perché una regola scritta per 192.168.10.50 fallisce silenziosamente quando il portatile dell’amministratore si sposta su un’altra sottorete.

Scrivi il percorso di ripristino nel runbook

Decidi ora cosa succede se la VPN in uscita rompe il percorso locale. L’accesso da console, un secondo indirizzo di gestione o una procedura documentata per fermare il client sono tutte risposte legittime, e ciascuna è meglio che scoprire il problema nel momento in cui devi accedere. Se il server è remoto, il percorso locale non esiste, e il progetto corretto è una rotta di accesso remoto approvata e separata o un bastion invece di una porta pubblica esposta.

Tieni i due ruoli separati nella documentazione: l’SSH locale per l’amministratore che è vicino, e il tunnel in uscita per il traffico dell’applicazione. Quando quei ruoli sono scritti, una modifica futura a uno dei due ha un punto evidente dove essere verificata, e la persona successiva non deve riscoprire perché un server con una VPN risponde ancora sul suo indirizzo LAN.