Ativar o encaminhamento de IP num gateway GCE VPN existente

A VM foi criada sem encaminhamento de IP, já executa o software VPN, e o instinto é reconstruí-la a partir do modelo com o sinalizador ativado. Essa reconstrução é desnecessária. O Compute Engine expõe canIpForward como uma propriedade atualizável, e o caminho de atualização documentado aplica-a com um refresh em vez de um reinício. O que o sinalizador controla na prática é estreito: sem ele, a plataforma descarta os pacotes que chegam à instância mas não são endereçados ao endereço próprio da instância. Um gateway que encaminha o tráfego de outras máquinas faz exatamente isso, por isso o sinalizador tem de estar ativo. Tudo o que vem depois é configuração do convidado e encaminhamento, que o sinalizador não toca.

O que o sinalizador permite, e o que não permite

Com o encaminhamento desativado, a plataforma trata a instância como um ponto final. Os pacotes cujo destino é o endereço próprio da instância são entregues; os pacotes que a instância deve reencaminhar em nome de outra pessoa não são.

Com o encaminhamento ativado, a instância pode atuar como próximo salto de uma rota VPC, e esse é o papel de que uma aplicação VPN necessita. O sinalizador não diz nada sobre firewalls, encaminhamento do convidado, configuração do túnel ou caminhos de retorno, e um valor true num gateway avariado continua a ser um gateway avariado.

Ler a propriedade atual

Inspecione a definição antes de alterar seja o que for, com um describe só de leitura contra a instância, o projeto e a zona pretendidos:

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

Um valor false só é relevante se esta VM se destina a ser o próximo salto. Se for, o resto do caminho continua a ter de ser verificado em separado, porque a propriedade é uma linha numa cadeia mais longa.

Atualizar a instância existente

O procedimento de atualização de propriedades de instância da Google exporta o recurso atual, modifica a propriedade e submete o resultado. É um fluxo de trabalho diferente do sinalizador --can-ip-forward do momento da criação, e é o que funciona numa VM em execução.

Exporte primeiro a definição para um ficheiro local, e guarde uma cópia inalterada para comparação:

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

Nesse ficheiro exportado, defina a propriedade e não altere mais nada:

canIpForward: true

Mantenha todo o recurso, incluindo a respetiva impressão digital. Substituir o ficheiro por um documento YAML de uma linha, ou agrupar edições não relacionadas de tipo de máquina, disco ou interface na mesma submissão, é a forma como uma alteração de propriedade se torna uma paragem.

Peça ao mecanismo de atualização para validar o ficheiro e indicar o que exigiria, antes de ser permitida qualquer alteração efetiva:

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

Essa execução de validação não ativa o encaminhamento. Leia a resposta para propriedades inválidas e para a ação que diz ser necessária. Para esta alteração isolada, a ação documentada é REFRESH. Se o resultado pedir um reinício, o ficheiro contém mais do que a propriedade que queria alterar, por isso inspecione-o em vez de conceder o reinício.

Aplique o ficheiro revisto com o limite de refresh:

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

Verifique se a operação terminou e execute novamente o comando describe. Se a impressão digital já não coincidir, alguém alterou a instância enquanto editava, por isso exporte uma cópia nova e reveja a alteração outra vez em vez de forçar o seu ficheiro desatualizado.

O convidado ainda tem de encaminhar o pacote

Uma permissão na nuvem não transforma a aplicação num router. Confirme que uma rota VPC seleciona esta VM como próximo salto para o prefixo de destino, e que o convidado encaminha entre o túnel e a interface correta com a sua própria política de encaminhamento ativada.

A política da firewall tem de permitir o fluxo interno, bem como o ouvinte externo. Abrir apenas a porta VPN descreve o transporte cifrado e não diz nada sobre a troca da aplicação no seu interior.

Por fim, o destino precisa de um caminho de retorno para o conjunto de clientes, ou o desenho tem de traduzir as origens de forma deliberada. Se o destino vê tráfego traduzido, verifique a origem traduzida; se o desenho preserva o conjunto, verifique esse conjunto na rota de retorno e nas regras de acesso. Acrescentar NAT antes de decidir qual desenho quer oculta uma rota em falta e altera a política que o destino vê.

Num gateway Linux, o encaminhamento do núcleo faz parte da configuração do convidado. Uma aplicação pfSense tem o seu próprio equivalente, e copiar para lá um comando sysctl do Linux não é o passo correspondente.

Verificar a partir do cliente que precisa de acesso

Teste a partir de um cliente VPN para um serviço de destino, não a partir do próprio gateway. Uma ligação iniciada no gateway usa outra origem e nunca exercita as regras de encaminhamento que acabou de ativar.

Registe a propriedade naquilo que gere a aplicação. Uma VM corrigida à mão funciona até a substituição seguinte reintroduzir silenciosamente a definição original, e essa falha parecerá uma regressão no software VPN.

Ordem do trabalho: ler a propriedade, exportar e editar uma linha, validar com NO_EFFECT, aplicar com REFRESH, confirmar que o convidado encaminha e depois testar a partir de um cliente.