Acerca de los servicios publicados
En este documento, se proporciona una descripción general del uso de Private Service Connect para que un servicio esté disponible para los consumidores de servicios.
Como productor de servicios, puedes usar Private Service Connect para publicar servicios mediante direcciones IP internas en tu red de VPC. Los consumidores de servicios pueden acceder a los servicios publicados mediante direcciones IP internas en sus redes de VPC.
Para que un servicio esté disponible para los consumidores, debes crear una o más subredes dedicadas. Luego, debes crear un adjunto de servicio que haga referencia a esas subredes. El adjunto del servicio puede tener preferencias de conexión diferentes.
Tipos de consumidores de servicios
Existen dos tipos de consumidores que pueden conectarse a un servicio de Private Service Connect:
Los extremos se basan en una regla de reenvío.
Un extremo permite que los consumidores de servicios envíen tráfico desde la red de VPC del consumidor hacia servicios en la red de VPC del productor de servicios (haz clic para agrandar).
Los backends se basan en un balanceador de cargas.
Un backend que usa un balanceador de cargas de aplicaciones externo global permite que los consumidores de servicios con acceso a Internet envíen tráfico a los servicios en la red de VPC del productor de servicios (haz clic para ampliar).
Subredes NAT
Los adjuntos del servicio de Private Service Connect se configuran con una o más subredes NAT (también conocidas como subredes de Private Service Connect). Los paquetes de la red de VPC del consumidor se traducen mediante NAT de origen (SNAT) para que sus direcciones IP de origen originales se conviertan en direcciones IP de origen de la subred NAT en la red de VPC del productor.
Los adjuntos de servicio pueden tener varias subredes NAT. Se pueden agregar subredes NAT al adjunto de servicio en cualquier momento sin interrumpir el tráfico.
Si bien un adjunto de servicio puede tener varias subredes NAT configuradas, no se puede usar una subred NAT en más de un adjunto de servicio.
Las subredes NAT de Private Service Connect no se pueden usar para recursos como instancias de máquina virtual (VM) o reglas de reenvío. Las subredes se usan solo a fin de proporcionar direcciones IP para la SNAT de las conexiones entrantes de consumidores.
Tamaño de subred NAT
El tamaño de la subred determina cuántos consumidores pueden conectarse a tu servicio. Si se consumen todas las direcciones IP en la subred NAT, fallará cualquier conexión adicional de Private Service Connect. Ten en cuenta lo siguiente:
Se consume una dirección IP desde la subred NAT para cada extremo o backend que está conectado al adjunto de servicio.
La cantidad de conexiones TCP o UDP, clientes o redes de VPC del consumidor no afecta el consumo de direcciones IP de la subred NAT.
Si los consumidores usan la propagación de conexiones, se consume una dirección IP adicional para cada radio de VPC al que se propagan las conexiones, para cada extremo.
Puedes controlar cuántas conexiones propagadas se crean configurando el límite de conexiones propagadas.
Cuando estimes cuántas direcciones IP necesitas para extremos y backends, ten en cuenta cualquier servicio de multiusuario o consumidores que usan el acceso de varios puntos para Private Service Connect.
Supervisión de la subred NAT
Para garantizar que las conexiones de Private Service Connect no fallen debido a direcciones IP no disponibles en una subred NAT, te recomendamos que sigas los siguientes pasos:
- Supervisa la métrica de adjunto de servicio
private_service_connect/producer/used_nat_ip_addresses. Asegúrate de que la cantidad de direcciones IP de NAT que se usen no exceda la capacidad de las subredes NAT de un adjunto de servicio. - Supervisa el estado de la conexión de las conexiones del adjunto de servicio. Si la conexión tiene el estado Requiere atención, es posible que no haya más direcciones IP disponibles en las subredes NAT del adjunto.
- En el caso de los servicios de múltiples usuarios, puedes usar límites de conexión para garantizar que un solo consumidor no agote la capacidad de las subredes NAT de un adjunto de servicio.
Si es necesario, se pueden agregar subredes NAT al adjunto del servicio en cualquier momento sin interrumpir el tráfico.
Especificaciones de NAT
Considera las siguientes características de NAT de Private Service Connect cuando diseñes el servicio que publicarás:
El tiempo de espera de inactividad de la asignación de UDP es de 30 segundos y no se puede configurar.
El tiempo de espera de inactividad de la conexión establecida de TCP es de 20 minutos y no se puede configurar.
Para evitar problemas con el agotamiento del tiempo de espera de las conexiones de clientes, realiza una de las siguientes acciones:
Asegúrate de que todas las conexiones se ejecuten por menos de 20 minutos.
Asegúrate de que parte del tráfico se envíe con mayor frecuencia que una vez cada 20 minutos. Puedes usar un keepalive o una señal de monitoreo de funcionamiento en tu aplicación, o bien keepalives de TCP. Por ejemplo, puedes configurar un keepalive en el proxy de destino de un balanceador de cargas de aplicaciones interno regional o un balanceador de cargas de red de proxy interno regional.
El tiempo de espera de inactividad de la conexión transitoria de TCP es de 30 segundos y no se puede configurar.
Existe una demora de dos minutos antes de que se pueda volver a usar cualquier tupla de 5 (la dirección IP de origen de la subred de NAT y el puerto de origen, el protocolo de destino, la dirección IP y el puerto de destino).
SNAT para Private Service Connect no admite fragmentos de IP.
Cantidad máxima de conexiones
Una sola VM de productor puede aceptar un máximo de 64,512 conexiones TCP simultáneas y 64,512 conexiones UDP desde un solo consumidor de Private Service Connect (extremo o backend). No hay límite para la cantidad total de conexiones TCP y UDP que un extremo de Private Service Connect puede recibir en conjunto en todos los backends del productor. Las VMs de cliente pueden usar los 65,536 puertos de origen cuando se inician conexiones TCP o UDP a un extremo de Private Service Connect. Toda la traducción de direcciones de red se realiza de forma local en el host del productor, que no requiere un grupo de puertos NAT asignado de forma central.
Adjuntos de servicio
Los productores de servicios exponen sus servicios a través de un adjunto de servicio.
- Para exponer un servicio, un productor de servicios crea un adjunto de servicio que hace referencia a un servicio de destino. El servicio de destino puede ser uno de los siguientes:
- La regla de reenvío de un balanceador de cargas
- Una instancia de Secure Web Proxy
El URI del adjunto de servicio tiene este formato: projects/SERVICE_PROJECT/regions/REGION/serviceAttachments/SERVICE_NAME
Un adjunto de servicio solo puede tener un servicio de destino. Sin embargo, varios adjuntos de servicio pueden compartir el mismo servicio de destino.
Los adjuntos de servicio te permiten controlar el acceso a tu servicio publicado, ver las conexiones y configurar límites de conexión. Para obtener más información, consulta Acerca del control de acceso a los servicios publicados.
Estados de conexión
Los adjuntos de servicio tienen estados de conexión que describen el estado de sus conexiones. Para obtener más información, consulta Estados de conexión.
Configuración del DNS
Si deseas obtener información sobre la configuración de DNS para los servicios publicados y los extremos que se conectan a los servicios publicados, consulta Configuración de DNS para servicios.
Configuración de varias regiones para la conmutación por error
Puedes hacer que un servicio esté disponible en varias regiones si creas las siguientes configuraciones.
Configuración del productor:
- Implementa el servicio en cada región. Cada instancia regional del servicio debe configurarse en un balanceador de cargas regional que admita el acceso mediante un backend.
- Crea un adjunto de servicio para publicar cada instancia regional del servicio.
Configuración del consumidor:
- Crea un backend de Private Service Connect para acceder a los servicios publicados. El backend
debe basarse en un
balanceador de cargas que admita la conmutación por error entre regiones
y debe incluir la siguiente configuración:
- Un NEG de Private Service Connect en cada región que apunte al adjunto de servicio de esa región
- Un servicio de backend global que contiene los backends de NEG
Esta configuración admite la conmutación por error automática entre regiones. Con la conmutación por error automática, si una instancia de servicio en una región deja de estar en buen estado, el balanceador de cargas del consumidor deja de enrutar el tráfico a ese servicio y, en cambio, lo enruta a una instancia de servicio en buen estado en una región alternativa.
Para obtener más información, consulta lo siguiente:
- Acerca del estado de Private Service Connect
- Conmutación por error automática entre regiones para los clientes
El uso de un balanceador de cargas de aplicaciones externo global permite que los consumidores de servicios con acceso a Internet envíen tráfico a los servicios en la red de VPC del productor de servicios. Debido a que el servicio se implementa en varias regiones, el balanceador de cargas del consumidor puede enrutar el tráfico a una instancia de servicio en buen estado en una región alternativa (haz clic para agrandar).
Traducción de la versión de IP
Para los extremos de Private Service Connect que se conectan a servicios publicados (adjuntos de servicio), la versión de IP de la dirección IP de la regla de reenvío del consumidor determina la versión de IP del extremo y el tráfico que sale del extremo. La dirección IP puede provenir de una subred solo IPv4, solo IPv6 o de pila doble. La versión de IP del extremo puede ser IPv4 o IPv6, pero no ambas.
En el caso de los servicios publicados, la versión de IP del adjunto de servicio se determina según la dirección IP de la regla de reenvío o la instancia de Secure Web Proxy asociadas. Esta dirección IP debe ser compatible con el tipo de pila de la subred NAT del adjunto de servicio. La subred NAT puede ser una subred solo IPv4, solo IPv6 o de pila doble. Si la subred de NAT es de pila doble, se usa el rango de direcciones IPv4 o IPv6, pero no ambos.
Private Service Connect no admite la conexión de un extremo IPv4 con un adjunto de servicio IPv6. En este caso, la creación del extremo falla con el siguiente mensaje de error:
Private Service Connect forwarding rule with an IPv4 address
cannot target an IPv6 service attachment.
Las siguientes combinaciones son posibles para las configuraciones compatibles:
- Extremo de IPv4 al adjunto de servicio IPv4
- Extremo de IPv6 al adjunto de servicio IPv6
-
Extremo de IPv6 al adjunto de servicio IPv4
En esta configuración, Private Service Connect traduce automáticamente entre las dos versiones de IP.
Para las conexiones entre los backends de Private Service Connect y los adjuntos de servicio, las reglas de reenvío del consumidor y del productor deben usar IPv4.
Características y compatibilidad
En las siguientes tablas, una marca de verificación indica que una función es compatible, y un símbolo no indica que la función no es compatible.
Según el balanceador de cargas del productor que se elija, el servicio de productor puede admitir el acceso por extremos, backends o ambos.
Compatibilidad con extremos
En esta sección, se resumen las opciones de configuración que están disponibles para consumidores y productores cuando usan extremos para acceder a servicios publicados.
Configuración del consumidor
En esta tabla, se resumen las opciones de configuración y las capacidades compatibles de los extremos que acceden a los servicios publicados según el tipo de productor objetivo.
Configuración del productor
En esta tabla, se resumen las opciones de configuración y las capacidades de los servicios publicados a los que se accede mediante extremos.
| Tipo de productor | Configuración del productor (servicio publicado) | |||
|---|---|---|---|---|
| Backends de productores compatibles | Protocolo de PROXY (solo tráfico de TCP) | Versión de IP | ||
| Balanceador de cargas de aplicaciones interno entre regiones |
|
|
||
| Balanceador de cargas de red de transferencia interno |
|
|
||
| Reenvío de protocolo interno (instancia de destino) |
|
|
||
| Servicios de asignación de puertos |
|
|
||
| Balanceador de cargas de aplicaciones interno regional |
|
|
||
| Balanceador de cargas de red del proxy interno regional |
|
|
||
| Proxy web seguro |
|
|
||
Los diferentes balanceadores de cargas admiten diferentes configuraciones de puertos; algunos balanceadores de cargas admiten un solo puerto, otros admiten un rango de puertos y otros admiten todos los puertos. Para obtener más información, consulta Especificaciones de puertos.
Compatibilidad con backends
Un backend de Private Service Connect para servicios publicados requiere dos balanceadores de cargas: un balanceador de cargas del consumidor y un balanceador de cargas del productor. En esta sección, se resumen las opciones de configuración que están disponibles para consumidores y productores cuando usan backends para acceder a servicios publicados.
Configuración del consumidor
En esta tabla, se describen los balanceadores de cargas de consumidores que son compatibles con los backends de Private Service Connect para servicios publicados, incluidos los protocolos de servicios de backend que se pueden usar con cada balanceador de cargas de consumidores. Los balanceadores de cargas de consumidores pueden acceder a los servicios publicados que se alojan en balanceadores de cargas de productores compatibles.
| Balanceador de cargas del consumidor | Protocolos | Versión de IP | Conmutación por error entre regiones |
|---|---|---|---|
|
Balanceador de cargas de aplicaciones interno entre regiones |
|
IPv4 | |
|
Balanceador de cargas de red del proxy interno entre regiones |
|
IPv4 | |
|
Balanceador de cargas de aplicaciones externo global Nota: No se admite el balanceador de cargas de aplicaciones clásico. |
|
IPv4 | |
|
Balanceador de cargas de red del proxy externo global Para asociar este balanceador de cargas con un NEG de Private Service Connect, usa Google Cloud CLI o envía una solicitud a la API. Nota: No se admite el balanceador de cargas de red del proxy clásico. |
|
IPv4 | |
|
IPv4 | ||
|
IPv4 | ||
|
IPv4 | ||
|
IPv4 |
Configuración del productor
En esta tabla, se describe la configuración de los balanceadores de cargas del productor que son compatibles con los backends de Private Service Connect para servicios publicados.
| Tipo de productor | Configuración del productor (servicio publicado) | |||||
|---|---|---|---|---|---|---|
| Backends de productores compatibles | Protocolos de reglas de reenvío | Puertos de regla de reenvío | Protocolo PROXY | Versión de IP | Asistencia de Private Service Connect | |
| Balanceador de cargas de aplicaciones interno entre regiones |
|
|
Admite uno, varios o todos los puertos | IPv4 | ||
| Balanceador de cargas de red de transferencia interno |
|
|
Consulta Configuración de puertos del productor | IPv4 | ||
| Balanceador de cargas de aplicaciones interno regional |
|
|
Admite un solo puerto | IPv4 | ||
| Balanceador de cargas de red del proxy interno regional |
|
|
Admite un solo puerto | IPv4 | ||
| Proxy web seguro |
|
|
No aplicable | IPv4 | ||
Configuración del puerto del productor
Cuando se publica un balanceador de cargas de red de transferencia interno con Private Service Connect, los consumidores que usan backends de Private Service Connect para acceder al servicio deben saber qué puerto usar para comunicarse con él. Ten en cuenta lo siguiente cuando crees la regla de reenvío para el balanceador de cargas de red de transferencia interno del productor:
- Recomendamos que les comuniques a los consumidores qué puerto se usa en la regla de reenvío del productor para que puedan especificar el puerto cuando creen un NEG.
Si los consumidores no especifican un puerto del productor cuando crean sus NEG, el puerto del productor se determina según la configuración de la regla de reenvío del productor:
- Si la regla de reenvío del productor usa un solo puerto, el backend del consumidor usa el mismo puerto.
Si la regla de reenvío del productor usa varios puertos, se aplica lo siguiente:
- Si se incluye el puerto
443, el backend del consumidor usa el puerto443. - Si no se incluye el puerto
443, el backend del consumidor usa el primer puerto de la lista, después de que se ordena alfabéticamente. Por ejemplo, si especificas el puerto80y el puerto1111, el backend del consumidor usa el puerto1111. Cambiar los puertos que usan los servidores de backend del productor podría provocar una interrupción del servicio para los consumidores.
Por ejemplo, supongamos que creas un servicio publicado con una regla de reenvío que usa los puertos
443y8443, y VMs de backend que responden en los puertos443y8443. Cuando un backend del consumidor se conecta a este servicio, usa el puerto443para la comunicación.Si cambias las VMs de backend para que solo respondan en el puerto
8443, el backend del consumidor ya no podrá acceder al servicio publicado.
- Si se incluye el puerto
Si la regla de reenvío del productor usa todos los puertos, el consumidor de servicios debe especificar un puerto del productor cuando cree el NEG. Si no especifican un puerto, el backend del consumidor usa el puerto
1, que no funciona.
VPC compartida
Los administradores de proyectos de servicio pueden crear adjuntos de servicio en proyectos de servicio de VPC compartida que se conectan a recursos en las redes de VPC compartidas.
La configuración es la misma que la de un adjunto de servicio normal, excepto por las siguientes diferencias:
- La regla de reenvío del balanceador de cargas del productor está asociada con una dirección IP de la red de VPC compartida. La subred de la regla de reenvío debe compartirse con el proyecto de servicio.
- El adjunto de servicio usa una subred de Private Service Connect de la red de VPC compartida. Esta subred se debe compartir con el proyecto de servicio.
Logging
Puedes habilitar los registros de flujo de VPC en las subredes que contienen las VM de backend. Los registros muestran flujos entre las VM de backend y las direcciones IP en la subred de Private Service Connect.
Controles del servicio de VPC
Los Controles del servicio de VPC y Private Service Connect son compatibles entre sí. Si la red de VPC en la que se implementa el extremo de Private Service Connect está en un perímetro de Controles del servicio de VPC, el extremo forma parte del mismo perímetro. Cualquier servicio admitido por los Controles del servicio de VPC a los que se accede a través del extremo de está sujeto a las políticas de ese perímetro de los Controles del servicio de VPC.
Cuando creas un extremo, las llamadas a la API del plano de control se realizan entre los proyectos del consumidor y del productor para establecer una conexión de Private Service Connect. Establecer una conexión de Private Service Connect entre los proyectos del consumidor y del productor que no están en el mismo perímetro de los Controles del servicio de VPC no requiere una autorización explícita con políticas de salida. La comunicación con los servicios compatibles con los Controles del servicio de VPC a través del extremo está protegida por el perímetro de los Controles del servicio de VPC.
Visualiza la información de conexión del consumidor
De forma predeterminada, Private Service Connect traduce la dirección IP de origen del consumidor a una dirección en una de las subredes de Private Service Connect en la red de VPC del productor de servicios. Si deseas ver la dirección IP de origen original del consumidor, puedes habilitar el protocolo PROXY cuando publiques un servicio. Private Service Connect admite la versión 2 del protocolo PROXY.
No todos los servicios admiten el protocolo PROXY. Para obtener más información, consulta Funciones y compatibilidad.
Si el protocolo PROXY está habilitado, puedes obtener la dirección IP de origen del consumidor y el ID de conexión de PSC (pscConnectionId) desde el encabezado del protocolo PROXY.
El formato de los encabezados del protocolo PROXY depende de la versión de IP del extremo del consumidor. Si el balanceador de cargas de tu adjunto de servicio tiene una dirección IPv6, los consumidores pueden conectarse tanto con direcciones IPv4 como IPv6. Configura tu aplicación para que reciba y lea los encabezados del protocolo PROXY para la versión de IP del tráfico que recibe.
Para el tráfico de consumidores que fluye a través de una conexión propagada, la dirección IP de origen del consumidor y el ID de conexión de PSC hace referencia al extremo de Private Service Connect que se propaga.
Cuando habilitas el protocolo PROXY para un adjunto de servicio, el cambio se aplica solo a las conexiones nuevas. Las conexiones existentes no incluyen el encabezado del protocolo PROXY.
Si habilitas el protocolo PROXY, consulta la documentación del software del servidor web de backend para obtener información sobre el análisis y el procesamiento de los encabezados del protocolo PROXY entrantes en las cargas útiles de TCP de la conexión del cliente. Si el protocolo PROXY está habilitado en el adjunto de servicio, pero el servidor web de backend no está configurado para procesar encabezados de protocolo PROXY, las solicitudes web pueden tener un formato incorrecto. Si las solicitudes tienen formato incorrecto, el servidor no puede interpretarlas.
El ID de conexión de Private Service Connect (pscConnectionId) está
codificado en el encabezado del protocolo PROXY en formato Type-Length-Value (TLV).
| Campo | Longitud del campo | Valor del campo |
|---|---|---|
| Tipo | 1 byte | 0xE0 (PP2_TYPE_GCP)
|
| Longitud | 2 bytes | 0x8 (8 bytes) |
| Valor | 8 bytes | El pscConnectionId de 8 bytes en orden de red |
Puedes ver el pscConnectionId de 8 bytes de la regla de reenvío
del consumidor o
el adjunto de servicio
del productor.
El valor pscConnectionId es único a nivel global para todas las conexiones activas en un
momento determinado. Sin embargo, con el tiempo, un pscConnectionId podría volver a usarse en
estas situaciones:
Dentro de una red de VPC determinada, si borras un extremo (regla de reenvío) y creas un extremo nuevo con la misma dirección IP, se podría usar el mismo
pscConnectionId.Si borras una red de VPC que contiene extremos (reglas de reenvío), después de un período de espera de siete días, el valor
pscConnectionIdque se usó para esos extremos podría usarse para un extremo diferente en otra red de VPC.
Puedes usar valores pscConnectionId para depurar y realizar un seguimiento de las fuentes de
los paquetes.
Hay un ID de 16 bytes independiente de adjunto de servicio de Private Service Connect
(pscServiceAttachmentId) disponible en el adjunto de servicio
del productor.
El valor pscServiceAttachmentId es un ID único a nivel global que identifica un
adjunto de servicio de Private Service Connect. Puedes usar el
valor pscServiceAttachmentId para obtener visibilidad y depurar. Este valor no se
incluye en el encabezado del protocolo PROXY.
Precios
Los precios de Private Service Connect se describen en la página de precios de VPC.
Cuotas
La cantidad total de extremos de Private Service Connect y de conexiones propagadas, de cualquier consumidor, que pueden acceder a tu la red de VPC de productor es controlada por la cuota de PSC ILB consumer forwarding rules per producer VPC network.
Los extremos contribuyen a esta cuota hasta que se borran, incluso si el adjunto de servicio asociado se borra o se configura para rechazar la conexión. Las conexiones propagadas contribuyen a esta cuota hasta que se borra el extremo asociado, incluso si la propagación de conexiones está inhabilitada en el concentrador de Network Connectivity Center o se borra el radio de conexiones propagadas.
Acceso local
Los servicios de Private Service Connect están disponibles mediante extremos. Se puede acceder a estos extremos desde hosts locales conectados compatibles. Para obtener más información, consulta Accede al extremo desde hosts locales.
Limitaciones
Los servicios publicados tienen las siguientes limitaciones:
- No se admiten los balanceadores de cargas configurados con
varios protocolos (el protocolo se establece en
L3_DEFAULT). - Duplicación de paquetes no puede duplicar paquetes para el tráfico de servicios publicados de Private Service Connect.
- Debes usar Google Cloud CLI o la API a fin de crear un adjunto de servicio que apunte a una regla de reenvío que se usa para el reenvío de protocolos internos.
Para obtener información sobre problemas y soluciones alternativas, consulta Problemas conocidos.