Una tabella VPN vuota non blocca nulla da sola

Una regola di policy invia i pacchetti marcati a una tabella dedicata, e l’aspettativa abituale è che la perdita della rotta VPN li blocchi. Il meccanismo fa altro. Quando una tabella non contiene alcuna rotta corrispondente, la ricerca prosegue verso la regola successiva invece di fermarsi, e la tabella main conserva ancora una rotta predefinita ordinaria per l’uplink. Il risultato è una configurazione che sembra fail-closed e si comporta come fail-open.

Niente è rotto; è così che il routing basato su policy è specificato.

La ricerca prosegue quando una tabella non ha nulla

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

Prendete quell’insieme di regole: una ricerca marcata va alla tabella 42, e una regola successiva invia la stessa marca a una tabella chiamata default. Finché la tabella 42 contiene una rotta predefinita utilizzabile, la prima ricerca fornisce il percorso. Quando quella rotta scompare e nient’altro nella tabella 42 corrisponde, la ricerca non diventa uno scarto; l’elaborazione passa alla regola successiva, e quando anch’essa non trova nulla, raggiunge la tabella main. Nulla in quella sequenza riporta quale regola ha prodotto la risposta finale, quindi una connessione funzionante sembra una policy funzionante.

La tabella 253, chiamata convenzionalmente default, è una tabella di routing ordinaria ed è normalmente vuota. Il suo nome non è un’istruzione a scartare pacchetti, e non è la stessa cosa di una rotta di destinazione predefinita dentro una tabella.

Le azioni terminali terminano la ricerca

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

Una regola terminale può seguire la ricerca VPN al posto di una ricerca in una tabella vuota. Con la stessa marca, un’azione prohibit posta dopo la regola della tabella 42 termina la ricerca quando quella tabella non dà nulla, restituendo un rifiuto amministrativo invece di offrire alla tabella main un’altra possibilità. Unreachable e blackhole sono anch’esse terminali, con un comportamento d’errore diverso per il mittente.

Una rotta di tipo throw è diversa: all’interno di quella tabella si comporta come se nulla avesse corrisposto, quindi le regole successive hanno comunque il loro turno. Questo rende throw utile per un ripiego deliberato e sbagliato come blocco finale.

Verificate con la marca e l’interfaccia reali

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

Ispezionate le regole e la tabella reali invece di un diagramma, poi interrogate il flusso con il contesto di origine, marca e ingresso che ha davvero. Una ricerca di sola lettura rivolta a una destinazione, a cui vengono indicati indirizzo di origine, interfaccia e marca, riporta la rotta che il kernel sceglierebbe senza che un pacchetto esca. Fornire una marca nella query non dimostra che il firewall marchi il traffico reale; è un controllo separato delle regole di marcatura. Confermate il valore con un contatore o un log prima di trarre conclusioni dalla query.

Le richieste generate localmente hanno bisogno del proprio contesto, perché il loro percorso di marcatura spesso differisce da quello del traffico inoltrato. Verificatele con l’interfaccia di uscita che l’applicazione userebbe davvero.

Due stati di guasto, non uno

Uno stato di guasto è la scomparsa della rotta VPN e il traffico che ricade sull’uplink. Un tunnel morto la cui rotta resta installata è un altro: i pacchetti restano diretti verso un percorso inutilizzabile invece di ricadere, e il sintomo è una perdita silenziosa anziché una connessione diretta visibile. Testate entrambi, e anche il comportamento all’avvio, alla riconnessione e all’arresto del servizio.

Una regola del genere aiuta solo finché esiste e finché i pacchetti portano ancora la marca che la seleziona. Uno script di spegnimento che elimina la regola, o un percorso che rimuove la marca, ripristina il comportamento aperto. Vale la pena provare quelle transizioni.

Applicate la policy a IPv6 separatamente e mantenete esplicite, anziché implicite, le eccezioni di endpoint approvate.