VPN Pi multi-router: metti ogni rotta sul dispositivo che decide
Un router a valle aggiunge una seconda sottorete client, e ciascuno dei quattro dispositivi possiede una decisione. Metti le rotte, controlla la sorgente, poi verifica da un client reale.
Mettere un box Wi-Fi dietro il Pi trasforma una decisione di routing in quattro, e il piano si rompe quando tutte e quattro vengono prese su un solo dispositivo. La prima domanda non è quale rotta aggiungere. È se il nuovo box fa bridge o routing, perché quella risposta decide quante sottoreti esistono e quali dispositivi devono apprenderle. Scegli prima il modello di collegamento; ogni rotta ne deriva.
Bridge o routing: la scelta che fissa il numero
Un bridge mette i nuovi client sulla stessa sottorete che il Pi già serve. Una sottorete, un'autorità DHCP e nessun passaggio da instradare. Questa è la disposizione più semplice e quella giusta quando una rete client separata non è mai stata un requisito. Un collegamento instradato è un progetto diverso: il box mantiene la propria sottorete, e quel prefisso va portato ovunque vada il traffico.
Il resto del piano mantiene il router a valle e preserva gli indirizzi sorgente dei client. L'obiettivo è una rete VPN privata, non un'uscita internet completa. Scrivi il modello prima degli indirizzi, perché l'elenco sotto è solo un esempio di collegamento instradato.
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24Chi decide cosa
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
Ogni dispositivo prende una decisione, e nessuno può prendere quella di un altro al suo posto. Il Pi ha bisogno di due voci, non una, e il percorso di ritorno è quello che la gente dimentica. Il traffico inoltrato raggiunge correttamente la rete privata e poi muore al ritorno, perché il Pi non ha idea di dove viva 10.41.0.0/24. Sembra un problema di firewall ed è in realtà una rotta mancante.
Anche il lato remoto ha bisogno della propria rotta. Se il servizio all'estremità remota non sa che 10.41.0.0/24 è raggiungibile attraverso il tuo tunnel, le risposte si fermano al primo salto che non ha risposta. Aggiungi entrambe le direzioni prima di leggere i filtri dei pacchetti.
I prossimi salti vengono dal collegamento
Il prossimo salto deve essere un indirizzo su una rete che il dispositivo possa davvero raggiungere. L'indirizzo pubblico del peer VPN non è il prossimo salto per una sottorete privata, e la rete di servizio remota non è affatto un prossimo salto. Una rotta verso un gateway irraggiungibile sembra corretta in un elenco e scarta ogni pacchetto. Controlla che il gateway risponda prima di dare la colpa alla destinazione.
Mantieni il peer VPN esterno del Pi raggiungibile tramite la sua rotta di sottolivello. Quella voce è separata dalle rotte del carico utile, e mescolarle dà un tunnel che non può ristabilirsi dopo un cambio di percorso.
La documentazione delle rotte statiche chiarisce la distinzione tra destinazione e gateway, anche se ogni piattaforma nomina i propri menu in modo diverso. Leggi la documentazione del dispositivo che hai davanti invece di copiare lo schermo di un altro fornitore. I comandi sotto mostrano la forma delle voci su Linux.
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1Cosa fa la traduzione alla sorgente
Se il router a valle traduce già i suoi client all'indirizzo di transito, il Pi vede un'unica sorgente tradotta invece dell'indirizzo proprio di ogni client. È un progetto diverso da quello che preserva la sorgente qui sopra. Cambia la politica basata sulla sorgente, la registrazione e quale lato può iniziare le connessioni. Entrambi i progetti funzionano; rispondono a domande diverse.
Quando un servizio VPN a monte rifiuta di instradare il prefisso client al ritorno, una traduzione ristretta all'uscita del tunnel del Pi può essere una soluzione legittima. Non è prova che la rotta mancante fosse superflua. Annota quale indirizzo vede davvero la rete remota e quale percorso di ritorno ne risulta.
Selezione della rotta, permesso di inoltro e traduzione della sorgente restano tre lavori separati. Svuotare una catena NAT condivisa o consentire ogni interfaccia perché un client via cavo funziona è il modo in cui un test funzionante diventa un forwarder aperto.
Dimostrarlo da una macchina client
Invia una richiesta da una macchina sulla LAN a valle, poi segui la sua sorgente all'andata e al ritorno. Un ping emesso dal Pi non esercita mai la rotta di ritorno a valle, per questo un ping riuscito dimostra meno di quanto sembri. Aggiungi un secondo test da un client via cavo sulla LAN propria del Pi così i due percorsi possono essere confrontati. Ripeti entrambi dopo aver riavviato uno dei dispositivi.
Le rotte aggiunte a mano e le traduzioni mai salvate spariscono insieme. Allora la coppia sembra un guasto nuovo invece di un lavoro incompiuto.
Salva il modello di collegamento insieme alle rotte, al servizio privato consentito e a qualsiasi traduzione in un'unica nota. È quella nota che impedisce alla persona successiva di trattare la posizione wireless come una questione di politica di routing.