Por que um Apps Script não alcança a sua aplicação interna pela VPN

O painel abre bem no navegador do portátil, mas o mesmo script de planilha falha com um erro de endereço indisponível. Ligar ou desligar a VPN não muda nada, porque o pedido nunca sai do portátil. O Apps Script executa-se na infraestrutura do Google e abre a sua própria ligação a partir daí. Esse único facto decide todo o desenho.

Separe duas perguntas antes de mudar qualquer coisa: que máquina envia o pedido e que credencial o recetor aceita.

O pedido nunca começa no seu portátil

Um separador do navegador envia a partir do portátil, através do adaptador VPN, do sufixo DNS interno e para a sub-rede privada. O UrlFetchApp envia a partir de um anfitrião gerido pelo Google, por isso vê os resolvedores do Google, os endereços de saída do Google e nenhuma das suas rotas de túnel dividido. Os dois caminhos partilham um documento de planilha, não uma localização de rede. No registo de acesso da aplicação, a tentativa do script aparece como um endereço do Google em vez de um endereço do conjunto de VPN, e essa é a confirmação mais rápida que vai obter.

Por isso as correções locais não fazem nada. Apontar o portátil para outro resolvedor, reiniciar o cliente VPN ou acrescentar uma entrada em hosts muda o caminho do navegador e deixa o caminho do script exatamente como estava.

O que isso exclui

Um ponto final apenas interno não é alcançável a partir do Apps Script, e a lista de IP permitidos é um substituto fraco do controlo de acesso nesta posição. Os intervalos de saída do Google são amplos, partilhados com outros clientes e impossíveis de ligar a um único script. A referência do UrlFetchApp indica que os pedidos se originam no conjunto de IP do Google, que é a versão autorizada dessa afirmação. Abrir a aplicação interna a esses intervalos admite tráfego que não consegue atribuir.

As sessões do navegador comportam-se da mesma forma. Um cookie ou uma sessão SSO no navegador do portátil não viaja com o pedido, que é um cliente HTTPS novo sem estado de sessão. Tudo o que depende de um redirecionamento SSO do navegador termina nesse redirecionamento e não nos seus dados.

Duas formas viáveis

A primeira forma dá ao script uma API aprovada. Publique o serviço interno atrás de uma passagem que autentique o chamador e depois faça o script apresentar uma credencial que a passagem aceite, como um token de conta de serviço. No Apps Script isso significa uma biblioteca OAuth2 ou ScriptApp.getOAuthToken(), mais uma lista de identidades de chamador permitidas do lado da API em vez de uma lista de IP.

A segunda forma inverte a direção. Uma tarefa interna consulta o sistema privado e publica um resultado controlado num Sheet, num objeto do Cloud Storage ou numa tabela do BigQuery que o script lê. Uma tarefa do Cloud Run, um agendador local ou um passo ETL existente podem todos ser essa tarefa, e nenhum deles precisa de aceitar uma ligação de entrada. A folha consome então um conjunto de dados em vez de uma interface.

Qual forma vence depende da frescura, do controlo ao nível do campo e de quem tem de poder auditar o leitor.

O que o resultado publicado tem de conter

Um fluxo na direção inversa precisa de um contrato explícito: os campos que transporta, o intervalo de atualização, o grupo de leitores e o que acontece quando a tarefa interna falha. Sem esses quatro a folha mostra em silêncio os números de ontem. Acrescente uma coluna de marca temporal gerada e uma contagem de linhas para que uma publicação obsoleta ou parcial seja visível na própria folha, sem que ninguém abra um registo.

A direção da API também precisa de um contrato: que credencial a passagem aceita, que âmbitos o token transporta e que identidades de chamador são permitidas. Uma resposta 200 que contém uma página de início de sessão não é uma chamada bem-sucedida, por isso verifique o corpo e não apenas o código de estado.

Leia o erro do lado certo

O Apps Script reporta um anfitrião inacessível como uma exceção de endereço indisponível, que não é a mensagem de ligação recusada do navegador. Um 403 da passagem significa que o pedido chegou e que uma credencial ou política foi rejeitada. Uma página de início de sessão HTML significa que o pedido alcançou uma camada interativa que um script não consegue completar. Três falhas diferentes com três responsáveis diferentes.

Mantenha o registo do script ao lado do resultado do navegador em vez de substituir um pelo outro. A pergunta que resta é então uma decisão de integração comum: dar a esse ambiente o acesso de que precisa ou entregar-lhe um resultado controlado.