Bloccare IPv6 per proteggere WireGuard rompe l’host

L’obiettivo è ragionevole: solo gli utenti del tunnel dovrebbero raggiungere i servizi di questa macchina. L’implementazione a cui si ricorre è una catena d’ingresso IPv6 che scarta tutto tranne WireGuard, e così scarta anche il traffico che tiene l’host agganciato al proprio collegamento. La scoperta dei vicini e i messaggi di manutenzione del percorso non sono accesso ai servizi, e rimuoverli produce una macchina irraggiungibile per motivi estranei alla tua politica. Il tunnel sale, i servizi sono correttamente delimitati e nient’altro sul collegamento funziona.

Tre responsabilità, un insieme di regole

La prima responsabilità è il funzionamento della rete esterna: l’host deve restare agganciato al proprio collegamento, risolvere i vicini e conoscere i limiti di percorso di quel collegamento. La seconda è l’ascoltatore cifrato, che accetta UDP sull’indirizzo e sulla porta che hai scelto. La terza è l’insieme dei servizi decifrati che vuoi far raggiungere agli utenti del tunnel.

Sono tre politiche diverse, e solo la seconda e la terza riguardano la VPN. Un insieme di regole che le tratta come una sola eredita un modo di guasto in cui stringere il confine applicativo rompe in silenzio l’aggancio dell’host.

Tienile in catene separate o almeno in commenti separati, così la persona successiva vede quale riga esiste e perché.

Che cosa fa ICMPv6 per l’host

IPv6 si affida a ICMPv6 per molto più dell’echo. La richiesta e l’annuncio di vicino sostituiscono ARP e sono necessari per la consegna locale. Packet Too Big trasporta l’informazione di MTU del percorso, e ignorarla produce trasferimenti che si bloccano sui pacchetti grandi. Gli annunci del router trasportano la rotta predefinita e l’informazione di prefisso quando il collegamento usa la configurazione automatica.

RFC 4890 separa i messaggi che un filtro dell’host deve consentire da quelli che sono una scelta amministrativa, e lo fa in una sezione host distinta dalle regole per un router che inoltra tra reti. Leggere solo la sezione sull’inoltro produce una politica d’ingresso troppo rigida per l’host che protegge.

La regola pratica è consentire i messaggi essenziali di errore e configurazione sull’interfaccia che ne ha bisogno, limitati per tipo e origine dove la piattaforma lo consente, e decidere esplicitamente sul resto.

Sostituire tutto questo con un permesso generale di ICMPv6 risolve il problema di disponibilità e rinuncia al filtraggio. Sostituirlo con uno scarto generale risolve il problema di filtraggio e rinuncia all’host.

Ammettere il tunnel, poi il servizio

Accetta il trasporto WireGuard sull’indirizzo esterno previsto e sulla porta UDP, e accetta il traffico di ritorno tramite il tracciamento delle connessioni. Poi consenti ai servizi applicativi di passare attraverso l’interfaccia del tunnel, dalle origini che autorizzi davvero.

Un permesso per la porta UDP esterna non autorizza le richieste decifrate al suo interno. Questa distinzione è l’intera ragione per cui l’interfaccia del tunnel compare nelle regole dei servizi.

Leggi l’insieme di regole com’è, non come lo descrive il file:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

Un ascoltatore su un indirizzo fisico è un’esposizione separata rispetto allo stesso servizio sull’indirizzo del tunnel. Se la macchina inoltra anche traffico verso un’altra, è una decisione della catena di inoltro e non questa politica d’ingresso, e richiede un proprio ragionamento.

Prova il collegamento, non solo il tunnel

Un tunnel che funziona dopo la modifica dimostra meno di quanto sembri, perché una voce di vicino esistente e una connessione stabilita possono nascondere un messaggio di controllo che la politica ora scarta.

Verifica l’aggancio direttamente, poi verifica che il percorso escluso fallisca ancora:

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

Una tabella dei vicini che resta completa dopo un riavvio è il segnale che la scoperta funziona ancora. Una tabella che si svuota e non si riempie mai è il segnale che l’hai filtrata. Il terzo comando convalida la sintassi dell’insieme di regole senza applicarlo, cosa che vale la pena fare finché hai ancora una sessione.

Recupera un host da cui ti sei chiuso fuori

Prima di modificare regole del firewall che trasportano la tua stessa sessione amministrativa, tieni un secondo canale: una console, una connessione seriale o un ritorno programmato che rimuove le nuove regole se non lo annulli.

Se una modifica ti chiude fuori, il recupero passa per quel canale e non per la rete che hai appena rimosso. Ripristina l’insieme di regole precedente da una copia salvata, conferma che l’host è di nuovo raggiungibile e solo allora riapplica la politica prevista in pezzi più piccoli.

La politica finale non è universale. Indirizzamento, routing e implementazione del firewall sono input di distribuzione, ma il confine è lo stesso ovunque: nega l’accesso applicativo indesiderato conservando il traffico di controllo che trasporta il tunnel autorizzato.