Abilitare l'inoltro IP su un gateway GCE VPN esistente

La VM è stata creata senza inoltro IP, esegue già il software VPN, e l'istinto è ricostruirla dal modello con il flag attivo. Quella ricostruzione è superflua. Compute Engine espone canIpForward come proprietà aggiornabile, e il percorso di aggiornamento documentato la applica con un refresh anziché un riavvio. Ciò che il flag controlla davvero è ristretto: senza di esso, la piattaforma scarta i pacchetti che arrivano all'istanza ma non sono indirizzati all'indirizzo proprio dell'istanza. Un gateway che inoltra il traffico di altre macchine fa esattamente questo, quindi il flag deve essere attivo. Tutto il resto è configurazione del guest e routing, che il flag non tocca.

Cosa consente il flag, e cosa no

Con l'inoltro disattivato, la piattaforma tratta l'istanza come un endpoint. I pacchetti la cui destinazione è l'indirizzo proprio dell'istanza vengono consegnati; i pacchetti che l'istanza dovrebbe inoltrare per conto di altri no.

Con l'inoltro attivo, l'istanza può agire come next hop per una rotta VPC, che è il ruolo di cui ha bisogno un'appliance VPN. Il flag non dice nulla su firewall, routing del guest, configurazione del tunnel o percorsi di ritorno, e un valore true su un gateway guasto resta un gateway guasto.

Leggere la proprietà attuale

Ispeziona l'impostazione prima di cambiare qualsiasi cosa, con un describe in sola lettura sull'istanza, il progetto e la zona previsti:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

Un valore false conta solo se questa VM deve essere un next hop. Se lo è, il resto del percorso va comunque verificato separatamente, perché la proprietà è una riga in una catena più lunga.

Aggiornare l'istanza esistente

La procedura di aggiornamento delle proprietà dell'istanza di Google esporta la risorsa corrente, modifica la proprietà e invia il risultato. È un flusso di lavoro diverso dal flag --can-ip-forward del momento di creazione, ed è quello che funziona su una VM in esecuzione.

Esporta prima la definizione in un file locale, e conserva una copia invariata per il confronto:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

In quel file esportato, imposta la proprietà e non cambiare nient'altro:

canIpForward: true

Conserva l'intera risorsa, impronta compresa. Sostituire il file con un documento YAML di una riga, o raggruppare modifiche non correlate a tipo di macchina, disco o interfaccia nella stessa sottomissione, è il modo in cui una modifica di proprietà diventa un'interruzione.

Chiedi al meccanismo di aggiornamento di convalidare il file e di indicare cosa richiederebbe, prima che sia consentita qualsiasi modifica effettiva:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

Quella esecuzione di convalida non abilita l'inoltro. Leggi la risposta per le proprietà non valide e per l'azione che dichiara necessaria. Per questa modifica isolata l'azione documentata è REFRESH. Se il risultato chiede un riavvio, il file contiene più della proprietà che volevi cambiare, quindi ispezionalo invece di concedere il riavvio.

Applica il file rivisto con il limite refresh:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

Verifica che l'operazione sia completata e riesegui il comando describe. Se l'impronta non corrisponde più, qualcun altro ha modificato l'istanza mentre stavi modificando, quindi esporta una copia nuova e rivedi di nuovo la modifica invece di forzare il tuo file obsoleto.

Il guest deve ancora instradare il pacchetto

Un'autorizzazione cloud non rende l'appliance un router. Conferma che una rotta VPC selezioni questa VM come next hop per il prefisso di destinazione, e che il guest instradi tra il tunnel e l'interfaccia corretta con la propria politica di inoltro attiva.

La politica del firewall deve consentire il flusso interno oltre all'ascoltatore esterno. Aprire solo la porta VPN descrive il trasporto cifrato e non dice nulla sullo scambio applicativo al suo interno.

Infine, la destinazione ha bisogno di un percorso di ritorno verso il pool di client, oppure il progetto deve tradurre le sorgenti deliberatamente. Se la destinazione vede traffico tradotto, controlla la sorgente tradotta; se il progetto conserva il pool, controlla quel pool nella rotta di ritorno e nelle regole di accesso. Aggiungere NAT prima di decidere quale progetto vuoi nasconde una rotta mancante e cambia la politica che la destinazione vede.

Su un gateway Linux, l'inoltro del kernel fa parte della configurazione del guest. Un'appliance pfSense ha il proprio equivalente, e copiarvi un comando sysctl di Linux non è il passo corrispondente.

Verificare dal client che ha bisogno di accesso

Prova da un client VPN verso un servizio di destinazione, non dal gateway stesso. Una connessione avviata sul gateway usa una sorgente diversa e non esercita mai le regole di inoltro che hai appena abilitato.

Registra la proprietà in qualunque cosa gestisca l'appliance. Una VM corretta a mano funziona fino alla sua prossima sostituzione, che reintroduce silenziosamente l'impostazione originale, e quel guasto sembrerà una regressione del software VPN.

Ordine di lavoro: leggi la proprietà, esporta e modifica una riga, convalida con NO_EFFECT, applica con REFRESH, conferma che il guest inoltra, poi prova da un client.