La regola di instradamento legge il mark del pacchetto, non conntrack

Quattro controlli separano una regola di mark funzionante da una rotta funzionante: quale mark legge la regola, se il pacchetto lo porta ancora al momento della ricerca, se un mark di connessione è stato ripristinato sui pacchetti successivi e se se la maschera e la priorità della regola corrispondente le consentono di scattare. Un contatore che cresce dimostra solo che qualche regola ha corrisposto a qualcosa. Non dice nulla su ciò che il pacchetto portava quando il kernel ha scelto il suo percorso.

I due mark vivono in posti diversi e scadono secondo calendari diversi.

Due mark, due vite

Un mark di pacchetto appartiene a un solo skb, viaggia con esso attraverso gli hook ed è consumato dal selettore fwmark dell'instradamento basato su politica. Un mark di connessione appartiene alla voce conntrack, persiste attraverso i pacchetti di quel flusso ed è invisibile alla regola di instradamento finché qualcosa non lo ricopia. Salvare un mark di pacchetto nella connessione è una memorizzazione; ripristinarlo è un'azione separata. Nessuna delle due avviene implicitamente.

Per questo un insieme di regole può sembrare coerente mentre la decisione di instradamento vede zero: il valore è stato salvato e nulla lo ha ripristinato.

Copiare tra i due è un passo che scrivete voi

Le due istruzioni che contano vanno in direzioni opposte: una salva il mark del pacchetto nella connessione, l'altra carica il mark della connessione sul pacchetto. Quale vi serve dipende da quando avviene la classificazione rispetto al flusso. Un progetto può richiedere solo il mark del pacchetto, e aggiungere la marcatura conntrack perché qualche soluzione alternativa usava entrambi è il modo in cui una politica semplice acquisisce un secondo modo di guasto.

ct mark set meta mark
meta mark set ct mark

Scrivete la direzione accanto alla regola, perché non è ovvia dalla sintassi a prima vista. La prima riga salva, la seconda ripristina, e nessuna implica l'altra.

Classificate prima della ricerca che lo consuma

Il traffico generato localmente e il traffico inoltrato da una LAN attraversano hook diversi e raggiungono le decisioni di instradamento in momenti diversi. Una regola di output che funziona per le connessioni del router stesso non dimostra che il pacchetto di un client inoltrato sia stato marcato prima della sua ricerca. Mettete la classificazione dove la ricerca che la consuma non è ancora avvenuta, e controllate se le regole successive nella stessa catena sovrascrivono il valore. L'ordine dentro una catena è parte della configurazione, non un dettaglio implementativo.

Anche la persistenza dello stato di connessione richiede un piano esplicito. Se si classifica solo il primo pacchetto di un flusso, i pacchetti successivi hanno bisogno del ripristino del mark salvato, altrimenti prenderanno il percorso non marcato. È questa la differenza tra un mark che descrive una connessione e uno che descrive un pacchetto.

Ponete alla rotta una domanda con mark

ip route get 10.77.0.10 mark 0x2

Esaminate le regole e la tabella, poi interrogate la rotta con il mark incluso, oltre alla sorgente o all'interfaccia in ingresso quando influenzano la politica. Una ricerca normale senza mark risponde a un'altra domanda e vi segnalerà volentieri il percorso che non volevate. Controllate la maschera e la priorità della regola oltre al suo valore, e confermate che la tabella scelta contenga una rotta utilizzabile.

Un contatore che cresce è prova che qualche regola ha corrisposto a qualche pacchetto. Non è prova che il pacchetto finale portasse il mark previsto nel punto di decisione giusto.

Leggete il mark, la direzione, il momento e la maschera. Quattro controlli, e la rotta smette di essere un mistero.