Cloud VPN verso una VM GCP: usate l’IP interno, non l’IP NAT

Quando una rete locale raggiunge una VPC tramite Cloud VPN, la destinazione per un servizio Compute Engine è normalmente l’indirizzo interno della VM. L’indirizzo IPv4 esterno non è un secondo indirizzo che potete sostituire nella stessa rotta privata. La maggior parte della confusione in questo ambito nasce dal trattare tre indirizzi con tre compiti come se fossero intercambiabili, quindi iniziate a nominare quale usa un determinato pacchetto.

Tre indirizzi, tre compiti

Nominate tutti e tre prima di eseguire il debug di uno qualsiasi, perché la risposta cambia l’oggetto che ispezionerete dopo.

Il primo appartiene al tunnel. Il secondo appartiene al progetto della rotta e del firewall. Il terzo appartiene all’accesso in ingresso da Internet ed è mappato, non collegato. Un progetto che funziona per uno di essi non dice nulla sugli altri due.

Perché l’indirizzo esterno non è una seconda interfaccia

La guida agli indirizzi è l’autorità su come differiscono raggiungibilità interna ed esterna su Compute Engine. Un IPv4 esterno di Compute Engine è una mappatura uno-a-uno sull’unica NIC interna dell’istanza, quindi il guest non vede mai una seconda interfaccia né un secondo indirizzo su quella NIC. Ciò che la VM riporta all’interno resta un unico indirizzo interno primario.

Per questo un client privato che instrada attraverso il tunnel verso 10.24.1.7 e un client che punta all’indirizzo esterno della VM seguono percorsi diversi. Aprire una regola del firewall per l’indirizzo pubblico non cambia nulla nella rotta della VPC che deve trasportare il traffico del tunnel, e modificare una rotta sul guest non sposta la mappatura della piattaforma. Scegliete l’indirizzo che la vostra rotta nomina, poi ispezionate solo gli oggetti che lo governano. Questa disciplina elimina la maggior parte delle congetture da questo percorso di risoluzione dei problemi.

Percorrete il percorso con gcloud

Partite dall’istanza e leggete entrambi gli indirizzi dallo stesso oggetto, così sapete di quale parla la vostra documentazione:

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

Poi confermate l’instradamento e l’autorizzazione da cui il percorso dipende davvero:

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

Leggete gli intervalli annunciati e appresi del tunnel, la rotta della VPC per la sottorete del carico di lavoro e la regola del firewall che consente l’origine locale. Questi tre devono concordare prima che un listener sul guest sia anche solo rilevante.

Poi controllate il guest: il servizio è in ascolto sull’indirizzo interno e il suo percorso di ritorno ripassa dalla VPC? Un listener associato solo a un indirizzo pubblico fallirà questo test anche quando ogni oggetto lato cloud è corretto.

Un prefisso pubblico è un’altra questione

Niente di quanto sopra significa che ogni indirizzo trasportato dentro una VPN debba essere RFC1918. Una rete remota può essere numerata legittimamente dallo spazio pubblico, purché la piattaforma supporti l’instradamento e l’operatore detenga l’autorità sull’indirizzo. È una scelta di progetto normale.

Non è lo stesso che trattare un ordinario indirizzo NAT esterno come se fosse un altro indirizzo di sottorete interna. Uno è un prefisso che instradate; l’altro è una mappatura che la piattaforma applica all’accesso in ingresso.

L’IPv6 esterno e le disposizioni di indirizzi progettate appositamente hanno una semantica propria. Se il vostro piano dipende da uno di questi, leggete la documentazione della piattaforma per quella funzione invece di generalizzare dal caso IPv4. La mappatura IPv4 è il caso comune, non l’unico, e le eccezioni hanno ciascuna le proprie regole.

Gli intervalli sovrapposti sono un altro problema

Gli intervalli privati sovrapposti sono un motivo reale per cui le persone ricorrono all’indirizzo pubblico, ed è la leva sbagliata. Cambiare la destinazione nell’indirizzo NAT della VM non risolve la sovrapposizione; cambia l’indirizzo a cui il pacchetto dichiara di essere diretto, senza definire come funziona il percorso di ritorno.

Risolvete la sovrapposizione deliberatamente: rinumerate, usate un progetto di traduzione supportato o instradate attraverso una rete in cui i prefissi non collidono. Ognuna di queste è un progetto con un responsabile. L’indirizzo NAT non è un progetto.

Documentate i due campi separatamente

Registrate il peer del tunnel e la destinazione del carico di lavoro come due campi runbook distinti, ciascuno con la rotta e la regola del firewall che lo sostengono. Un tunnel IPsec che sale vi dice solo che le parti sono d’accordo; non dice nulla su quale indirizzo sia raggiungibile il carico di lavoro, né se la sua rotta privata sia completa.

Verificate con un client reale dall’altra parte: risolvete il nome, confermate che restituisca l’indirizzo interno, connettetevi e controllate il traffico di ritorno. La documentazione sugli indirizzi IP di Compute Engine è il riferimento per la distinzione interno-esterno usata sopra.