Client a valle dietro una VPN a monte: rotta o NAT?

Un gateway esegue WireGuard per i tuoi dispositivi e un client OpenVPN verso la rete di qualcun altro. L'inoltro tra le due interfacce interne funziona, ed è facile concludere che la sottorete a valle faccia ormai parte del servizio a monte. Non è così. Una rotta ottenuta dal client dice al tuo gateway dove inviare le richieste; non dice nulla su come la rete remota restituisca il traffico a dispositivi di cui non ha mai sentito parlare. Scegli un modello di ritorno che il monte supporti davvero prima di aggiungere una sola regola.

Decidi il modello di ritorno prima di toccare l'instradamento

In questa guida i client a valle usano 10.90.0.0/24, l'indirizzo del tunnel a monte assegnato al gateway è 10.80.0.6 e la risorsa remota approvata è 172.20.0.30. Due modelli si adattano a questa forma: conservare l'origine a valle e far sì che il lato remoto la instradi, oppure tradurre l'origine nell'indirizzo del tunnel del gateway stesso. Tutto ciò che segue questa decisione è meccanico, e la decisione stessa richiede il proprietario del servizio. Una delle righe qui sopra è un accordo di instradamento con il lato remoto; l'altra è un cambiamento di politica locale che puoi fare da solo. Confondere le due è ciò che trasforma una modifica di dieci minuti in una trattativa.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Scegli una riga e attieniti a essa. Le righe sono alternative, non passi, e mescolarle produce un progetto che nessuno sa spiegare in revisione.

Conservazione dell'origine con instradamento

Il lato remoto riceve una richiesta da un indirizzo a valle, quindi ha bisogno di una rotta supportata e della proprietà del peer per quella sottorete, oltre all'autorizzazione ad accettarla. Sono impostazioni remote, e nessuna rotta Linux locale le crea. Chiedile in modo esplicito e per iscritto, con il prefisso e il peer del tunnel che la trasporterà, e aspettati che la risposta dipenda dal fatto che il servizio supporti o meno accordi site-to-site.

Se la risposta è sì, la configurazione locale è minima: inoltro abilitato, gli allowed-ips del peer WireGuard che coprono l'intervallo a valle e una politica del firewall che consente l'attraversamento in entrambe le direzioni.

Traduzione dell'origine deliberata

Se il servizio restituisce il traffico solo all'indirizzo del client connesso, traduci l'origine in quell'indirizzo in uscita e conserva lo stato conntrack che la inverte per le risposte. Limita la regola alle origini a valle previste, alle destinazioni remote previste e all'interfaccia a monte. Una regola che traduce tutto ciò che esce da ogni interfaccia è una politica molto più ampia di questo requisito, e ti sorprenderà più avanti.

IPv6 richiede un progetto proprio; copiare una riga masquerade IPv4 non è un'architettura. Prova il percorso tradotto con una connessione nuova anziché una in cache.

Il percorso dati locale deve comunque funzionare

La traduzione non elimina il lavoro locale: il gateway ha ancora bisogno di una rotta verso le destinazioni a valle, della corretta proprietà dell'origine del peer WireGuard, dell'inoltro abilitato e di una politica del firewall ristretta tra le interfacce. Una richiesta generata sul gateway stesso non esercita nessuno di quei permessi, ed è per questo che i test locali sul gateway passano mentre i dispositivi a valle falliscono ancora.

Prova da un dispositivo a valle reale, non dal gateway. L'indirizzo di origine è tutto il senso dell'esercizio.

Un'origine significa un'identità di sessione

Il servizio remoto vede la sessione autenticata del gateway e il suo indirizzo tradotto, non un'autenticazione indipendente per ogni dispositivo a valle. Mantieni espliciti i permessi per dispositivo e le identità delle applicazioni, e conferma con il proprietario del servizio che un gateway che agisce per più dispositivi sia davvero consentito. La traduzione non è un modo per aggirare un requisito di registrazione per dispositivo; se il servizio richiede che ogni dispositivo si registri, usa quel modello o negozia un accordo site-to-site.

Scrivi quella conferma nel runbook accanto alla regola, perché il prossimo revisore chiederà se il progetto è stato approvato o era solo comodo.

Definisci lo stato disconnesso, poi prova tre richieste

Decidi cosa succede quando il tunnel a monte cade. Il traffico remoto autorizzato non dovrebbe seguire silenziosamente un ripiego WAN ordinario dove ciò è vietato, quindi la politica del firewall che consente l'attraversamento deve fallire chiusa. Poi prova tre casi da un dispositivo a valle reale: una richiesta consentita che funziona, una richiesta non consentita che fallisce e un guasto a monte che ferma quella consentita.

Registra il rollback su una riga per regola, così la modifica può essere annullata senza ricostruire l'intento.