Acerca de los servicios publicados
En este documento se ofrece una descripción general de cómo usar 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 varias subredes dedicadas. A continuación, crea un archivo adjunto de servicio que haga referencia a esas subredes. El adjunto de servicio puede tener diferentes preferencias de conexión.
Tipos de consumidores de servicios
Hay dos tipos de consumidores que pueden conectarse a un servicio de Private Service Connect:
Los endpoints se basan en una regla de reenvío.
Un punto final permite que los consumidores de servicios envíen tráfico desde su red de VPC a los servicios de la red de VPC del productor de servicios (haz clic para ampliar).
Los backends se basan en un balanceador de carga.
Un backend que usa un balanceador de carga de aplicaciones externo global permite que los consumidores de servicios con acceso a Internet envíen tráfico a los servicios de la red de VPC del productor de servicios (haz clic para ampliar).
Subredes de NAT
Los adjuntos de servicio de Private Service Connect se configuran con una o varias subredes NAT (también denominadas subredes de Private Service Connect). Los paquetes de la red de VPC del consumidor se traducen mediante la NAT de origen (SNAT) para que sus direcciones IP de origen originales se conviertan en direcciones IP de origen de la subred de NAT de la red de VPC del productor.
Los adjuntos de servicio pueden tener varias subredes NAT. Se pueden añadir subredes NAT adicionales al adjunto de servicio en cualquier momento sin interrumpir el tráfico.
Aunque una vinculación de servicio puede tener configuradas varias subredes NAT, una subred NAT no se puede usar en más de una vinculación de servicio.
Las subredes NAT de Private Service Connect no se pueden usar para recursos como instancias de máquina virtual o reglas de reenvío. Las subredes solo se usan para proporcionar direcciones IP para SNAT de las conexiones de consumidores entrantes.
Tamaño de la subred de NAT
El tamaño de la subred determina cuántos consumidores pueden conectarse a tu servicio. Si se consumen todas las direcciones IP de la subred NAT, se producirá un error en cualquier conexión adicional de Private Service Connect. Ten en cuenta lo siguiente:
Se consume una dirección IP de la subred NAT por cada punto final o backend que esté conectado al adjunto de servicio.
El número de conexiones TCP o UDP, clientes o redes de VPC de consumidor no afecta al consumo de direcciones IP de la subred NAT.
Si los consumidores usan la propagación de conexiones, se consumirá una dirección IP adicional por cada VPC de radio a la que se propaguen las conexiones y por cada endpoint.
Puedes controlar cuántas conexiones propagadas se crean configurando el límite de conexiones propagadas.
Cuando calcules cuántas direcciones IP necesitas para los puntos finales y los backends, ten en cuenta los servicios multiinquilino o los consumidores que usen el acceso multipunto para Private Service Connect.
Monitorización de subredes NAT
Para asegurarte de que las conexiones de Private Service Connect no fallen debido a que no hay direcciones IP disponibles en una subred NAT, te recomendamos que hagas lo siguiente:
- Monitoriza la
private_service_connect/producer/used_nat_ip_addressesmétrica de adjunto de servicio. Asegúrate de que el número de direcciones IP de NAT utilizadas no supere la capacidad de las subredes de NAT de un adjunto de servicio. - Monitoriza el estado de la conexión de las conexiones de adjuntos de servicio. Si una conexión tiene el estado Necesita atención, es posible que no haya más direcciones IP disponibles en las subredes NAT del archivo adjunto.
- En el caso de los servicios multiempresa, puedes usar los límites de conexión para asegurarte de que un solo consumidor no agote la capacidad de las subredes NAT de un adjunto de servicio.
Si es necesario, se pueden añadir subredes NAT al adjunto de servicio en cualquier momento sin interrumpir el tráfico.
Especificaciones de NAT
Ten en cuenta las siguientes características de NAT de Private Service Connect al diseñar el servicio que vas a publicar:
El tiempo de espera inactivo de la asignación UDP es de 30 segundos y no se puede configurar.
El tiempo de espera de inactividad de la conexión TCP establecida es de 20 minutos y no se puede configurar.
Para evitar que se agote el tiempo de espera de las conexiones de los clientes, haz una de las siguientes acciones:
Asegúrate de que todas las conexiones duren menos de 20 minutos.
Asegúrese de que se envía tráfico con una frecuencia superior a una vez cada 20 minutos. Puedes usar un latido o un keepalive en tu aplicación, o keepalives de TCP. Por ejemplo, puedes configurar un keepalive en el proxy de destino de un balanceador de carga de aplicaciones interno regional o de un balanceador de carga de red con proxy interno regional.
El tiempo de espera de conexión inactiva transitoria de TCP es de 30 segundos y no se puede configurar.
Hay un retraso de dos minutos antes de que se pueda reutilizar cualquier quíntupla (dirección IP de origen y puerto de origen de la subred NAT, además del protocolo, la dirección IP y el puerto de destino).
SNAT para Private Service Connect no admite fragmentos de IP.
Número máximo de conexiones
Una sola VM de productor puede aceptar un máximo de 64.512 conexiones TCP simultáneas y 64.512 conexiones UDP de un solo consumidor de Private Service Connect (endpoint o backend). No hay límite en el número total de conexiones TCP y UDP que puede recibir un endpoint de Private Service Connect en conjunto en todos los back-ends del productor. Las VMs cliente pueden usar los 65.536 puertos de origen al iniciar conexiones TCP o UDP con un punto final de Private Service Connect. Toda la traducción de direcciones de red se realiza de forma local en el host del productor, lo que no requiere un grupo de puertos NAT asignado de forma centralizada.
Vinculaciones de servicio
Los productores de servicios exponen sus servicios a través de una vinculación de servicio.
- Para exponer un servicio, un productor de servicios crea una vinculación de servicio que hace referencia a un servicio de destino. El servicio de destino puede ser uno de los siguientes:
- Regla de reenvío de un balanceador de carga
- Una instancia de proxy web seguro
El URI de la vinculación de servicio tiene este formato:
projects/SERVICE_PROJECT/regions/REGION/serviceAttachments/SERVICE_NAME
Puedes asociar una vinculación de servicio a un único servicio de destino. No puedes asociar varios adjuntos de servicio a un servicio de destino concreto.
Preferencias de conexión
Cada adjunto de servicio tiene una preferencia de conexión que especifica si las solicitudes de conexión se aceptan automáticamente. Hay tres opciones posibles:
- Aceptar todas las conexiones automáticamente. El adjunto de servicio acepta automáticamente todas las solicitudes de conexión entrantes de cualquier consumidor. Una política de la organización puede anular la aceptación automática y bloquear las conexiones entrantes.
- Aceptar conexiones de las redes seleccionadas. La vinculación de servicio solo acepta solicitudes de conexión entrantes si la red de VPC del consumidor está en la lista de consumidores aceptados de la vinculación de servicio.
- Aceptar las conexiones de los proyectos seleccionados. El adjunto de servicio solo acepta solicitudes de conexión entrantes si el proyecto de consumidor está en la lista de consumidores aceptados del adjunto de servicio.
Te recomendamos que aceptes las conexiones de los proyectos o las redes seleccionados. Aceptar automáticamente todas las conexiones puede ser adecuado si controlas el acceso de los consumidores por otros medios y quieres habilitar el acceso permisivo a tu servicio.
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 la conexión.
Listas de aceptación y rechazo de consumidores
Las listas de aceptación de consumidores y las listas de rechazo de consumidores son una función de seguridad de los archivos adjuntos de los servicios. Las listas de aceptación y rechazo permiten a los productores de servicios especificar qué consumidores pueden establecer conexiones de Private Service Connect con sus servicios. Las listas de aceptación de consumidores especifican si se acepta una conexión, y las listas de rechazo de consumidores especifican si se rechaza una conexión. Ambas listas te permiten especificar consumidores por la red de VPC o el proyecto del recurso de conexión. Si añades un proyecto o una red a la lista de permitidos y a la de denegados, se rechazarán las solicitudes de conexión de ese proyecto o red. No se admite la especificación de consumidores por carpeta.
Las listas de aceptación y de rechazo de consumidores te permiten especificar proyectos o redes VPC, pero no ambos al mismo tiempo. Puedes cambiar una lista de un tipo a otro sin interrumpir las conexiones, pero debes hacer el cambio en una sola actualización. De lo contrario, algunas conexiones podrían cambiar temporalmente al estado pendiente.
Las listas de consumidores controlan si un punto final puede conectarse a un servicio publicado, pero no controlan quién puede enviar solicitudes a ese punto final. Por ejemplo, supongamos que un consumidor tiene una red de VPC compartida a la que tiene asociados dos proyectos de servicio. Si un servicio publicado tiene service-project1 en la lista de aceptación de consumidores y service-project2 en la lista de rechazo de consumidores, se aplican las siguientes condiciones:
-
Un consumidor de
service-project1puede crear un punto final que se conecte al servicio publicado. -
Un consumidor de
service-project2no puede crear un punto final que se conecte al servicio publicado. -
Un cliente de
service-project2puede enviar solicitudes al endpoint deservice-project1si no hay reglas ni políticas de cortafuegos que impidan ese tráfico.
Para obtener información sobre cómo interactúan las listas de aceptación de consumidores con las políticas de la organización, consulta el artículo Interacción entre las listas de aceptación de consumidores y las políticas de la organización.
Límites de listas de aceptación de consumidores
Las listas de aceptación de consumidores tienen límites de conexión. Estos límites definen el número total de conexiones de backend y de punto final de Private Service Connect que una vinculación de servicio puede aceptar del proyecto o la red de VPC del consumidor especificados.
Los productores pueden usar límites de conexión para evitar que los consumidores individuales agoten las direcciones IP o las cuotas de recursos en la red de VPC del productor. Cada conexión de Private Service Connect aceptada se resta del límite configurado para un proyecto o una red de VPC de consumidor. Los límites se definen al crear o actualizar listas de aceptación de consumidores. Puedes ver las conexiones de un archivo adjunto de servicio cuando describes un archivo adjunto de servicio.
Las conexiones propagadas no se tienen en cuenta para estos límites.
Por ejemplo, supongamos que un adjunto de servicio tiene una lista de aceptación de consumidores que incluye project-1 y project-2, ambos con un límite de una conexión. El proyecto project-1 solicita dos conexiones, project-2 solicita una conexión y project-3 solicita una conexión. Como project-1 tiene un límite de una conexión, la primera se acepta y la segunda se queda pendiente.
Se acepta la conexión de project-2 y la de project-3 sigue pendiente. La segunda conexión de project-1 se puede aceptar aumentando el límite de project-1. Si se añade project-3 a la lista de aceptación del consumidor, esa conexión pasa de pendiente a aceptada.
Reconciliación de conexiones
La conciliación de conexiones determina si las actualizaciones de las listas de aceptación o rechazo de un adjunto de servicio pueden afectar a las conexiones de Private Service Connect. Si la conciliación de conexiones está habilitada, al actualizar las listas de aceptación o rechazo se pueden finalizar las conexiones existentes. Las conexiones que se hayan rechazado previamente se pueden aceptar. Si la conciliación de conexiones está inhabilitada, al actualizar las listas de aceptación o rechazo solo se verán afectadas las conexiones nuevas y pendientes.
Por ejemplo, supongamos que tienes un adjunto de servicio con varias conexiones aceptadas de Project-A. Project-A está en la lista de
aceptación del adjunto de servicio. El archivo adjunto de servicio se actualiza quitando Project-A de la lista de aceptados.
Si la conciliación de conexiones está habilitada, todas las conexiones existentes de Project-A pasarán a PENDING, lo que finalizará la conectividad de red entre las dos redes VPC y detendrá inmediatamente el tráfico de red.
Si la conciliación de conexiones está inhabilitada, las conexiones de Project-A no se verán afectadas. El tráfico de red puede seguir fluyendo a través de las conexiones de Private Service Connect. Sin embargo, no se permiten las nuevas conexiones de Private Service Connect.
Para obtener información sobre cómo configurar la conciliación de conexiones para los nuevos elementos adjuntos de servicio, consulta Publicar un servicio con aprobación explícita.
Para obtener información sobre cómo configurar la conciliación de conexiones para los elementos ServiceAttachment, consulta Configurar la conciliación de conexiones.
Conexiones propagadas
Los consumidores que se conecten a tu vinculación de servicio mediante puntos finales pueden habilitar la propagación de conexiones. Las conexiones propagadas permiten que las cargas de trabajo de las VPC de consumidor accedan a los servicios gestionados de las redes de VPC de productor como si las dos redes de VPC estuvieran conectadas directamente a través de puntos finales. Cada conexión propagada consume una dirección IP de la subred NAT del adjunto de servicio.
Puedes ver el número de conexiones propagadas asociadas a un punto final conectado cuando consultas los detalles de un servicio publicado. Este recuento no incluye las conexiones propagadas que están bloqueadas por el límite de conexiones propagadas del productor.
Límite de conexiones propagado
Los adjuntos de servicio tienen un límite de conexiones propagadas, lo que permite a los productores de servicios limitar el número de conexiones propagadas que se pueden establecer con el adjunto de servicio desde un solo consumidor. Si no se especifica, el límite de conexiones propagadas predeterminado es 250.
- Si la preferencia de conexión del adjunto de servicio es
ACCEPT_MANUAL, el límite se aplica a cada proyecto o red de VPC que se incluya en la lista de consumidores aceptados. - Si la preferencia de conexión es
ACCEPT_AUTOMATIC, el límite se aplica a cada proyecto que contenga un endpoint conectado.
Si un consumidor supera el límite de conexiones propagadas, no se crearán más conexiones propagadas. Para permitir la creación de más endpoints propagados, puedes aumentar el límite de conexiones propagadas. Cuando aumentas este límite, Network Connectivity Center crea conexiones propagadas que estaban bloqueadas por el límite, siempre que las nuevas conexiones no superen el límite actualizado. Actualizar este límite no afecta a las conexiones propagadas que ya existan.
Evitar que se agote la cuota
El número total de puntos finales de Private Service Connect y de conexiones propagadas, de cualquier consumidor, que pueden acceder a tu red de VPC de productor se controla mediante la cuota PSC ILB consumer forwarding rules per producer VPC network.
En el caso de los servicios multiinquilino, es importante protegerse contra el agotamiento de esta cuota.
Puedes usar los siguientes límites para evitar que se agoten las cuotas:
- Los límites de conexión de la lista de aceptación de consumidores controlan el número total de puntos finales de Private Service Connect que pueden crear conexiones a una vinculación de servicio desde una sola red de VPC o proyecto de consumidor. Reducir estos límites no afecta a las conexiones actuales. Estos límites no se aplican a las conexiones propagadas.
- Los límites de conexión propagados controlan el número total de conexiones propagadas que se pueden establecer a un adjunto de servicio desde un solo consumidor. Reducir este límite no afecta a las conexiones propagadas.
Ejemplo
En el siguiente ejemplo se muestra cómo funcionan los límites de conexión propagados y los límites de la lista de elementos aceptados del consumidor en relación con la cuota de PSC ILB consumer forwarding rules per producer VPC network.
Supongamos que un consumidor ha creado dos endpoints en una red de VPC de radio, spoke-vpc-1. Ambos endpoints se conectan a service-attachment-1 en producer-vpc-1. El radio está conectado a un eje de Network Connectivity Center que tiene habilitada la propagación de la conexión y no hay ningún otro radio conectado a ese eje.
El productor de servicios ha configurado service-attachment-1 para que cada proyecto de la lista de aceptados tenga un límite de cuatro consumidores. El productor ha configurado un límite de conexiones propagadas de dos, lo que significa que un proyecto puede tener hasta dos conexiones propagadas.
Esta configuración de ejemplo contiene dos endpoints y ninguna conexión propagada (haga clic para ampliar).
El uso de cuotas y límites de esta configuración es el siguiente:
| Cuota o límite | Uso | Explicación |
|---|---|---|
| Reglas de reenvío de ILB de PSC de consumidor por red de VPC de productor | 2 | una por endpoint |
Límite de conexiones de la lista de aceptación de consumidores de la vinculación de servicio para consumer-project-1 |
2 | una por endpoint |
Límite de conexiones propagadas de la vinculación de servicio de consumer-project-1 |
0 | no se propagan las conexiones |
Supongamos que consumer-project-1 conecta otro spoke llamado spoke-vpc-2 al mismo eje de Network Connectivity Center que spoke-vpc-1. De esta forma, se crean dos conexiones propagadas en consumer-project-1, una para cada endpoint.
Esta configuración de ejemplo contiene dos endpoints y dos conexiones propagadas (haz clic para ampliar).
El uso de cuotas y límites de esta configuración es el siguiente:
| Cuota o límite | Uso | Explicación |
|---|---|---|
| Reglas de reenvío de ILB de PSC de consumidor por red de VPC de productor | 4 | una por cada endpoint y otra por cada conexión propagada |
Límite de conexiones de la lista de aceptación de consumidores de la vinculación de servicio para consumer-project-1 |
2 | una por endpoint |
Límite de conexiones propagadas de la vinculación de servicio de consumer-project-1 |
2 | una por cada conexión propagada |
Consumer-project-1 ha alcanzado el límite de conexiones propagadas. Si el consumidor añade otra VPC de radio, Private Service Connect no crea ninguna conexión propagada nueva.
Supongamos que otro consumidor tiene dos VPC de radio en consumer-project-2. Los radios se conectan a un hub de Network Connectivity Center con las conexiones propagadas habilitadas. Una de las VPCs de radio contiene un único endpoint que se conecta a service-attachment-1.
Esta configuración de ejemplo contiene tres endpoints y tres conexiones propagadas (haz clic en la imagen para ampliarla).
El uso de cuotas y límites de esta configuración es el siguiente:
| Cuota o límite | Uso | Explicación |
|---|---|---|
| Reglas de reenvío de ILB de PSC de consumidor por red de VPC de productor | 6 | cuatro de consumer-project-1 y dos de consumer-project-2 |
Límite de conexiones de la lista de aceptación de consumidores de la vinculación de servicio para consumer-project-1 |
2 | una por punto final en consumer-project-1 |
Límite de conexiones de la lista de aceptación de consumidores de la vinculación de servicio para consumer-project-2 |
1 | una por punto final en consumer-project-2 |
Límite de conexiones propagadas de la vinculación de servicio de consumer-project-1 |
2 | una por cada conexión propagada en consumer-project-1 |
Límite de conexiones propagadas de la vinculación de servicio de consumer-project-2 |
1 | una por cada conexión propagada en consumer-project-2 |
Configuración de DNS
Para obtener información sobre la configuración de DNS de los servicios y los endpoints publicados que se conectan a servicios publicados, consulta Configuración de DNS de los servicios.
Configuración de varias regiones
Puedes hacer que un servicio esté disponible en varias regiones creando 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 carga que admita el acceso mediante un backend.
Crea un archivo adjunto de servicio para publicar cada instancia regional del servicio.
Configuración del consumidor:
Crea un backend para acceder a los servicios publicados. El backend se basa en un balanceador de carga de aplicación externo global e incluye las siguientes configuraciones:
Un NEG de Private Service Connect en cada región que apunta a la vinculación de servicio de esa región.
Un servicio de backend que contiene los backends de NEG.
En esta configuración, el endpoint enruta el tráfico mediante la política de balanceo de carga global predeterminada: primero por estado y, después, por la ubicación más cercana al cliente.
Si usas un balanceador de carga de aplicaciones externo global, los consumidores de servicios con acceso a Internet pueden enviar tráfico a los servicios de la red de VPC del productor de servicios. Como el servicio se ha desplegado en varias regiones, el balanceador de carga puede enrutar el tráfico a una NEG de la región más cercana que esté en buen estado (haga clic para ampliar).
Traducción de la versión de IP
En el caso de los puntos finales de Private Service Connect que se conectan a servicios publicados (vinculaciones 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 punto final y del tráfico que sale de él. La dirección IP puede proceder de una subred solo IPv4, solo IPv6 o de pila dual. La versión de IP del endpoint 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 mediante 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 doble pila. Si la subred NAT es una subred de doble pila, se usa el intervalo de direcciones IPv4 o IPv6, pero no ambos.
Private Service Connect no admite la conexión de un punto final IPv4 con una vinculación de servicio IPv6. En este caso, la creación del endpoint falla y se muestra el siguiente mensaje de error:
Private Service Connect forwarding rule with an IPv4 address
cannot target an IPv6 service attachment.
Estas son las combinaciones posibles para las configuraciones compatibles:
- Punto final IPv4 a adjunto de servicio IPv4
- Punto final IPv6 a adjunto de servicio IPv6
-
Punto final IPv6 a un adjunto de servicio IPv4
En esta configuración, Private Service Connect traduce automáticamente entre las dos versiones de IP.
En las conexiones entre los backends de Private Service Connect y las vinculaciones de servicio, las reglas de reenvío del consumidor y del productor deben usar IPv4.
Funciones y compatibilidad
En las siguientes tablas, el símbolo indica que una función está disponible, y la ausencia de símbolo indica que no lo está.
En función del balanceador de carga de productor que se elija, el servicio de productor puede admitir el acceso mediante endpoints, backends o ambos.
Compatibilidad con endpoints
En esta sección se resumen las opciones de configuración disponibles para consumidores y productores al usar endpoints para acceder a servicios publicados.
Configuración de consumidor
En esta tabla se resumen las opciones de configuración y las funciones admitidas de los endpoints que acceden a servicios publicados en función del tipo de productor de destino.
Configuración del productor
En esta tabla se resumen las opciones de configuración y las funciones admitidas de los servicios publicados a los que acceden los endpoints.
| Tipo de productor | Configuración del productor (servicio publicado) | |||
|---|---|---|---|---|
| Back-ends de productores admitidos | Protocolo PROXY (solo tráfico TCP) | Versión de IP | ||
| Balanceador de carga de aplicación interno entre regiones (vista previa) |
|
|
||
| Balanceador de carga de red de paso a través interno |
|
|
||
| Reenvío de protocolos interno (instancia de destino) |
|
|
||
| Servicios de asignación de puertos |
|
|
||
| Balanceador de carga de aplicación interno regional |
|
|
||
| Balanceador de carga de red de proxy interno regional |
|
|
||
| Proxy web seguro |
|
|
||
Los distintos balanceadores de carga admiten diferentes configuraciones de puertos. Algunos admiten un solo puerto, otros admiten un intervalo de puertos y otros admiten todos los puertos. Para obtener más información, consulta las especificaciones de los puertos.
Compatibilidad con back-ends
Un backend de Private Service Connect para servicios publicados requiere dos balanceadores de carga: un balanceador de carga de consumidor y un balanceador de carga de productor. En esta sección se resumen las opciones de configuración disponibles para los consumidores y productores al usar back-ends para acceder a los servicios publicados.
Configuración de consumidor
En esta tabla se describen los balanceadores de carga de consumidor que admiten los backends de Private Service Connect para los servicios publicados, así como los protocolos de servicio de backend que se pueden usar con cada balanceador de carga de consumidor. Los balanceadores de carga de consumidor pueden acceder a los servicios publicados que se alojan en balanceadores de carga de productor compatibles.
| Balanceador de carga de consumidor | Protocolos | Versión de IP |
|---|---|---|
|
IPv4 | |
|
IPv4 | |
|
Balanceador de carga de aplicación externo global (admite varias regiones) Nota: No se admite el balanceador de carga de aplicaciones clásico. |
|
IPv4 |
|
Balanceador de carga de red con proxy externo global Para asociar este balanceador de carga a un NEG de Private Service Connect, usa la CLI de Google Cloud o envía una solicitud de API. Nota: No se admite el balanceador de carga de red de proxy clásico. |
|
IPv4 |
|
IPv4 | |
|
IPv4 | |
|
IPv4 | |
|
IPv4 |
Configuración del productor
En esta tabla se describe la configuración de los balanceadores de carga de productores que admiten los backends de Private Service Connect para los servicios publicados.
| Tipo de productor | Configuración del productor (servicio publicado) | ||||
|---|---|---|---|---|---|
| Back-ends de productores admitidos | Protocolos de reglas de reenvío | Puertos de reglas de reenvío | Protocolo PROXY | Versión de IP | |
| Balanceador de carga de aplicación interno entre regiones (vista previa) |
|
|
Admite uno, varios o todos los puertos | IPv4 | |
| Balanceador de carga de red de paso a través interno |
|
|
Consulta Configuración de puertos de productores. | IPv4 | |
| Balanceador de carga de aplicación interno regional |
|
|
Admite un solo puerto | IPv4 | |
| Balanceador de carga de red de proxy interno regional |
|
|
Admite un solo puerto | IPv4 | |
| Proxy web seguro |
|
|
No aplicable | IPv4 | |
Configuración de puertos de productores
Cuando se publica un balanceador de carga de red de pases interno mediante Private Service Connect, los consumidores que usan backends de Private Service Connect para acceder al servicio deben saber qué puerto usar para comunicarse con el servicio. Ten en cuenta lo siguiente al crear la regla de reenvío del balanceador de carga de red de paso a través interno del productor:
- Te recomendamos que comuniques a los consumidores qué puerto se usa en la regla de reenvío del productor para que puedan especificarlo al crear un NEG.
Si los consumidores no especifican un puerto de productor al crear sus NEGs, el puerto de productor se determina en función de 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 aplican las siguientes condiciones:
- Si se incluye el puerto
443, el backend del consumidor usa el puerto443. - Si no se incluye el puerto
443, el backend del consumidor usará el primer puerto de la lista, después de que se haya ordenado alfabéticamente. Por ejemplo, si especificas el puerto80y el puerto1111, el backend del consumidor usará el puerto1111. Si cambias los puertos que usan los back-ends del productor, es posible que se interrumpa el 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 de consumidor se conecta a este servicio, utiliza el puerto443para comunicarse.Si cambias las VMs de backend para que solo respondan en el puerto
8443, el backend de 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 al crear 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 conecten a recursos de redes de VPC compartida.
La configuración es la misma que la de un adjunto de servicio normal, excepto por lo siguiente:
- La regla de reenvío del balanceador de carga del productor está asociada a 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.
- La vinculación de servicio usa una subred de Private Service Connect de la red de VPC compartida. Esta subred debe compartirse con el proyecto de servicio.
Almacenamiento de registros
Puedes habilitar los registros de flujo de VPC en las subredes que contengan las VMs de backend. Los registros muestran los flujos entre las VMs backend y las direcciones IP de la subred de Private Service Connect.
Controles de Servicio de VPC
Controles de Servicio de VPC y Private Service Connect son compatibles entre sí. Si la red de VPC en la que se ha implementado el punto final de Private Service Connect está en un perímetro de Controles de Servicio de VPC, el punto final forma parte del mismo perímetro. Cualquier servicio compatible con Controles de Servicio de VPC al que se acceda a través del endpoint está sujeto a las políticas de ese perímetro de Controles de Servicio de VPC.
Cuando creas un endpoint, se realizan llamadas a la API del plano de control entre los proyectos de consumidor y productor para establecer una conexión de Private Service Connect. Para establecer una conexión de Private Service Connect entre proyectos de consumidor y productor que no estén en el mismo perímetro de Controles de Servicio de VPC, no es necesario que se autorice explícitamente con políticas de salida. La comunicación con los servicios compatibles con Controles de Servicio de VPC a través del endpoint está protegida por el perímetro de Controles de Servicio de VPC.
Ver la información de conexión de los consumidores
De forma predeterminada, Private Service Connect traduce la dirección IP de origen del consumidor a una dirección de una de las subredes de Private Service Connect de la red de VPC del productor de servicios. Si quieres 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) del encabezado del protocolo PROXY.
El formato de los encabezados del protocolo PROXY depende de la versión de IP del endpoint del consumidor. Si el balanceador de carga de tu adjunto de servicio tiene una dirección IPv6, los consumidores pueden conectarse con direcciones IPv4 e IPv6. Configure su aplicación para recibir y leer encabezados del protocolo PROXY para la versión IP del tráfico que debe recibir.
En el caso del 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 hacen referencia al punto final de Private Service Connect que se propaga.
Cuando habilitas el protocolo PROXY en un adjunto de servicio, el cambio solo se aplica a las conexiones nuevas. Las conexiones ya establecidas no incluyen el encabezado del protocolo PROXY.
Si habilita el protocolo PROXY, consulte la documentación del software del servidor web backend para obtener información sobre cómo analizar y procesar los encabezados del protocolo PROXY entrantes en las cargas útiles TCP de la conexión del cliente. Si el protocolo PROXY está habilitado en el adjunto de servicio, pero el servidor web backend no está configurado para procesar los encabezados del protocolo PROXY, las solicitudes web pueden estar mal formadas. Si las solicitudes tienen un formato incorrecto, el servidor no podrá interpretarlas.
El ID de conexión de Private Service Connect (pscConnectionId) se codifica en el encabezado del protocolo PROXY en formato de tipo, longitud y valor (TLV).
| Campo | Longitud del campo | Valor de campo |
|---|---|---|
| Tipo | 1 byte | 0xE0 (PP2_TYPE_GCP)
|
| Duración | 2 bytes | 0x8 (8 bytes) |
| Valor | 8 bytes | El pscConnectionId de 8 bytes en orden de red |
Puede ver el valor pscConnectionId de 8 bytes en la regla de reenvío del consumidor o en el archivo adjunto del servicio del productor.
El valor pscConnectionId es único a nivel global para todas las conexiones activas en un momento dado. Sin embargo, con el tiempo, es posible que se reutilice un pscConnectionId en los siguientes casos:
En una red de VPC determinada, si eliminas un endpoint (regla de reenvío) y creas otro con la misma dirección IP, es posible que se utilice el mismo valor de
pscConnectionId.Si eliminas una red de VPC que contiene puntos finales (reglas de reenvío), después de un periodo de espera de siete días, el valor
pscConnectionIdque se usó para esos puntos finales se podrá usar para otro punto final de otra red de VPC.
Puede usar los valores de pscConnectionId para depurar y rastrear las fuentes de los paquetes.
El servicio de productor
attachment tiene un ID de vinculación de servicio de Private Service Connect de 16 bytes independiente (pscServiceAttachmentId).
El valor pscServiceAttachmentId es un ID único global que identifica una vinculación de servicio de Private Service Connect. Puedes usar el valor pscServiceAttachmentId para la visibilidad y la depuración. 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
El número total de puntos finales de Private Service Connect y de conexiones propagadas, de cualquier consumidor, que pueden acceder a tu red de VPC de productor se controla mediante la PSC ILB consumer forwarding rules per producer VPC networkcuota.
Los endpoints contribuyen a esta cuota hasta que se eliminan, aunque se elimine el ServiceAttachment asociado o se configure para rechazar la conexión. Las conexiones propagadas contribuyen a esta cuota hasta que se elimina el endpoint asociado, aunque la propagación de conexiones esté inhabilitada en el centro de conectividad de red o se elimine el spoke de la conexión propagada.
Acceso in situ
Los servicios de Private Service Connect se ponen a disposición mediante puntos finales. Se puede acceder a estos endpoints desde hosts locales conectados compatibles. Para obtener más información, consulta Acceder al endpoint desde hosts locales.
Limitaciones
Los servicios publicados tienen las siguientes limitaciones:
- No se admiten los balanceadores de carga configurados con
varios protocolos (protocolo definido como
L3_DEFAULT). - Packet Mirroring no puede replicar paquetes del tráfico de servicios publicados de Private Service Connect.
- Debes usar la CLI de Google Cloud o la API para crear una vinculación de servicio que apunte a una regla de reenvío que se use para el reenvío de protocolo interno.
Para ver los problemas y las soluciones alternativas, consulta la sección Problemas conocidos.