Activar o reenvío de IP nunha pasarela GCE VPN existente
canIpForward é unha propiedade actualizable, non un motivo para reconstruír a VM. Exporta o recurso, cambia unha liña, valida e despois aplica cun refresh.
A VM creouse sen reenvío de IP, xa executa o software VPN, e o instinto é reconstruíla a partir do modelo coa opción activada. Esa reconstrución é innecesaria. Compute Engine expón canIpForward como unha propiedade actualizable, e a ruta de actualización documentada aplícaa cun refresh en lugar dun reinicio. O que a opción controla realmente é estreito: sen ela, a plataforma descarta os paquetes que chegan á instancia pero non están dirixidos ao enderezo propio da instancia. Unha pasarela que reenvía o tráfico doutras máquinas fai exactamente iso, así que a opción ten que estar activada. Todo o demais é configuración do hóspede e encamiñamento, que a opción non toca.
Que permite a opción e que non
Co reenvío desactivado, a plataforma trata a instancia como un extremo. Entréganse os paquetes cuxo destino é o enderezo propio da instancia; os paquetes que a instancia debe reenviar en nome doutro, non.
Co reenvío activado, a instancia pode actuar como seguinte salto dunha ruta VPC, que é o papel que necesita un dispositivo VPN. A opción non di nada sobre cortalumes, encamiñamento do hóspede, configuración do túnel nin rutas de retorno, e un valor true nunha pasarela rota segue sendo unha pasarela rota.
Ler a propiedade actual
Inspecciona a configuración antes de cambiar nada, cun describe de só lectura contra a instancia, o proxecto e a zona previstos:
gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'
Un valor false só importa se esta VM debe ser un seguinte salto. Se o é, o resto do camiño aínda hai que comprobalo por separado, porque a propiedade é unha liña nunha cadea máis longa.
Actualizar a instancia existente
O procedemento de actualización de propiedades de instancia de Google exporta o recurso actual, modifica a propiedade e envía o resultado. Ese é un fluxo de traballo distinto da opción --can-ip-forward do momento de creación, e é o que funciona nunha VM en marcha.
Exporta primeiro a definición a un ficheiro local e conserva unha copia sen cambios para comparar:
gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml
Nese ficheiro exportado, define a propiedade e non cambies nada máis:
canIpForward: true
Conserva todo o recurso, incluída a súa pegada. Substituír o ficheiro por un documento YAML dunha liña, ou agrupar edicións non relacionadas de tipo de máquina, disco ou interface no mesmo envío, é como un cambio de propiedade se converte nunha caída.
Pide ao mecanismo de actualización que valide o ficheiro e informe que requiriría, antes de que se permita calquera cambio efectivo:
gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT
Esa execución de validación non activa o reenvío. Le a resposta na procura de propiedades non válidas e da acción que di que fai falta. Para este cambio illado, a acción documentada é REFRESH. Se o resultado pide un reinicio, o ficheiro contén máis ca a propiedade que querías cambiar, así que inspeccióao en lugar de conceder o reinicio.
Aplica o ficheiro revisado co límite de refresh:
gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH
Comproba que a operación rematou e executa de novo o comando describe. Se a pegada xa non coincide, alguén máis cambiou a instancia mentres editabas, así que exporta unha copia nova e revisa o cambio outra vez en lugar de forzar o teu ficheiro obsoleto.
O hóspede aínda ten que encamiñar o paquete
O permiso na nube non converte o dispositivo nun router. Confirma que unha ruta VPC selecciona esta VM como seguinte salto para o prefixo de destino, e que o hóspede encamiña entre o túnel e a interface correcta coa súa propia política de reenvío activada.
A política do cortalumes ten que permitir o fluxo interno ademais do oínte externo. Abrir só o porto VPN describe o transporte cifrado e non di nada sobre o intercambio da aplicación dentro del.
Por último, o destino necesita unha ruta de retorno cara ao conxunto de clientes, ou o deseño ten que traducir as fontes a propósito. Se o destino ve tráfico traducido, comproba a fonte traducida; se o deseño conserva o conxunto, comproba ese conxunto na ruta de retorno e nas regras de acceso. Engadir NAT antes de decidir que deseño queres agocha unha ruta que falta e cambia a política que ve o destino.
Nunha pasarela Linux, o reenvío do núcleo forma parte da configuración do hóspede. Un dispositivo pfSense ten o seu propio equivalente, e copiar nel un comando sysctl de Linux non é o paso correspondente.
Verificar desde o cliente que necesita acceso
Proba desde un cliente VPN cara a un servizo de destino, non desde a propia pasarela. Unha conexión iniciada na pasarela usa unha fonte distinta e nunca exercita as regras de reenvío que acabas de activar.
Rexistra a propiedade no que xestione o dispositivo. Unha VM corrixida a man funciona ata que a súa seguinte substitución reintroduce en silencio a configuración orixinal, e ese fallo parecerá unha regresión do software VPN.
Orde de traballo: le a propiedade, exporta e edita unha liña, valida con NO_EFFECT, aplica con REFRESH, confirma que o hóspede reenvía e despois proba desde un cliente.