El más detallado de toda la red: análisis en profundidad de la ruta del tráfico de Istio Ambient Mesh

Autor: Shi Zehuan

Prefacio

Istio Ambient Mesh es una nueva arquitectura lanzada por la comunidad Istio que extrae capacidades de Sidecar a ztunnel y waypoint. También implementa reglas de tráfico bajo esta arquitectura basadas en iptables y enrutamiento de políticas. Actualmente, hay algunos materiales en la red que discuten la implementación de Esta parte Hay un cierto grado de análisis (como las tres series de artículos lanzados por Solo.io), pero todavía hay muchos detalles que no se han mencionado en ningún artículo. Este artículo tiene como objetivo proporcionar una explicación detallada de la ruta del tráfico de Istio Ambient Mesh y se esfuerza por presentar los detalles lo más claramente posible para ayudar a los lectores a comprender completamente las partes más críticas de Istio Ambient Mesh. Leer este artículo requiere que los lectores tengan conocimientos básicos del protocolo TCP/IP y de la red del sistema operativo, incluidos iptables y enrutamiento. Debido a limitaciones de espacio, este artículo no presentará estos conceptos básicos en detalle. Para los lectores interesados, se recomienda consultar la información relevante para una comprensión más profunda.

ambiente

Usamos el escenario más simplificado para ilustrar la ruta del tráfico de Ambient Mesh: se inicia una solicitud HTTP a través de curl desde un Pod de suspensión que se ejecuta en el Nodo-A, y el objeto de la solicitud es un servicio llamado httpbin en el clúster. Bajo este servicio, hay un Pod httpbin ubicado en el Nodo B. Dado que el servicio (ClusterIP) es solo una IP virtual en K8 (no es la dirección de ningún dispositivo de red real), en este escenario, la solicitud se envía directamente al Pod de la aplicación httpbin, la ruta de red en este escenario se verá así:

Sin embargo, bajo la influencia de las reglas de tráfico de Ambient Mesh, los paquetes de datos enviados desde el Sleep Pod en realidad deben pasar por una serie de iptables y enrutamiento de políticas y reenviarse a ztunnel o waypoint antes de llegar a la aplicación httpbin en el extremo opuesto. Para facilitar la descripción en las siguientes páginas, primero debemos presentar a todos los participantes en este proceso. Los lectores no necesitan recordar las direcciones ni los nombres de estos dispositivos. Se enumeran aquí solo como referencia:

Ruta de tráfico completa

Aunque la ruta de solicitud de suspensión -> httpbin parece muy simple, en Ambient Mesh, ztunnel se hace cargo de todas las conexiones entrantes y salientes. Los paquetes IP enviados desde el módulo de suspensión serán secuestrados al puerto 15001 de ztunnel, cifrados por ztunnel y luego enviados. Entonces, de hecho, la conexión iniciada por curl ejecutada en el pod de suspensión en realidad está conectada a la pila de protocolos en el Pod ztunnel. De manera similar, la conexión recibida por el Pod httpbin en realidad proviene del ztunnel que se ejecuta en el Nodo donde se encuentra. entonces la conexión real establecida Hay 3 conexiones TCP:

dormir -> NodoA ztunnel
Túnel ztúnel NodoA -> túnel ztúnel NodoB
NodoB ztunnel -> httpbin

Dado que Ambient Mesh es un diseño transparente de 4 capas, aunque es reenviado por ztunnel o proxy de waypoint, ni la aplicación curl en el Pod de suspensión ni la aplicación httpbin en el pod de httpbin pueden percibir la existencia del proxy intermedio. Para lograr este objetivo, los paquetes de datos no se pueden reenviar directamente a través de DNAT y SNAT en muchos aspectos, porque las acciones de DNAT y SNAT modificarán la información de origen/destino del paquete de datos. Estas reglas diseñadas por Ambient Mesh están diseñadas en gran medida para garantizar la transparencia. En ambos extremos de la ruta de transmisión, para explicar cada parte una por una, necesitamos refinar aún más la figura anterior:

Interpretemos esta imagen. El autor divide el camino completo en tres partes. La primera parte es curl a ztunnelA, representada por una línea roja; la segunda parte es de ztunnelA a ztunnelB, representada por una línea azul; la tercera parte es ztunnelB a httpbin, representado por una línea amarilla. Además, existen dos tipos de líneas, una línea sin flechas en ambos extremos indica que estos dispositivos están conectados directamente, es decir, si el paquete de datos entra por un extremo, saldrá por el otro extremo. de los dos dispositivos host eth0 Es diferente del método de conexión entre el Pod y el host, pero este no es el enfoque de este artículo. También podemos considerarlo como una conexión directa. El enfoque de este artículo será explicar el Conexión con flechas y analice las tres partes de la ruta separadas arriba una por una. , Aclare cómo se reenvía el paquete de datos en esta parte de la ruta.

Parte 1: curl a ztunnel-A

Cuando ejecutamos curl para enviar una solicitud, curl inicia una conexión al servicio httpbin. Después de la resolución DNS, nuestro destino de conexión es el ClusterIP (no Pod) del servicio httpbin. En el clúster K8s, el paquete de datos enviado a la IP del clúster Será una serie de reglas de iptables que convierten la dirección de destino en un PodIP y luego la envían a través del host. Sin embargo, en Ambient Mesh, debe ser cifrada por ztunnel antes de enviarla. En esta sección, primero tomaremos una Observe cómo se enruta el paquete de datos al ztunnel Pod del proceso ztunnel.

1）Dormir NS -> Nodo-A NS

Dado que solo hay un dispositivo de red eth0 en el Pod de suspensión, es un extremo del par veth del pod en el espacio de nombres de la red del pod, y su extremo opuesto es el dispositivo vethbda3de4b en el espacio de nombres de la red del host. El pod se comunica con todas las redes externas. ya sea arriba o abajo.Todas las líneas se envían y reciben a través de este canal. En el modo Sidecar, para redirigir el tráfico a Sidecar, hay una serie de reglas de iptables en el espacio de nombres de la red del pod. Sin embargo, en el modo Ambient, dado que Sidecar ya no se inyecta en el Pod, ya no hay reglas de iptables en el Espacio de nombres de red del Pod, por lo que la ruta del tráfico en esta etapa es la misma que la de un pod K8 general. Los paquetes de datos enviados desde la pila de protocolos de red del Pod se enviarán a través del único dispositivo de red del Pod, eth0, y luego llegarán al espacio de nombres de red del host desde el quinto dispositivo en el lado del host.

2）Nodo-A NS -> ztunnelA NS

Primer paquete de datos de enlace ascendente

Una vez que el paquete de datos llega al host, es necesario redirigirlo al ztunnel. Sin embargo, el primer paquete de datos en esta ruta (paquete de protocolo de enlace TCP) se reenviará al ztunnel a través de una ruta diferente a la de los paquetes de datos posteriores. Comencemos con el primer paquete de datos. El paquete comienza. Dado que el objeto de conexión iniciado por curl en el módulo de suspensión es el servicio httpbin, después de la resolución DNS, el objetivo de conexión real es el ClusterIP del servicio httpbin, por lo que la dirección de origen y la dirección de destino del paquete de datos de tres capas enviado por La pila de protocolos del módulo de suspensión será similar a esta:

K8s configura reglas de iptables para el enrutamiento de servicios para establecer la dirección de servicio DNAT en una dirección de punto final específica. Para omitir esta lógica y redirigir el paquete de datos a ztunnel, Ambient Mesh CNI agrega algunas reglas de iptables para el host antes de las reglas de K8s. . Después de que el paquete de datos llega al host desde el veth del módulo de suspensión, la cadena PREROUTING comienza a ejecutarse. Echemos un vistazo al contenido de la cadena PREROUTING:

=== PREROUTING ===
    --- raw ---
    --- mangle ---
        -A PREROUTING -j ztunnel-PREROUTING
    --- nat ---
        -A PREROUTING -j ztunnel-PREROUTING
        -A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
        -A PREROUTING -d 172.18.0.1/32 -j DOCKER_OUTPUT

Se puede ver que Istio Ambient Mesh ha agregado reglas a la tabla mangle y a la tabla nat para forzar el salto a la cadena ztunnel-PREROUTING para su procesamiento. Dado que salta incondicionalmente a la cadena ztunnel-PREROUTING, los paquetes de datos enviados por el no- Ambient Mesh Pod también se procesará. Saltará a esta cadena para su procesamiento. Para evitar redirigir incorrectamente el tráfico de Pods fuera de la red a ztunnel, cuando se inicie el Pod, el CNI de Ambient Mesh lo juzgará. Si el juicio El resultado es que Ambient está habilitado, esta será la IP del Pod que se agrega al ipset llamado ztunnel-pods-ips en el espacio de nombres de la red del host. En el escenario de este artículo, el Pod de suspensión se agregará al ipset llamado ztunnel-pods-ips en el Nodo A, por lo que los paquetes del Pod de suspensión cumplirán las siguientes reglas en la cadena ztunnel-PREROUTING: (Las reglas omiten las reglas relacionadas con el contenido irrelevante de la etapa actual):

=== ztunnel-PREROUTING ===
    --- raw ---
    --- mangle ---
        ......
        -A ztunnel-PREROUTING -p tcp -m set --match-set ztunnel-pods-ips src -j MARK --set-xmark 0x100/0x100
    --- nat ---
        -A ztunnel-PREROUTING -m mark --mark 0x100/0x100 -j ACCEPT
    --- filter ---

Durante la etapa de ejecución de la tabla de mangle, dado que la dirección de origen (dirección del Pod de suspensión) del paquete de datos está dentro de ztunnel-pods-ips, esta regla coincide exitosamente y el paquete de datos se marcará con 0x100. Posteriormente, la etapa de la tabla nat se acepta directamente, lo que permite que el paquete de datos omita el procesamiento de las reglas de iptables de K8. Hasta ahora, las reglas solo marcan el paquete de datos y la dirección de destino del paquete de datos no ha cambiado. Para cambiar el enrutamiento del paquete de datos, debe usar la tabla de enrutamiento. Después de que finalice PREROUTING, el paquete de datos ingresará a la etapa de enrutamiento. Dado que el paquete de datos está marcado con 0x100, en la etapa de enrutamiento de política, se cumplirán las siguientes reglas (se omiten las reglas irrelevantes):

......
101:    from all fwmark 0x100/0x100 lookup 101
......

Después de alcanzar esta regla de enrutamiento de política, para este paquete se utilizará la tabla de enrutamiento 101. Echemos un vistazo al contenido de la tabla de enrutamiento 101:

default via 192.168.127.2 dev istioout 
10.244.2.3 dev veth51e3b96d scope link

Dado que la dirección de destino del paquete de datos es la IP del clúster del servicio httpbin, en el entorno de demostración utilizado en este artículo, la IP del clúster del servicio httpbin es 10.96.0.105, por lo que se aplicará la regla predeterminada en esta tabla de enrutamiento. El significado de esta regla es: a través del dispositivo istioout envía a la puerta de enlace 192.168.127.2. El dispositivo istioout es un dispositivo puente, y el otro extremo es el dispositivo pistioout en el ztunnel Pod, y su dirección es 192.168.127.2. Después de que el paquete de datos aplica esta regla de enrutamiento, saldrá del host a través del dispositivo istioout y luego llegue al ztunnel Pod desde el espacio de nombres de la red pistioout.

Después de que el paquete de datos llega al espacio de nombres de red de ztunnel Pod a través de pistioout, dado que la dirección de destino del paquete de datos no es ningún dispositivo de red en ztunnel Pod, la pila de protocolos de ztunnel Pod descartará el paquete de datos sin ninguna intervención. El agente saliente del proceso ztunnel escucha en el puerto 15001. Para entregar correctamente el paquete de datos a este puerto, también se configuran algunas reglas de iptables y reglas de enrutamiento en el ztunnel Pod. Una vez que el paquete de datos llega al espacio de nombres de la red del ztunnel Pod, cumplirá las siguientes reglas:

=== PREROUTING ===
    --- raw ---
    --- mangle ---
        ......
        -A PREROUTING -i pistioout -p tcp -j TPROXY --on-port 15001 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff
        ......
    --- nat ---
    --- filter ---

Esta regla redirige la dirección de destino del paquete de datos que ingresa desde el dispositivo pistioout al puerto 15001 de 127.0.0.1 y etiqueta el paquete de datos con 0x400. Cabe señalar que aunque la dirección de destino se redirige aquí, tproxy la retendrá. La dirección de destino original del paquete de datos. La aplicación puede obtener la dirección de destino original del paquete de datos a través de la opción SO_ORIGINAL_DST de getsockopt. Después de ejecutar las reglas de iptables, se ejecutará el enrutamiento de políticas y el paquete de datos alcanzará las siguientes reglas de enrutamiento de políticas:

20000:  from all fwmark 0x400/0xfff lookup 100

Esta política de enrutamiento especifica el uso de la tabla de enrutamiento 100 para el enrutamiento. Echemos un vistazo al contenido de la tabla de enrutamiento 100:

local default dev lo scope host

100 La tabla de enrutamiento tiene solo una regla, que se envía a la pila de protocolos local a través del dispositivo lo. En este punto, el paquete de datos ingresa a la pila de protocolos local del Pod ztunnel. Dado que el paquete de datos se redirige a 127.0.0.1:15001 en iptables, finalmente llega el paquete de datos, el puerto 15001 monitoreado por el proceso ztunnel, la ruta desde curl hasta el primer paquete del proceso ztunnel ha sido resuelta:

paquete de datos de enlace descendente

También existen algunas reglas especiales para procesar paquetes de devolución en esta etapa. Cuando el paquete de devolución ingresa al host a través del veth de ztunnel en el host, cumplirá las siguientes reglas:

-A ztunnel-PREROUTING ! -s 10.244.2.3/32 -i veth51e3b96d -j MARK --set-xmark 0x210/0x210
-A ztunnel-PREROUTING -m mark --mark 0x200/0x200 -j RETURN

El significado de esta regla es: si el paquete de datos no proviene de la IP del ztunnel Pod, sino que ingresa al host desde el veth del ztunnel Pod, se marcará con 0x210.

¿Por qué es esta condición? Debido a que ztunnel es en realidad un proxy transparente, es decir, ztunnel actúa como el servicio de destino del extremo opuesto para responder al paquete de datos, por lo que la dirección de origen en el paquete de datos es la dirección del servicio del extremo opuesto, no la dirección del ztunnel Pod.

Posteriormente, dado que el paquete de datos está marcado con 0x210, alcanzará las siguientes reglas de enrutamiento de políticas en el host durante la fase de enrutamiento:

100:    from all fwmark 0x200/0x200 goto 32766
......
32766:  from all lookup main

Esta regla de enrutamiento indica el enrutamiento a través de la tabla de enrutamiento principal. La dirección del paquete de retorno es la dirección del Pod de suspensión, que es 10.244.2.8. Se aplicará la regla agregada por la red K8 en la tabla de enrutamiento principal:

10.244.2.8 dev vethbda3de4b scope host

Esta regla enruta el paquete de datos al dispositivo vethbda3de4b. vethbda3de4b es el dispositivo veth del Sleep Pod en el lado del host. Los paquetes de datos que ingresan a este dispositivo ingresarán al Sleep Pod a través del dispositivo eth0 en el Sleep Pod.

Aún no ha terminado. Una vez determinada la ruta, dado que la dirección de destino del paquete no es la máquina local, la cadena FORWARD de iptables se ejecutará nuevamente. Existen las siguientes reglas en la tabla mangle de la cadena FOWARD:

-A FORWARD -j ztunnel-FORWARD

También salta incondicionalmente a la cadena ztunnel-FORWARD. En la cadena ztunnel-FORWARD, dado que el paquete de datos lleva el identificador 0x210, se cumplirán las siguientes reglas:

-A ztunnel-FORWARD -m mark --mark 0x210/0x210 -j CONNMARK --save-mark --nfmask 0x210 --ctmask 0x210

Esta regla guarda la etiqueta en el paquete de datos en la conexión. Hasta ahora, esta conexión también ha guardado la etiqueta 0x210. Cuando el paquete de datos que pertenece a esta conexión pasa a través del host, la etiqueta de conexión 0x210 se utilizará para hacer coincidir los paquetes posteriores en esta conexión Todos los paquetes.

Paquetes de datos de enlace ascendente posteriores

Dado que el primer paquete de respuesta marcará la conexión con 0x210, los paquetes ascendentes posteriores que ingresen al host desde el Pod veth de suspensión cumplirán las siguientes reglas en la fase de ENRUTAMIENTO PREVIO:

-A ztunnel-PREROUTING ! -i veth51e3b96d -m connmark --mark 0x210/0x210 -j MARK --set-xmark 0x40/0x40

Como puede ver, la marca de conexión coincide a través del módulo de marca de conexión de iptables y luego el paquete se marca con 0x40. El paquete marcado con 0x40 cumplirá las siguientes reglas en la etapa de enrutamiento posterior:

102:    from all fwmark 0x40/0x40 lookup 102

Luego use la tabla de enrutamiento 102 para enrutar:

default via 10.244.2.3 dev veth51e3b96d onlink
10.244.2.3 dev veth51e3b96d scope link

Esta tabla de enrutamiento es una regla creada por Ambient Mesh para enrutar al ztunnel Pod. Dado que la dirección de destino del paquete de datos es el ClusterIP del servicio httpbin, esta etapa alcanzará la regla de enrutamiento predeterminada en la tabla de enrutamiento 102 y la enviará a el ztunnel Pod a través del dispositivo veth51e3b96d. Después de que el paquete de datos ingrese al dispositivo veth51e3b96d, ingresará al espacio de nombres de red ztunnel Pod desde el dispositivo eth0 del ztunnel Pod y cumplirá las siguientes reglas de iptables:

-A PREROUTING ! -d 10.244.2.3/32 -i eth0 -p tcp -j MARK --set-xmark 0x4d3/0xfff

La condición de esta regla es que si la dirección de destino del paquete de datos no es la dirección del Pod ztunnel, ingresa desde el dispositivo eth0 y el protocolo es TCP, el paquete de datos se marcará con una marca 0x4d3. Después de marcar esta marca , el paquete de datos cumplirá las siguientes reglas en la fase de enrutamiento:

20003:  from all fwmark 0x4d3/0xfff lookup 100

Después de alcanzar esta ruta de política, se utilizará la tabla de enrutamiento 100:

local default dev lo scope host

Esta tabla de enrutamiento enruta paquetes al dispositivo lo, forzándolos a ingresar a la pila de protocolos nativos.

Resumir

Resumamos brevemente: en esta etapa desde el Nodo-A hasta ztunnel, el primer paquete de datos sale del host a través de la interfaz istioout y la interfaz pistioout ingresa al Pod ztunnel. Sin embargo, los paquetes de datos posteriores se marcarán como 0x210 porque la conexión está marcada Salga del host a través del dispositivo veth del ztunnel Pod y luego ingrese al ztunnel Pod a través del dispositivo eth0 del ztunnel Pod.

Parte 2: ztunnel-A a ztunnel-B

Una vez que el paquete de datos llegue al ztunnel, se realizará el equilibrio de carga de capa 4. Para esta parte, consulte mi artículo [ 1] . Después del equilibrio de carga de capa 4, ztunnel convierte la IP del servicio de destino en IP del Pod. Debido al diseño de seguridad de confianza cero, ztunnel necesita reenviar los datos al ztunnel del nodo donde se encuentra primero la IP del Pod en lugar del Pod de destino. El diseño de Ambient Mesh en este punto es que la dirección de destino del paquete de datos enviado por ztunnel es la dirección del Pod de destino (es decir, httpbin Pod), de esta manera, las reglas de enrutamiento de K **** 8 pueden Se utiliza para hacer que el paquete de datos llegue al objetivo. El host donde se encuentra el Pod está en el host opuesto y luego enruta el paquete de datos al Pod ztunnel a través de una serie de reglas. En la siguiente sección, veremos cómo se implementa este camino.

1）ztunnel-A Espacio de nombres de red -> Nodo-A Espacio de nombres de red

Después del equilibrio de carga de capa 4, ztunnel iniciará una conexión al puerto del par Pod 15008. La razón por la que se usa el puerto 15008 (en lugar del puerto de servicio o el puerto del Pod de backend) es que este puerto se usa cuando la regla iptables del par Coincidencias de túnel. Se establecen condiciones de coincidencia, cuyos detalles se analizarán en la Parte 3. Los paquetes de datos enviados por ztunnel primero deben llegar al host desde el ztunnel Pod para ser reenviados al nodo par a través del host. El ztunnel Pod, al igual que el Sleep Pod, también tiene un par de pares cinco conectados al host. El dispositivo El nombre en el espacio de nombres de la red ztunnel Pod es eth0, los paquetes de datos que ingresan al dispositivo ingresarán al espacio de nombres de la red del host desde el dispositivo veth en el lado del host. La dirección de destino de los paquetes de datos enviados por ztunnel es la dirección del httpbin Pod, y no alcanzará ninguna regla de iptables en el ztunnel Pod. En la etapa de enrutamiento, el paquete de datos alcanzará la regla de enrutamiento predeterminada y el paquete de datos se enviará al host a través de eth0.

2）Nodo-A -> Nodo-B

Después de que el paquete de datos llegue al NodoA, dado que su dirección de destino es la dirección IP del pod httpbin (10.244.1.17), alcanzará la regla de enrutamiento para el segmento de red del pod agregado por los K8 en la tabla de enrutamiento principal:

......
10.244.1.0/24 via 172.18.0.4 dev eth0
......

Esta regla indica que los paquetes de datos destinados al segmento de red 10.244.1.0/24 se envían a la puerta de enlace 172.18.0.4 (dirección del Nodo B) a través del dispositivo eth0. Los paquetes de datos enviados por el Pod ztunnel son la dirección httpbin Pod 10.244. 1.7, por lo que se cumplirá esta regla. Regla, salga del Nodo-A a través del dispositivo eth0 y vaya al Nodo-B, y finalmente ingrese al espacio de nombres de la red del NodoB a través del dispositivo eth0 del NodoB:

3）Espacio de nombres de red del Nodo-B -> Espacio de nombres de red ztunnel-B

Primer paquete de datos de enlace ascendente

En la ruta desde el nodo al ztunnel en la fase de entrada, similar a la fase de salida, el primer paquete de datos (paquete de protocolo de enlace TCP) se reenviará al ztunnel a través de una ruta diferente a la de los paquetes de datos posteriores. Comience también con el análisis del primer paquete. Echemos un vistazo a las reglas de enrutamiento de políticas del Nodo B. Dado que este paquete de datos no lleva ninguna marca, no está en el ipset ztunnel-pod-ips del Nodo B. Al mismo tiempo, el La dirección de destino del paquete de datos es Pod. La IP no afectará las reglas de iptables de la red K8, así que veamos directamente la etapa de enrutamiento de políticas:

0:      from all lookup local
100:    from all fwmark 0x200/0x200 goto 32766
101:    from all fwmark 0x100/0x100 lookup 101
102:    from all fwmark 0x40/0x40 lookup 102
103:    from all lookup 100
32766:  from all lookup main
32767:  from all lookup default

Dado que la tabla de enrutamiento local contiene todas las reglas de enrutamiento local, no se puede alcanzar. El paquete de datos no tiene ninguna etiqueta y no alcanzará 100, 101 o 102. Por lo tanto, el paquete de datos alcanzará la regla 103 y utilizará el enrutamiento 100. tabla. A continuación, echemos un vistazo a esta ruta. Contenido de la tabla:

10.244.1.3 dev vethbcda8cd4 scope link 
10.244.1.5 via 192.168.126.2 dev istioin src 10.244.1.1 
10.244.1.6 via 192.168.126.2 dev istioin src 10.244.1.1
10.244.1.7 via 192.168.126.2 dev istioin src 10.244.1.1

100 Se configura una regla de enrutamiento en la tabla de enrutamiento para la dirección IP de cada Pod que se ejecuta en este nodo. Cada regla apunta al dispositivo istioin en el nodo. Es decir, cuando se usa esta tabla de enrutamiento para el enrutamiento, siempre que el paquete de datos Si la dirección de destino es un Pod en esta máquina, se enruta al dispositivo istioin. La dirección de destino de este paquete de datos es la dirección httpbin Pod 10.244.1.7. Llegará a la regla de enrutamiento en la línea 4: 10.244.1.7 a través de 192.168.126.2 dev istioin src 10.244.1.1, ingresando así al dispositivo istioin. Mencionamos el dispositivo istioout en la discusión anterior. De manera similar, el dispositivo istioin se usa para manejar el tráfico entrante y el otro extremo es el dispositivo pistioin en el ztunnel B Pod.

Después de que el paquete de datos ingresa a ztunnel-B a través del dispositivo pistioin, también se debe a que la dirección de destino es httpbin Pod. Para no ser descartado por ztunnel Pod, también debe ser redirigido mediante la regla iptables. Desde la dirección de destino del paquete de datos es 15008, los datos El paquete cumplirá las siguientes reglas:

-A PREROUTING -i pistioin -p tcp -m tcp --dport 15008 -j TPROXY --on-port 15008 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff

Esta regla hace coincidir el paquete de datos del dispositivo pistioin, el protocolo es tcp y el puerto de destino es 15008, lo redirige al puerto 15008 de 127.0.0.1 a través de TPROXY y marca el paquete de datos con 0x400. marcado, Las siguientes reglas se aplicarán durante la fase de enrutamiento de políticas:

20000:  from all fwmark 0x400/0xfff lookup 100

Esta regla de enrutamiento de política indica utilizar la tabla de enrutamiento 100 para enrutar paquetes:

local default dev lo scope host

Similar a ztunnel-A, la tabla de enrutamiento 100 tiene solo una regla de enrutamiento, que es enrutar el paquete de datos al dispositivo lo, lo que obliga al paquete de datos a ingresar a la pila de protocolos local. Dado que la dirección de destino del paquete de datos se modifica por TPROXY a 15008, el paquete de datos eventualmente llegará al socket que el proceso ztunnel está escuchando en el puerto 15008. En este punto, el paquete de datos de ztunnel-A llega con éxito al proceso de ztunnel:

paquete de datos de enlace descendente

Cuando la pila de protocolos ztunnel Pod envía un paquete de datos de enlace descendente, el paquete de datos ingresará al host a través del dispositivo eth0 y se aplicarán las siguientes reglas de iptables en el host:

-A ztunnel-PREROUTING ! -s 10.244.2.3/32 -i veth51e3b96d -j MARK --set-xmark 0x210/0x210

La condición coincidente de esta regla es que si la dirección de origen del paquete de datos no es la IP del ztunnel Pod, sino que proviene del dispositivo ztunnel Pod veth, se marcará con 0x210. Al igual que la fase de salida, los paquetes de datos marcados con 0x210 se enrutará utilizando la tabla de enrutamiento principal:

100:    from all fwmark 0x200/0x200 goto 32766
......
32766:  from all lookup main

Dado que la dirección de destino del paquete de datos de enlace descendente es la dirección del Pod de suspensión (10.244.2.8), utilizando las reglas de enrutamiento de la red K8 en la tabla de enrutamiento principal, el paquete de datos enviado al segmento de dirección 10.244.2.0/24 saldrá por el dispositivo eth0 del host. , es enrutado por el enrutador en la red del host al host donde se encuentra el pod de pares.

10.244.2.0/24 via 172.18.0.3 dev eth0

Después de determinar la ruta, siga las siguientes reglas en la cadena ztunnel-FORWARD:

-A ztunnel-FORWARD -m mark --mark 0x210/0x210 -j CONNMARK --save-mark --nfmask 0x210 --ctmask 0x210

Al igual que en la fase de salida en el Nodo A, la conexión está marcada con una marca 0x210 en el paquete de respuesta. La marca en la conexión hará que los paquetes de datos posteriores cumplan con otras reglas.

Paquetes de datos de enlace ascendente posteriores

Dado que la conexión está marcada con 0x210, los paquetes de datos posteriores alcanzarán las siguientes reglas de iptables después de ingresar al Nodo B:

-A ztunnel-PREROUTING ! -i vethbcda8cd4 -m connmark --mark 0x210/0x210 -j MARK --set-xmark 0x40/0x40
-A ztunnel-PREROUTING -m mark --mark 0x200/0x200 -j RETURN

De manera similar al Nodo A, si el paquete de datos no proviene de ztunnel veth y tiene una etiqueta de conexión 0x210, el paquete de datos se marca con 0x40. El propósito es permitir que el paquete de datos se enrute utilizando la tabla de enrutamiento 102 en el siguiente etapa de enrutamiento:

102:    from all fwmark 0x40/0x40 lookup 102

102 La tabla de enrutamiento es la tabla de enrutamiento que conduce a ztunnel-B. El paquete de datos alcanzará la regla de enrutamiento predeterminada y se enrutará a vethbcda8cd4 (es decir, el dispositivo de red de ztunnel-B en el host), ingresando así al ztunnel Pod.

default via 10.244.1.3 dev vethbcda8cd4 onlink 
10.244.1.3 dev vethbcda8cd4 scope link

El proceso después de ingresar al ztunnel Pod es el mismo que el de la etapa Inbound y no se describirá nuevamente aquí.

Resumir

La fase de entrada en el Nodo B es similar a la fase de Salida en el Nodo A. En esta fase desde el Nodo B hasta ztunnel, el primer paquete de datos sale del host desde la interfaz istioin y la interfaz pistioin ingresa al Pod ztunnel, y datos posteriores Debido a que la conexión está marcada con 0x210, el paquete saldrá del host a través del dispositivo veth del ztunnel Pod y luego ingresará al ztunnel Pod a través del dispositivo eth0 del ztunnel Pod.

Parte 3: ztunnel-B a httpbin

Después de que ztunnel-B reciba la conexión del par ztunnel, inmediatamente establecerá una conexión TCP con el Pod de destino para que los datos descifrados puedan enviarse al Pod de destino a través de esta conexión. ztunnel-B los obtiene de la conexión llamando a getsockopt usando la opción SO_ORIGINAL_DST a la dirección de destino original y conozca el puerto de destino real a través del mensaje de protocolo de enlace HTTP CONNECT enviado por ztunnel-A. Al mismo tiempo, para que httpbin Pod piense que el paquete de datos proviene del Sleep Pod, ztunnel necesita pasar la opción IP_TRANSPARENT en el sockt utilizado para conectarse a httpbin. La dirección de origen de la conexión debe ser la dirección del Pod de suspensión (ztunnel puede conocer la dirección del Pod de suspensión a través de la dirección de origen de la conexión). . De esta manera, la dirección de origen del paquete de datos enviado desde ztunnelB es la dirección del Pod de suspensión y la dirección de destino es la dirección del Pod httpbin, al igual que el paquete de datos realmente se envía desde el Pod de suspensión. A continuación, observamos cómo este paquete sale del pod ztunnel y finalmente llega al pod httpbin.

1）ztunnel-B Espacio de nombres de red -> Espacio de nombres de red Nodo-B

Dado que el paquete enviado al Pod httpbin no cumplirá ninguna regla de iptables en el Pod ztunnel B, el Pod no llevará ninguna etiqueta. El paquete alcanzará la siguiente política de enrutamiento en el Pod ztunnel, utilizando la tabla de enrutamiento principal.

0:      from all lookup local
20000:  from all fwmark 0x400/0xfff lookup 100
20003:  from all fwmark 0x4d3/0xfff lookup 100
32766:  from all lookup main
32767:  from all lookup default

El contenido de la tabla de enrutamiento principal es el siguiente:

default via 10.244.1.1 dev eth0 
10.244.1.0/24 via 10.244.1.1 dev eth0 src 10.244.1.3 
10.244.1.1 dev eth0 scope link src 10.244.1.3 
192.168.126.0/30 dev pistioin proto kernel scope link src 192.168.126.2 
192.168.127.0/30 dev pistioout proto kernel scope link src 192.168.127.2

Dado que la dirección del Pod httpbin es 10.244.1.7, la regla predeterminada a través de 10.244.1.1 dev eth0 en la tabla de enrutamiento se usará para el enrutamiento, y el paquete de datos se enviará a la interfaz de red eth0 para salir del Pod ztunnel y ingrese al anfitrión.

2）Espacio de nombres de red del nodo B -> Espacio de nombres de red httpbin

Después de que el paquete de datos llega al host, dado que su dirección de destino es la dirección del Pod en la máquina local, debe evitar alcanzar la regla de enrutamiento que redirige el paquete de datos al Pod ztunnel que fue alcanzado en la etapa anterior. utiliza ztunnel: se han agregado las siguientes reglas a la cadena PREROUTING (cómo saltar a la cadena ztunnel-PREROUTING, consulte el artículo anterior y no se repetirá aquí):

......
-A ztunnel-PREROUTING ! -s 10.244.1.3/32 -i vethbcda8cd4 -j MARK --set-xmark 0x210/0x210
......

vethbcda8cd4 es el dispositivo en el lado del host del par veth de ztunnel Pod veth. Después de que el paquete de datos ingresa al dispositivo eth0 de ztunnel Pod, llega al host a través de este dispositivo. Esta regla coincide con el paquete de datos de ztunnel Pod veth. Los datos los paquetes que cumplan con esta regla se marcarán con 0x210. En la segunda parte, los paquetes de datos de ztunnel-A alcanzaron la regla de enrutamiento de política numerada 103 y se enrutaron al pod de ztunnel utilizando la tabla de enrutamiento 100. Sin embargo, actualmente debido a la existencia de la marca 0x210, el paquete de datos primero alcanzará la regla de enrutamiento de política numerada 100 y finalmente usará la tabla de enrutamiento principal para el enrutamiento:

0:      from all lookup local
100:    from all fwmark 0x200/0x200 goto 32766
101:    from all fwmark 0x100/0x100 lookup 101
102:    from all fwmark 0x40/0x40 lookup 102
103:    from all lookup 100
32766:  from all lookup main
32767:  from all lookup default

Echemos un vistazo al contenido de la tabla de enrutamiento principal:

default via 172.18.0.1 dev eth0 
10.244.0.0/24 via 172.18.0.2 dev eth0 
10.244.1.2 dev veth1eb71e57 scope host 
10.244.1.3 dev vethbcda8cd4 scope host 
10.244.1.5 dev veth6cba8664 scope host 
10.244.1.6 dev vetheee0622e scope host
10.244.1.7 dev vethfc1b555e scope host
10.244.2.0/24 via 172.18.0.3 dev eth0 
172.18.0.0/16 dev eth0 proto kernel scope link src 172.18.0.4 
192.168.126.0/30 dev istioin proto kernel scope link src 192.168.126.1

La red K8s insertará todas las entradas de enrutamiento del pod en el nodo actual en la tabla de enrutamiento principal. El paquete de datos enviado a la IP del Pod se enrutará al quinto dispositivo conectado al espacio de nombres de la red del Pod. El paquete de datos enviado al Pod httpbin hit La regla de enrutamiento en la línea 7 se enruta al dispositivo vethfc1b555e, y luego el paquete ingresará al Pod httpbin desde el otro extremo del dispositivo, que es el dispositivo eth0 ubicado dentro del Pod httpbin. En este punto, hemos completado la ruta completa del paquete de datos.

Conclusión

En este artículo, el autor analiza la ruta completa desde el Pod de origen al Pod de destino en Ambient Mesh. Sin embargo, debido a limitaciones de espacio, en realidad hay algunos detalles que no se han mencionado en este artículo. El autor discutirá el enrutamiento de paquetes. de la comunicación sin pod en el futuro. Comparte estos contenidos paso a paso. Alibaba Cloud Service Grid ASM [ 2] también admite oficialmente el modo ambiental en la versión 1.18 recién lanzada. Como la primera red de servicios totalmente administrada de la industria que admite el modo ambiental, ASM adapta algunos complementos de red comunes y proporciona los documentos de respaldo correspondientes. como reglas de enrutamiento y reglas de seguridad en modo ambiente, los lectores pueden venir y experimentarlo.

Enlaces relacionados:

[1] Este artículo

https://developer.aliyun.com/article/1290950

[2] ASM de la red de servicios en la nube de Alibaba

https://account.aliyun.com/login/login.htm?oauth_callback=https%3A%2F%2Fservicemesh.console.aliyun.com%2F&lang=zh