API de Google por VPN: encamiña a VIP, non só a subrede

Entra por SSH no servidor local, levanta o túnel e a VM privada responde; despois a primeira chamada a unha API de Google falla sen ruta. A subrede da VM e as VIP da API son destinos distintos, así que unha ruta para unha non selecciona a outra. Deben cumprirse tres condicións antes de que unha chamada privada á API funcione. O nome da API debe resolverse nunha VIP, o prefixo VIP debe anunciarse polo túnel e a VPC debe saber como enviar a resposta de volta. Un ping non che di nada diso, e unha sesión SSH que funciona cara a unha máquina da subrede tampouco.

As VIP da API son destinos separados

Google publica VIP dedicadas para o acceso á API desde a rede local, e esas son as direccións que o teu DNS debe devolver para os nomes da API. Ambas son prefixos pequenos e ningunha é espazo RFC 1918:

As direccións que parecen públicas non significan que a ruta deba saír do túnel para a internet común. Os prefixos existen para que un cliente local acade os frontais de Google por un camiño admitido en lugar dun punto de saída arbitrario. Trátaos como destinos que pertencen ao túnel, non como hosts que sondar. Unha regra de devasas escrita para a saída a internet adoita descartalos, e é unha razón habitual pola que unha chamada falla antes de comezar.

O DNS decide a que extremo chegas

Apunta o resolutor local aos rexistros que Google documenta para o extremo elixido, de modo que os nomes que necesita a aplicación respondan con esa VIP. Só googleapis.com non é un inventario: os rexistros de paquetes, os rexistros de contedores e os conectores de migración teñen os seus propios nomes documentados. A VIP restrinxida tampouco leva todos os servizos, así que un nome que se resolve pode seguir sen soporte. Anota os dominios que a aplicación contacta realmente antes de tocar o resolutor.

Adiviñar un enderezo de VM da VPC como substituto dun nome de servizo non é unha solución, e normalmente oculta o oco de DNS ata que falla outro cliente.

Anuncia o prefixo VIP, conserva o resto

Cunha conexión baseada en BGP, o Cloud Router debe anunciar o prefixo VIP elixido para que o router local aprenda ese rango pola sesión prevista. Anunciar só as subredes da VPC non engade ese rango, e o router local segue usando a súa ruta por defecto para esas direccións. O prefixo da táboa de rutas é a única proba de que o anuncio cruzou a sesión.

Conserva os anuncios existentes mentres engades o novo, porque as opcións a nivel de router e a nivel de par teñen alcance distinto, e cambiar o conxunto pode retirar redes que xa funcionaban. Despois comproba o anuncio efectivo en cada sesión en lugar de no router enteiro. Un prefixo ausente e un prefixo retirado vense iguais desde o lado local, así que a vista da sesión é o que separa unha omisión dunha regresión.

O lado da VPC necesita a súa propia ruta e camiño de volta

Dentro da VPC, o camiño da VIP debe usar a pasarela de internet predeterminada como seguinte salto, e malia o nome ese tráfico queda dentro da rede de Google. A VPC tamén necesita unha ruta de volta á orixe local pola VPN, que é un obxecto aparte do prefixo anunciado. Ten en conta os requisitos rexionais de encamiñamento documentados cando o túnel e o cliente non están na mesma rexión.

Comproba o camiño de volta de forma independente, porque unha dirección de petición que funciona pode ocultar unha dirección de resposta rota. Dúas direccións, dúas rutas, e cada unha falla co seu propio síntoma.

Proba a petición e despois le o rexeitamento

O eco ICMP non obtén resposta destas VIP, así que un ping fallido non demostra nada e un correcto demostra moi pouco. Desde o cliente real, examina a resposta do nome e a ruta seleccionada, e despois fai unha petición HTTPS autorizada ao servizo que che interesa. Se a petición chega ao servizo e se rexeita, mira as credenciais, IAM e calquera política de perímetro de servizo que se aplique.

O encamiñamento privado non concede autorización de API e non cambia o que a identidade pode facer. O éxito do transporte e unha resposta autorizada son resultados separados, e necesitas ambos. Mantén tamén explícito o camiño IPv6, porque configurar os prefixos IPv4 non di nada sobre un cliente que prefire IPv6.

A guía de Google sobre Private Google Access desde a rede local cubre xuntos os rexistros DNS e os requisitos de encamiñamento, así que compara a túa configuración de resolutor e de anuncio con ela e non cunha publicación de foro. Despois repite a mesma petición e anota a resposta e a ruta no mesmo tícket.