Cómo usar el modo de transporte IPsec entre dos puertas de enlace

Question

Cómo usar el modo de transporte IPsec entre dos puertas de enlace

#1 de ecdsa (2 votos)

2

He leído muchas comparaciones del modo de transporte IPsec frente al modo túnel, y hay un claro entendimiento de que cuando dos puertas de enlace intercambian tráfico enrutado, deberían usar el modo túnel. En otras palabras, el modo de transporte debería ser usado solo entre dos hosts (o dos puertas de enlace si se comunican entre sí, no enrutando el tráfico). Lo que trato de entender es si el modo de transporte se puede utilizar en una configuración de puerta de enlace a puerta de enlace, incluso si no se recomienda.

Mi configuración es la siguiente:

LAN1 < - > GW1 < - > GW2 < - > LAN2

En mi caso, quiero proteger el enlace entre GW1 y GW2 (que contiene tráfico de IP de / a LAN1 a / de LAN2). Es una conexión directa, sin enrutamiento involucrado, sin NAT, nada. Todas las razones por las que se recomienda el modo de túnel (y el modo de transporte no) no se aplican a mi caso. Estoy de acuerdo en dejar los encabezados de IP sin cifrar, etc. Quiero ahorrar bytes de sobrecarga, por lo que me gustaría usar el modo de transporte incluso si no se recomienda en este caso.

Estoy usando Ubuntu Linux con el paquete Strongswan e IPsec en modo ESP.

Mi pregunta es: ¿es posible ?

¿Existe una razón "fundamental" que la hace imposible, o simplemente "no se recomienda / generalmente no se hace / no está en el manual de Cisco" pero es factible?

¿Alguien tiene un archivo de configuración que funcione?

vpn ipsec

pregunta Danielik 30.08.2018 - 18:31

fuente

1 respuesta

Lea otras preguntas en las etiquetas vpn ipsec

Las direcciones IP no aparecen en el historial de inicio de sesión de Facebook ¿Hay alguna manera de probar que un programa se ejecutó en mi PC con Windows?

score 2 · Answer 1

El problema es aplicar IPsec de forma transparente.

Los SPI utilizados para identificar asociaciones de seguridad (SA) no son únicos a nivel mundial, son asignados por el host receptor, por lo que para identificar de manera única una SA en la base de datos de asociaciones de seguridad (SAD), el SPI de la tupla, el protocolo (ESP o AH). y se utiliza la dirección IP de destino. Esta es también la forma en que un host procesa un paquete IPsec entrante; de forma predeterminada, simplemente busca una entrada SAD con una tupla que coincida con los datos del paquete recibido (también es posible verificar primero si la dirección de destino es local y luego realizar la búsqueda). en el SAD con solo el SPI y el protocolo, eso es lo que sección 5.2 de RFC 4301 describe).

Sin embargo, en el escenario descrito, el destino no es una única dirección IP conocida que sea local para el host (como es el caso en el modo túnel y en el modo de transporte de host a host), en cambio, podría tomar un rango completo de valores como podría ser la dirección de cualquiera de los hosts detrás de la puerta de enlace de recepción. Por lo tanto, no se puede utilizar la búsqueda predeterminada.

Lo que se requiere es una búsqueda que ignore la dirección de destino (lo que podría generar desajustes si un host detrás de la puerta de enlace usa IPsec y asignó el mismo SPI), o algún tipo de coincidencia de subred / rango para las direcciones IP .

Ahora, en lo que respecta al kernel de Linux, ninguna de estas opciones está disponible. El código que busca en una entrada SAD un paquete IPsec entrante ( / a>) insiste en hacer coincidir la dirección de destino almacenada en la entrada SAD. Por lo tanto, a menos que modifique el código fuente del kernel de manera que cambie la forma en que se trata la dirección de destino, no puede evitar usar el modo de túnel.

Para las direcciones IP individuales detrás de cada puerta de enlace, existe lo que se denomina modo BEET, que es compatible con el kernel de Linux (y strongSwan). En este modo, los paquetes se envían en modo de transporte (entre las direcciones de la puerta de enlace), pero antes / después del procesamiento, las direcciones en el encabezado IP se cambian de acuerdo con las direcciones de asignación (los selectores de tráfico de dirección única negociados, consulte draft-nikander-esp-beet-mode para obtener más información).

Nota al margen: en realidad, hay un indicador para las SA en el kernel de Linux llamado __xfrm_state_lookup que permite algunas coincidencias de direcciones comodín para IPv6, pero solo se usa para Mobile IPv6 a través de una función de búsqueda separada (para procesar paquetes con Opciones de destino y Tipo 2 Encabezados de extensión de enrutamiento que parece).