Activa el reenviament IP en una passarel·la GCE VPN existent

La VM es va crear sense reenviament IP, ja executa el programari VPN, i l'instint és reconstruir-la a partir de la plantilla amb el flag activat. Aquesta reconstrucció és innecessària. Compute Engine exposa canIpForward com una propietat actualitzable, i el camí d'actualització documentat l'aplica amb un refresh en lloc d'un reinici. El que el flag controla realment és estret: sense ell, la plataforma descarta els paquets que arriben a la instància però no estan adreçats a l'adreça pròpia de la instància. Una passarel·la que reenvia el trànsit d'altres màquines fa exactament això, així que el flag ha d'estar activat. Tot el que ve després és configuració del hoste i encaminament, que el flag no toca.

Què permet el flag i què no

Amb el reenviament desactivat, la plataforma tracta la instància com un extrem. Els paquets la destinació dels quals és l'adreça pròpia de la instància es lliuren; els paquets que la instància ha de fer passar en nom d'algú altre, no.

Amb el reenviament activat, la instància pot actuar com a següent salt per a una ruta VPC, que és el paper que necessita un aparell VPN. El flag no diu res sobre tallafocs, encaminament del hoste, configuració del túnel ni camins de retorn, i un valor true en una passarel·la espatllada continua sent una passarel·la espatllada.

Llegeix la propietat actual

Inspecciona la configuració abans de canviar res, amb un describe de només lectura contra la instància, el projecte i la zona previstos:

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

Un valor false només importa si aquesta VM ha de ser un següent salt. Si ho és, la resta del camí encara s'ha de comprovar per separat, perquè la propietat és una línia en una cadena més llarga.

Actualitza la instància existent

El procediment d'actualització de propietats d'instància de Google exporta el recurs actual, modifica la propietat i envia el resultat. És un flux de treball diferent del flag --can-ip-forward del moment de creació, i és el que funciona en una VM en marxa.

Exporta primer la definició a un fitxer local i conserva'n una còpia sense canvis per comparar:

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

En aquest fitxer exportat, defineix la propietat i no canviïs res més:

canIpForward: true

Conserva tot el recurs, inclosa la seva empremta. Substituir el fitxer per un document YAML d'una línia, o agrupar edicions no relacionades de tipus de màquina, disc o interfície en la mateixa tramesa, és com un canvi de propietat es converteix en una caiguda.

Demana al mecanisme d'actualització que validi el fitxer i informi què requeriria, abans que es permeti cap canvi efectiu:

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

Aquesta execució de validació no activa el reenviament. Llegeix la resposta per buscar propietats no vàlides i l'acció que diu que cal. Per a aquest canvi aïllat, l'acció documentada és REFRESH. Si el resultat demana un reinici, el fitxer conté més que la propietat que volies canviar, així que inspecciona'l en lloc de concedir el reinici.

Aplica el fitxer revisat amb el límit de refresh:

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

Comprova que l'operació s'ha completat i torna a executar l'ordre describe. Si l'empremta ja no coincideix, algú altre ha canviat la instància mentre editaves, així que exporta'n una còpia nova i revisa el canvi de nou en lloc de forçar el teu fitxer obsolet.

El hoste encara ha d'encaminar el paquet

El permís al núvol no converteix l'aparell en un encaminador. Confirma que una ruta VPC selecciona aquesta VM com a següent salt per al prefix de destinació, i que el hoste encamina entre el túnel i la interfície correcta amb la seva pròpia política de reenviament activada.

La política del tallafoc ha de permetre el flux intern així com l'oient extern. Obrir només el port VPN descriu el transport xifrat i no diu res sobre l'intercanvi d'aplicació a dins.

Finalment, la destinació necessita un camí de retorn cap al conjunt de clients, o el disseny ha de traduir les fonts deliberadament. Si la destinació veu trànsit traduït, comprova la font traduïda; si el disseny conserva el conjunt, comprova aquest conjunt a la ruta de retorn i a les regles d'accés. Afegir NAT abans de decidir quin disseny vols amaga una ruta que falta i canvia la política que veu la destinació.

En una passarel·la Linux, el reenviament del nucli forma part de la configuració del hoste. Un aparell pfSense té el seu equivalent, i copiar-hi una ordre sysctl de Linux no és el pas corresponent.

Verifica des del client que necessita accés

Prova des d'un client VPN cap a un servei objectiu, no des de la passarel·la mateixa. Una connexió iniciada a la passarel·la fa servir una font diferent i mai exercita les regles de reenviament que acabes d'activar.

Registra la propietat en allò que gestioni l'aparell. Una VM corregida manualment funciona fins que la seva propera substitució reintrodueix silenciosament la configuració original, i aquesta fallada semblarà una regressió del programari VPN.

Ordre de treball: llegeix la propietat, exporta i edita una línia, valida amb NO_EFFECT, aplica amb REFRESH, confirma que el hoste reenvia i després prova des d'un client.