Gateway VPN su Raspberry Pi: una sola NIC o una porta client dedicata

Avete un Pi, un profilo VPN in uscita funzionante e due dispositivi che dovrebbero raggiungere internet attraverso di esso. La domanda che decide l’intera costruzione non è quale guida seguire, ma quanto contenimento vi serve. Una sola porta lascia che il Pi si affianchi a quei dispositivi sulla LAN del router e agisca come gateway aggiuntivo; una seconda porta vi permette di metterli su un segmento dove il Pi è l’unica via d’uscita. Tutto ciò che segue a quella scelta — DHCP, ambito del firewall, DNS, il caso di interruzione — ne deriva.

In che cosa i due schemi differiscono davvero

Entrambi i progetti instradano. La differenza è chi altro sta sul cavo e che cosa succede quando la politica è sbagliata.

Il contenimento è l’asse reale. Lo schema A è indicativo: un dispositivo che ignora il gateway fornito via DHCP e sceglie il router funziona ancora, ma senza cifratura. Lo schema B è imposto dalla topologia, perché non c’è nessun altro salto successivo da scegliere.

Schema A: il Pi come gateway aggiuntivo sulla LAN esistente

Supponete che il router dell’ISP sia 192.168.50.1, il Pi sia 192.168.50.2 e i client scelti puntino al Pi. L’importante è che due flussi di pacchetti diversi condividano un solo cavo. Il pacchetto interno del client arriva al Pi e deve uscire dal tunnel; il pacchetto cifrato del Pi verso il peer VPN deve uscire dallo stesso cavo verso il router. Viaggiano in direzioni opposte sulla stessa interfaccia e richiedono un trattamento diverso.

Date al Pi il suo indirizzo tramite il gestore di rete installato, non con una vecchia ricetta di file di interfaccia che se lo contende per il dispositivo. Poi impostate i client: un gateway statico su un dispositivo, oppure una prenotazione DHCP che distribuisce 192.168.50.2 come router. Non cambiate l’intero ambito DHCP del router per due dispositivi, e non date per scontato che un client rispetti l’opzione — verificatelo.

La debolezza è strutturale, non riparabile. Qualsiasi client su quel segmento può puntare a 192.168.50.1 e uscire in chiaro, e un dispositivo con una seconda interfaccia o una radio cellulare abbandona del tutto il vostro percorso di applicazione. Se quella frase è inaccettabile per il dispositivo in questione, avete già la risposta: usate lo schema B.

Schema B: una porta dedicata chiude i dispositivi dentro

Qui il Pi mantiene 192.168.50.2 sul collegamento ascendente con gateway 192.168.50.1, e prende 10.20.0.1/24 su una seconda interfaccia per i dispositivi collegati. Ora il Pi è un router con due reti, e il segmento collegato ha esattamente una via d’uscita.

Controllate l’intervallo contro tutto il resto prima di impegnarvi: la sottorete del tunnel stesso, altri prefissi tra sedi e qualunque cosa raggiungibile tramite la VPN. Un 10.20.0.0/24 che collide con una LAN remota produce quel risultato a metà funzionante che costa una serata di diagnosi. Se la seconda porta è un adattatore USB, confermate che sia supportato e fissate il suo nome nel gestore di rete, così che una riassegnazione dopo il riavvio non sposti il vostro indirizzo LAN.

Eseguite l’ascoltatore DHCP solo su quell’interfaccia. Un server che risponde sul collegamento ascendente compete con il router dell’ISP e distribuisce gli indirizzi del vostro segmento al resto della casa. Legatelo all’interfaccia LAN, limitatelo all’intervallo dichiarato e tenete l’indirizzo del Pi fuori dal pool.

Inoltro, traduzione e la regola di chiusura in caso di guasto

Quattro cose sono spesso descritte come una e non lo sono. Abilitare l’inoltro (net.ipv4.ip_forward=1) dice solo al kernel che può spostare pacchetti tra interfacce; di per sé non permette nulla e non garantisce alcun percorso. Scegliere l’uscita è una decisione di instradamento. Permettere il pacchetto è una decisione di politica nella catena forward. Riscriverne l’origine è una decisione di postrouting. Una costruzione che fa solo la prima produce un Pi che inoltra allegramente il traffico dei client verso il collegamento ascendente.

Limitate il permesso alle sorgenti che intendevate e all’interfaccia che il traffico deve usare, e includete il percorso di ritorno e le destinazioni che servono al Pi. Poi traducete sull’uscita del tunnel se il fornitore non vi reinstrada il prefisso della LAN. manuale di nftables tratta l’inoltro, l’uscita locale e la traduzione della sorgente come operazioni distinte, che è il modello mentale corretto qui.

Il guasto abituale è una regola masquerade ampia sull’interfaccia fisica. Allora il traffico raggiunge internet per la via dell’ISP mentre, dal lato client, sembra esattamente una VPN che funziona. Non dimostra nulla. Tenete la traduzione legata all’uscita dichiarata e tenete le vostre regole nel firewall che l’host già usa, invece di aggiungere un insieme di regole concorrente che svuota una catena postrouting condivisa.

Poi affrontate l’assenza del tunnel. Un profilo client che installa una route predefinita ampia significa anche che, quando il tunnel cade, la route predefinita ordinaria può tornare e il traffico dei client torna silenziosamente sul collegamento ascendente. Dove il ritorno a testo in chiaro non è accettabile, la politica forward deve negare esplicitamente il traffico dal client al collegamento ascendente, nello stato in cui la route VPN è sparita. Scrivetelo come regola di rifiuto, non come supposizione. Il trasporto cifrato del Pi verso il peer VPN è un flusso local-output separato e deve restare permesso, altrimenti il tunnel non potrà mai tornare.

DNS e IPv6 hanno bisogno della propria risposta

Se i client usano il Pi come resolver, raggiungono un ascoltatore locale e il Pi avvia una nuova interrogazione. Quell’interrogazione verso l’alto segue la route del Pi stesso, non la regola forward che avete scritto per i client, quindi un percorso client solo attraverso il tunnel più un resolver che esce direttamente è una fuga senza alcun messaggio di errore. Decidetelo deliberatamente: un resolver raggiunto attraverso il tunnel, o uno locale che accettate come diretto, e fate corrispondere la politica di uscita del Pi a quella decisione.

IPv6 è di nuovo un caso a parte. Una regola forward per IPv4 non limita nulla riguardo a IPv6, e gli annunci del router sul collegamento ascendente possono dare al Pi, e per suo tramite al segmento collegato, una seconda route predefinita che aggira la vostra politica. O date a IPv6 il suo percorso protetto con lo stesso principio, oppure limitatelo esplicitamente sul segmento dei client e ditelo.

Provate il confine prima di fidarvi

Accettate lo schema solo dopo quattro controlli separati, perché l’unico test tentatore — aprire un browser su un client — passa in diversi stati rotti.

Confermate che un client reale raggiunge internet attraverso il tunnel, poi confermate che lo stesso client non può raggiungere internet con il tunnel abbassato. Confermate che la risoluzione DNS funziona e che l’interrogazione esce dove intendevate. Confermate che il trasporto del Pi funziona ancora dopo un riavvio del tunnel, e che il ripristino non richiede di riavviare la macchina. Infine controllate un dispositivo che non avete scelto: con lo schema A dovrebbe continuare a funzionare normalmente, e con lo schema B non dovrebbe esistere affatto su quel segmento.

• Due porte e una regola di rifiuto danno applicazione; una porta e un’opzione DHCP danno consiglio.
• La traduzione sull’interfaccia sbagliata sembra un successo e non lo è.
• Il traffico del Pi, il DNS e IPv6 hanno ciascuno bisogno di una decisione, non di un’inferenza.