Perché una regola sulla porta di origine rompe uno dei tuoi percorsi SSH

Due voci di gestione su un solo host, un solo servizio di rete e una regola di policy che doveva aiutare entrambe. La regola corrisponde alla porta di origine 22, invia la ricerca a una tabella che conosce solo il valore predefinito WAN, e la voce VPN smette di rispondere ai nuovi accessi mentre la voce diretta continua a funzionare. Nulla di tutto ciò è misterioso una volta che il selettore viene letto correttamente. Una porta di origine identifica un servizio, non il percorso da cui è arrivata una connessione.

Due voci, un servizio di rete

L'host ha un indirizzo lato LAN e un indirizzo VPN, e sshd è in ascolto su entrambi. Una sessione diretta e una sessione in tunnel condividono quindi la porta del servizio e differiscono solo in quale indirizzo locale riceve la connessione.

Questa differenza basta a scegliere un percorso di risposta, ed è esattamente la differenza che una regola basata sulla porta scarta. Entrambe le sessioni producono risposte la cui porta di origine è 22, quindi una regola che corrisponde a quella porta non può separarle. Invia entrambe le ricerche alla stessa tabella, e una di esse riceve una risposta che non si adatta. La correzione è far corrispondere l'attributo che differisce davvero.

Dare a ogni voce la propria porta funzionerebbe ugualmente, e trattarlo come un requisito è una scelta di progettazione, non una proprietà di SSH.

Leggi la regola, poi la tabella

Una regola di policy è un selettore ordinato, e la prima che restituisce una risposta utilizzabile termina la ricerca. Leggi l'elenco in ordine e nota quale regola può vincere.

Poi leggi la tabella a cui quella regola punta, perché una regola che si risolve con successo non è una regola che si risolve in modo utile. Una tabella che contiene solo una rotta predefinita invia la risposta di origine VPN fuori dall'interfaccia WAN. Una rotta più specifica in una tabella successiva non viene mai consultata, ed è per questo che aggiungere una seconda tabella spesso non cambia nulla. La tabella selezionata è ciò che va ispezionato.

ip -4 rule show
ip route show table 100
ip route show table main

Queste due uscite insieme spiegano il risultato; ciascuna da sola invita a una conclusione errata.

Limita la regola al flusso che intendi

L'attributo che separa le due voci è l'indirizzo di origine locale. Una regola che corrisponde a quell'indirizzo invia solo le sessioni in tunnel alla tabella privata e lascia le sessioni dirette sulla tabella principale.

Quella regola va abbinata a una tabella che contenga la rotta privata e il percorso di ritorno per quella sottorete. Limita entrambe al traffico di gestione invece che a ogni servizio dell'host. Una regola che cattura tutto il traffico da quell'indirizzo reindirizzerà anche qualsiasi altra cosa che l'host invia da lì. Lo stretto batte l'astuto qui, perché la persona successiva deve leggerlo.

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

Se entrambe le voci vengono tradotte su un unico indirizzo locale, quella distinzione scompare e il progetto necessita invece di uno stato consapevole della connessione.

Tieni separati ascoltatore, autorizzazione e selezione della risposta

Tre cose distinte devono essere vere prima che una sessione funzioni: l'indirizzo esiste, il servizio è in ascolto e la risposta trova la via del ritorno. Un cambio di rotta corregge solo la terza.

La configurazione dell'ascoltatore è un file a sé e un ricaricamento a sé, e più indirizzi di ascolto sono normali. L'autenticazione è ancora una terza decisione, e un'eccezione di routing non concede accesso a nessuno. Mantieni verifica della chiave host, autenticazione dell'account e restrizioni di origine su entrambe le voci, e resisti alla tentazione di indebolire gli altri controlli del tunnel perché un solo percorso di gestione funzioni.

Mantieni un canale di ripristino che non dipenda dal percorso che stai modificando, perché un errore qui blocca la correzione stessa.

Dimostralo con una sessione nuova, non con una vecchia

Un terminale stabilito non dimostra nulla, poiché è stato ammesso prima della modifica. Apri una sessione nuova attraverso ogni voce prevista.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

Poi ripeti la riconnessione VPN e riprova, perché una rotta che sopravvive a una riconnessione non è la stessa di una aggiunta a una tabella che la riconnessione svuota. Osserva le origini negate separatamente da quelle consentite, così un tentativo bloccato non si nasconde dietro una sessione funzionante. Salva l'indirizzo locale, la regola e la tabella accanto al risultato. Se invece separi le porte, registralo come decisione operativa e non come limite di SSH.