Un peer VPN fa ping su altre interfacce perché sono locali

Un client WireGuard si connette e fa ping a un indirizzo su un’interfaccia completamente diversa, e la risposta arriva. Le catture mostrano la richiesta solo sul tunnel. Nulla è rotto, e l’impostazione di inoltro disattivata con cura non c’entra nulla. Questo è un confronto tra due percorsi che sembrano uguali in un diagramma e sono completamente diversi nel kernel.

Un percorso inoltra pacchetti per qualcun altro; l’altro li consegna all’host stesso.

Un pacchetto indirizzato all’host resta nell’host

Il client remoto invia un pacchetto IP a un indirizzo posseduto dall’host. Il routing pone una domanda su quel pacchetto: questa destinazione è locale? Ogni indirizzo che l’host detiene compare nella tabella di routing locale, e quella tabella viene consultata prima della principale, quindi il pacchetto va nello stack dell’host stesso invece di uscire da un’altra interfaccia. La risposta viene generata localmente, e torna attraverso il tunnel perché è da lì che veniva la richiesta.

Questo è l’intero meccanismo. Non avviene alcun inoltro, non è coinvolto alcun cambiamento di stato dell’interfaccia, e l’indirizzo in questione non deve essere raggiungibile da nessun’altra parte.

Perché ip_forward non si applica

L’inoltro governa i pacchetti che devono uscire da un’interfaccia diversa da quella su cui sono arrivati. Un ping all’host stesso non prende mai quel percorso: il pacchetto viene consumato localmente e la risposta viene generata localmente. Impostare net.ipv4.ip_forward=0 quindi non cambia nulla qui, e una regola nella catena di inoltro non vede mai quel traffico. Il controllo corretto si trova sul percorso di ingresso, limitato dall’interfaccia in entrata o dalla sorgente.

Per questo disattivare l’inoltro e presumere che l’host sia isolato produce un falso senso di sicurezza.

Leggi la tabella locale che ha deciso

ip rule show di solito segnala una regola con priorità zero che invia tutte le ricerche prima alla tabella locale, e ip route show table local elenca gli indirizzi propri dell’host con ambito locale. Quella tabella include indirizzi su interfacce amministrativamente disattivate ma ancora configurate. Gli indirizzi IPv4 assegnati staticamente di solito sopravvivono a una caduta del collegamento, ed è così che un ping a un bridge abbassato può ancora riuscire e sorprendere l’operatore.

IPv6 è in disaccordo proprio su questo punto. I suoi indirizzi vengono di solito ritirati quando il collegamento cade, a meno che keep_addr_on_down non sia impostato. Confronta le famiglie invece di presumere che una regola copra entrambe.

A cosa arriva davvero un peer

Una risposta dall’indirizzo proprio del router su un segmento non dice nulla sulle macchine dietro quel segmento. Il peer non può raggiungere un host dietro l’altra interfaccia tramite questo percorso; raggiunge solo gli indirizzi posseduti dal router stesso. Testare un servizio su un host LAN separato, invece di fare ping all’indirizzo del router, è ciò che stabilisce se l’inoltro è consentito del tutto.

Limitare un peer ai servizi legati all’indirizzo del tunnel è una questione di politica di ingresso. Consenti il servizio desiderato sull’interfaccia del tunnel e limita le sorgenti che possono usarlo, perché il pacchetto arriva davvero lì.

Controlla anche gli indirizzi che intendevi ritirare. Rimuovere un indirizzo da un’interfaccia è più affidabile che impilare regole del firewall su uno obsoleto.