Traffico unidirezionale dopo la disattivazione dello SNAT di sottorete Tailscale

Disattiva il NAT sorgente su un router di sottorete Tailscale e il tunnel continua a funzionare mentre le connessioni che lo attraversano si fermano. Le richieste arrivano a destinazione con l'indirizzo overlay proprio del client remoto, che è esattamente lo scopo della modifica, e le risposte ora hanno bisogno di un percorso che la LAN non ha mai dovuto conoscere. Senza quel percorso i pacchetti arrivano, le risposte escono dal gateway ordinario e il guasto si presenta come un problema di firewall che nessuna regola di firewall spiega. Il tunnel è sano; manca la tratta di ritorno.

Cosa nascondeva lo SNAT

Con lo SNAT attivo, il router riscrive l'indirizzo sorgente con il proprio indirizzo LAN prima di inoltrare nella sottorete, così la destinazione risponde a un host che sa già come raggiungere e non serve configurare altro. Disattivarlo conserva la sorgente originale, e la destinazione vede allora un indirizzo nell'intervallo overlay invece di un vicino sul proprio cavo. Quell'indirizzo è reale e instradabile attraverso la tailnet, ed è irraggiungibile dalla LAN tramite il gateway predefinito. L'interruttore documentato è --snat-subnet-routes=false, applicato al router di sottorete Linux stesso.

È un'impostazione permanente e non un interruttore per pacchetto, quindi il percorso di ritorno deve esistere per ogni rete di destinazione servita da quel router. È questo che rende la modifica una decisione di distribuzione invece di una casella di controllo. Tutto ciò che quel router serve eredita il requisito nello stesso momento.

Dove può risiedere il percorso di ritorno

Tre posizionamenti sono comuni, e differiscono per portata, non per correttezza. Una rotta statica sull'host di destinazione è la più diretta e la meno scalabile, poiché ogni dispositivo ha bisogno della propria copia. Una tabella di routing nella VPC o nel router del sito copre un'intera rete in una volta, e un'opzione DHCP che trasporta rotte statiche senza classe raggiunge automaticamente i client ma fallisce silenziosamente sui dispositivi che la ignorano.

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

Qualunque posizionamento scegliate, il salto successivo è l'indirizzo LAN del router e mai il suo indirizzo tailnet. Un host della LAN non può raggiungere l'overlay finché non possiede questa rotta, quindi un salto successivo dentro l'overlay è circolare e non manda il pacchetto da nessuna parte. Questo singolo errore spiega la maggior parte delle configurazioni che sembrano corrette e falliscono comunque, e sopravvive a ogni controllo che legge solo la tabella del router stesso. Annotate quale posizionamento avete usato, altrimenti la persona successiva testerà quello sbagliato.

Leggere il guasto come traffico unidirezionale

Il sintomo è più facile da riconoscere della causa: il servizio risponde sul router stesso e resta silenzioso da un client remoto. Una cattura sulla destinazione mostra richieste in arrivo e risposte in uscita, cosa che sembra un successo finché non si nota dove sono dirette quelle risposte. Vanno verso il gateway predefinito, il che significa che la tratta in ingresso ha funzionato e quella di ritorno no.

Catturate invece sul router, perché vede entrambe le direzioni di uno scambio e mostra se una risposta è mai arrivata. Se la risposta appare sulla destinazione ma mai sul router, la rotta manca o è sbagliata sul lato destinazione. Se appare sul router e si ferma lì, il problema è più avanti e appartiene a un'altra indagine.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

L'indirizzo reale vale una rotta

Mantenere lo SNAT resta la risposta più semplice ogni volta che la rete di destinazione non può essere riconfigurata, e il costo è che ogni client sembra il router nei log e nella politica della destinazione. Disattivarlo è giustificato quando un'applicazione ha bisogno dell'indirizzo sorgente reale o quando la politica di rete deve distinguere client che condividono un router. Entrambe sono ragioni legittime e nessuna è gratuita. Il beneficio deve valere la manutenzione di una rotta su ogni rete di destinazione, più la revisione del firewall descritta sotto.

Per una piccola LAN lo scambio di solito conviene, mentre per una moltitudine di apparati che non possono accettare una rotta statica di solito non conviene. Annotate la decisione e il motivo accanto alla configurazione del router, così il prossimo amministratore sa quale comportamento è deliberato. Un valore predefinito che nessuno ha scritto è indistinguibile da una svista.

Firewall, registrazione e il doppio ruolo

Ogni regola che corrispondeva all'indirizzo LAN del router ora corrisponde a una sorgente diversa, comprese le regole di autorizzazione e qualsiasi campo di log che registrava il router come client. Leggete quelle regole prima della prima prova e non dopo il primo fallimento, perché una regola che consente solo l'indirizzo del router blocca del tutto la nuova sorgente. Restringete la sostituzione ai client e alle porte che ne hanno bisogno, poi confermate che non ammetta silenziosamente tutta la tailnet.

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

Un nodo che funge sia da nodo di uscita sia da router di sottorete è una combinazione documentata che può perdere traffico in uscita una volta disattivato lo SNAT di sottorete. Separare questi ruoli su nodi diversi elimina l'avvertenza e dà a ogni rotta e politica di firewall un solo proprietario. Se i ruoli devono restare insieme, aspettatevi questo comportamento e provatelo prima di incolpare un client. Tenete la rotta, l'impostazione dell'interruttore e l'assegnazione dei ruoli in un'unica nota, perché vengono lette insieme quando fallisce la connessione successiva.