NAT sul server VPN o sul router? Entrambe le soluzioni possono funzionare

Contrassegnare una connessione come route predefinita su un portatile è il passaggio che tutti ricordano, ed è proprio quello che non cambia nulla sul gateway. Il client ora invia le richieste Internet nel tunnel; se escono dall’edificio dipende dall’inoltro, da un punto di traduzione e da un percorso di ritorno che raggiunga l’indirizzo privato del client. Due disposizioni possono fornire tutte e tre le cose, collocano il lavoro in punti diversi, ed entrambe falliscono nello stesso modo silenzioso quando nessuno possiede la direzione della risposta. Scegliere tra le due è una questione di chi deve vedere il pool di client.

Il mito: una route del client costruisce l’uscita

Il tunneling forzato è una politica lato client: decide che il traffico vada all’adattatore VPN invece che a quello fisico. La documentazione Microsoft sull’instradamento VPN descrive quella separazione e quel comportamento forzato, ed è un’affermazione sulla tabella di routing del client, non sulle regole di inoltro del server. Dal punto di vista del client il tunnel è dove vive Internet; dal punto di vista del gateway è arrivato un pacchetto da un indirizzo che nessuno a monte ha mai sentito. Nessuno dei due lati è configurato male da solo, ed è per questo che il guasto appare come un server rotto alla persona davanti al portatile.

Questa discrepanza è l’intero problema che il resto dell’articolo risolve. Qualcosa deve rendere restituibile l’indirizzo privato del client, e la scelta è dove.

Disegnate prima il percorso di ritorno

Scrivete il percorso con indirizzi reali prima di toccare qualsiasi impostazione, e segnatevi sopra i due punti di traduzione candidati. Questo laboratorio usa un pool VPN di 10.70.0.0/24 con un client su 10.70.0.37, un indirizzo LAN del server di 172.16.40.10, un router su 172.16.40.1 e un’uscita pubblica di 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

Il server che già naviga su Internet dimostra solo il proprio percorso. Un pacchetto inoltrato per conto di un client è una decisione diversa, presa dalla politica di inoltro sulla stessa macchina, ed è quella che di solito manca. Segnare i tre punti di decisione sul diagramma mantiene la conversazione su uno di essi alla volta.

Opzione A: tradurre sul server VPN

Qui il server traduce la sorgente del client nel proprio indirizzo LAN prima di consegnare il pacchetto al router, e il router applica la sua traduzione ordinaria in uscita. Sulla risposta, la mappatura del router ripristina l’indirizzo del server e quella del server ripristina l’indirizzo del client. Due traduzioni con stato in serie sono normali e praticabili, purché entrambe siano registrate; il router non ha mai bisogno di una route verso il pool, ed è questo il fascino di questa disposizione.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Usate queste letture per vedere cosa ha già il server invece di dare per scontato che ci sia un NAT. Una regola masquerade di Linux copiata da un blog non è una configurazione Windows, e un’autorizzazione nel firewall dell’host per l’ascoltatore VPN non è la stessa politica del permesso di inoltrare la richiesta di un client oltre. Confermate il ruolo di inoltro del server dalla sua superficie di gestione, poi guardate la traduzione separatamente, perché le due cose sono spesso abilitate da parti diverse di una distribuzione.

Opzione B: portare il pool al router

Nella seconda disposizione il server inoltra il vero indirizzo di origine del client, e il router lo traduce. Questo mantiene il pool di client visibile al bordo, il che aiuta se il router è il luogo dove vivono la politica di traffico, la registrazione o l’ispezione. Significa anche che il router ha bisogno di una route di ritorno per 10.70.0.0/24 che punti a 172.16.40.10, oltre a una politica Internet che includa davvero quel prefisso; una regola scritta per la sottorete LAN non si estende silenziosamente al pool.

Scegliete questa quando il dispositivo di bordo è il proprietario previsto della politica e può accettare un altro prefisso nelle sue tabelle di routing e traduzione. Scegliete la traduzione lato server quando il pool deve restare invisibile a monte e il router non è amministrato dallo stesso team. Nessuna delle due opzioni è implicata da una casella di controllo sul client, e nessuna è più sicura in generale; collocano visibilità e manutenzione in punti diversi.

Rendete espliciti DNS, IPv6 e accettazione

La traduzione degli indirizzi non risolve la risoluzione dei nomi. Il client può usare un resolver fornito con il profilo VPN, un resolver privato per spazi di nomi specifici, o uno pubblico approvato, e un resolver irraggiungibile con quella politica continuerà a fallire dopo che l’instradamento funziona. Provate un nome e un indirizzo separatamente, così i due guasti non si fondono mai in un unico rapporto.

L’IPv6 ha bisogno del proprio paragrafo nella progettazione. Una traduzione IPv4 funzionante non dice nulla sul fatto che i client IPv6 abbiano una route, una sorgente pubblica valida o una politica che li blocchi quando il tunnel cade. Lasciarlo non detto significa che metà dei client aggira il gateway in silenzio mentre l’altra metà funziona.

Per l’accettazione, seguite una richiesta client consentita e la sua risposta attraverso entrambi i confini, e annotate quale indirizzo ciascun confine dovrebbe vedere in quel momento. È quella registrazione che rende il prossimo cambio di pool una modifica di cinque minuti invece di una discussione su chi possiede la route di ritorno mancante. Conservate la registrazione con il profilo del client invece che in un ticket, perché il profilo è ciò che il prossimo ingegnere troverà per primo.