Por qué su sensor de VPN nunca ve la etiqueta VLAN de la sucursal
Un túnel enrutado recupera paquetes, no las tramas que los transportaron. Cuatro comprobaciones sobre el tipo de interfaz, la posición del sensor, el contexto de origen y la ruta de respuesta.
Un sensor del lado de la VPN ve dos VLAN de sucursal como tráfico IP plano, y la etiqueta que identificaba cada sucursal en su propio cable ha desaparecido. Eso es lo que hace un túnel enrutado: recupera paquetes, no las tramas Ethernet que los entregaron. Que la etiqueta ausente importe depende por completo de la pregunta que le haga al sensor. Realice las cuatro comprobaciones siguientes en orden y sabrá qué punto de observación puede responderla.
Primero: establezca qué recupera su túnel
Una interfaz TUN transporta paquetes IP, así que la cabecera VLAN de la trama de sucursal se detiene en el enrutador que empujó el tráfico al túnel. Una interfaz TAP transporta tramas Ethernet, lo que significa que las etiquetas pueden sobrevivir cuando el puente y las reglas de admisión de VLAN las dejan pasar. Lea el tipo de interfaz antes de razonar sobre qué debería contener una captura.
Ninguna de las dos opciones es un defecto. Los dos diseños responden preguntas distintas y dejan la etiqueta en lugares distintos.
Confirme la interfaz usted mismo en lugar de deducirla del nombre del producto. Los detalles del enlace nombran el tipo de dispositivo y muestran los indicadores vigentes, y una captura tomada en un dispositivo TUN no va a ganar una cabecera Ethernet solo porque usted la haya pedido. Si aparecen etiquetas en una captura TUN, casi con seguridad está leyendo otra interfaz o un túnel que transporta tramas dentro de su carga útil. Anote en qué caso se encuentra antes de continuar.
Segundo: coloque el sensor donde el objeto aún existe
Tres posiciones cubren la mayoría de los diseños enrutados: el segmento Ethernet de la sucursal, la red exterior entre los extremos del túnel y la ruta después del procesamiento del túnel. Cada una ve un objeto distinto, y la etiqueta solo existe en la primera. Elegir una posición de sensor es una decisión sobre qué objeto necesita la política, no una cuestión de comodidad.
| Observation point | What is actually there | Question it can answer |
|---|---|---|
| Branch Ethernet segment | Tagged frames on the local wire | Which VLAN carried this frame here |
| Outer tunnel network | The protected carrier between endpoints | Which endpoints are exchanging traffic |
| After tunnel processing | Recovered IP packets | Which branch prefix the packet claims |
Plantee la pregunta de política en términos que la tabla pueda responder, y normalmente se resuelve sola. Si la regla necesita saber de qué sucursal vino un paquete, el mapeo de prefijos aguas abajo puede bastar, pero solo mientras ese mapeo sea exacto e inequívoco. Si la regla necesita saber por qué puerto llegó la trama, necesita la primera posición, porque nada aguas abajo puede reconstruirlo. Los sensores colocados por costumbre y no por pregunta son la forma en que los equipos acaban exigiendo un campo que el diseño nunca llevó.
Un túnel que transporta Ethernet es un diseño distinto y necesita su propia comprobación de qué preservan o reescriben los extremos. Elegir TAP por sí solo todavía no define el puente, las reglas de admisión de VLAN ni la política de inspección.
Tercero: gánese el contexto de origen en lugar de confiar en él
Un rango de direcciones por sucursal es el sustituto habitual de la identidad VLAN, y solo se sostiene mientras el mapeo siga siendo uno a uno. Los prefijos solapados, la traducción y una puerta de enlace compartida rompen cada uno esa suposición de una forma que parece un problema de calidad de datos y no de diseño. Escriba el mapeo con sus límites y diga qué ocurre con un paquete que coincide con dos filas. Un prefijo que aparece en dos sucursales debería ser un error que usted detecta, no un lanzamiento de moneda que usted acepta.
El contexto que aporta el cliente no es prueba de pertenencia. Es una afirmación, y pertenece a otra columna.
Donde la distinción importa, use datos de asociación que usted controle: qué instancia de túnel aceptó la conexión, en qué interfaz llegaron los paquetes, qué dice la tabla de rutas local de ese par. Una etiqueta proporcionada por el cliente es una pista útil y una entrada de autorización inútil. Si el sensor no puede establecer la asociación desde su propio lado, la política necesita una regla más amplia y no una suposición confiada.
Cuarto: confirme la ruta de respuesta y qué pasa por alto el descifrado
Un sensor que solo ve una dirección todavía puede parecer sano, porque las peticiones siguen llegando a tiempo. Compruebe la ruta de respuesta de forma explícita, y compruébela para el mismo flujo y no para la accesibilidad general. La visibilidad de medio duplex se convierte en un hueco silencioso en cualquier conclusión con estado que saque de ella.
Recuperar el tráfico IP interno tampoco es lo mismo que ver la aplicación dentro de él, porque el TLS transportado por el túnel sigue siendo TLS.
ip -d link show tun0
tcpdump -i tun0 -n -e -c 5
Esos dos comandos responden a la pregunta de la interfaz y muestran qué contiene realmente la captura, lo que es más rápido que discutir sobre la arquitectura. Sustituya el nombre de interfaz que usa su diseño y ejecute la captura mientras el flujo que le interesa está activo. Cuando no aparece ninguna etiqueta en un dispositivo TUN, el hallazgo es que el diseño enrutó en lugar de puentear, no que el sensor haya perdido datos. Luego, o bien mueva el sensor a una posición que pueda ver la etiqueta, o bien reescriba la regla en términos que la posición actual pueda sostener.