¿Cómo reenvía el tráfico de red de VPN? (Capa 3)

Estoy buscando información sobre cómo las VPN (Red privada virtual) reenvían el tráfico de red a través de su VPS (Servidor privado virtual).

Tome un ejemplo donde está conectado a una VPN. Realiza una solicitud a un sitio web, que luego baja por la pila de red a la Capa 3.

Tenemos un paquete de IP: tiene sus encabezados, incluida su dirección de destino y una carga útil.

Si cambia la dirección de destino del paquete IP a la dirección IP del VPS, ¿cómo reenvía el servidor la solicitud a la dirección de destino original?

Lo único que se me ocurre es que en la Capa 3 (la Capa IP), la dirección de destino del encabezado se cambia a la dirección IP del VPS, y luego la dirección de destino original se agrega a la carga útil del paquete.

¿Esto no significa que la longitud del paquete y el encabezado de la suma de verificación del paquete tendrían que ser recalculados y el paquete IP nuevamente modificado?

Y luego el VPS realiza la asignación inversa del paquete para ensamblar y realizar la solicitud original en el servidor.

Esto parece que habría un tiempo de latencia alto asociado con él.

Tal vez me falta algún aspecto técnico de cómo funciona esto, ¿alguien más puede explicarlo?

Tomemos, por ejemplo, el encabezado GRE (GRE es un protocolo utilizado para realizar VPN; no se usa con frecuencia ya que no es seguro de ninguna manera, pero el concepto de encapsulación es casi el mismo en todas las conexiones VPN (también con IPsec, por ejemplo) ):

Como puede ver, el paquete original se encapsula en otro paquete IP.

Supongamos que hay dos redes / enrutadores (A y B, un enrutador puede ser un VPS) conectados entre sí a través de una VPN (sitio a sitio).

Si un host en la red A quiere acceder a un servidor FTP en la red B, el host en la red A enviará un paquete, donde la dirección de destino es la dirección IP del servidor FTP y la dirección de origen es la suya.

Luego, el paquete original llega al VPN-Gateway (probablemente su enrutador), que encapsula este paquete original en, por ejemplo, un paquete IPv4 donde la dirección de destino es el VPN-Gateway (red B) y la dirección de origen es la suya. De esa manera, el paquete puede viajar a través de Internet a la otra VPN-Gateway (red B). Aquí, el protocolo / encabezado original o tipo de paquete no importa, ya que se encapsulará con un encabezado IPv4 para viajar por Internet y otros enrutadores no se preocuparán por el protocolo / encabezado original ya que solo ven el "nuevo" Encabezado IPv4.

Se debe calcular una nueva suma de verificación para el "nuevo" paquete que se agrega, de lo contrario no podría viajar por Internet (como, por ejemplo, PPP a veces se usa entre puntos en Internet, lo que calcula una suma de verificación). Por lo tanto, debe haber dos sumas de verificación en todo el paquete.

Con IPsec (que se usa casi siempre para conexiones VPN), el paquete original se encripta (principalmente a través de AES) y se agrega un encabezado de texto sin formato (el encabezado "nuevo" para viajar por Internet). Debe ser texto sin formato para que pueda enrutarse correctamente. Para eso, también se debe calcular una nueva suma de verificación (ya que la suma de verificación original está encriptada).

Cuando ha alcanzado el otro VPN-Gateway (red B), el encabezado VPN se desmonta y el paquete original se envía a la red (al servidor FTP).

Entonces, la respuesta corta a su pregunta es la encapsulación. Lo que significa que hay otro conjunto de encabezados de paquetes colocados alrededor del paquete que está enviando a un sitio web que es retirado por el punto final VPN.

Piénsalo de esta manera:

-----------------------------------------------
| src_ip=2.2.2.2, dest_ip=3.3.3.3             |
|---------------------------------------------|
|| src_ip=10.10.10.10, dest_ip=5.5.5.5       ||
|| Data goes here. This could be a HTTP GET  ||
|| or pretty much anything.                  ||
|---------------------------------------------|
-----------------------------------------------

Su cliente VPN que se ejecuta en su máquina local le dará una nueva dirección IP (10.10.10.10) y cambiará su tabla de rutas de modo que la ruta predeterminada se dirija hacia el túnel creado. Luego enviará el tráfico al servidor VPN o, en su ejemplo, un VPS (3.3.3.3). A menudo, su paquete tendrá un NAT aplicado cuando se desencapsule, por lo que en su servidor de destino (5.5.5.5) aparecerá que el tráfico proviene de la IP de destino del tráfico encapsulado (3.3.3.3) Así es como el tráfico vuelve a usted yendo primero al servidor VPN.

A tu tercera pregunta. Dado que está colocando un paquete adicional esencialmente en el exterior, la longitud y la suma de verificación se calculan en el paquete resultante. Entonces sí, hay dos longitudes y dos sumas de verificación. En cuanto a la longitud máxima que hace el VPS, dice usar esta MTU o mediante el descubrimiento de MTU de la forma habitual.

En cuanto a la latencia. No puedes romper la física. Tendrá en cuenta su sobrecarga de llegar al SPV y ejecutar su pila de red. Si bien puede parecer que habría una alta latencia, esto a veces no es el caso. Si su VPS está topológicamente en línea con el destino del paquete, es posible que se agregue una sobrecarga mínima. Por ejemplo, si está en Seattle y su VPS está en Nueva York y el sitio web con el que está tratando de hablar está en Londres. Pero si va de Seattle a Nueva York para regresar a un sitio web en Seattle, entonces hay una latencia adicional del viaje por los Estados Unidos.

La capa de transporte crea un paquete y lo pasa a la capa de red. El host busca en su tabla de enrutamiento y lo envía a la interfaz virtual creada por el software VPN.

El software VPN toma el paquete de la interfaz virtual. Puede encriptarlo o agregar sus propios encabezados, luego lo devuelve a la pila de red como carga útil. Dependiendo de la implementación particular de VPN, puede pasar esta carga útil a la capa de transporte o puede pasar por alto la capa de transporte e ir directamente a la capa de red.

Luego se agrega otra capa de encabezados de capa de red al paquete dirigido hacia el servidor VPN. Luego, el paquete se busca nuevamente en la tabla de enrutamiento y se envía a Internet (si la VPN es de "cobertura total", entonces el software VPN debe tener cuidado de configurar la tabla de enrutamiento de manera que el tráfico VPN salga del interfaz real orientada a internet en lugar de volver al software VPN).

Cuando el paquete encapsulado llega al servidor VPN, se devuelve al software VPN. Los encabezados "externos" se eliminan y el paquete se devuelve a la pila de red a través de una interfaz virtual.

Después de eso, depende de la pila de red en el servidor VPN qué hacer con él. En el caso de una VPN utilizada para acceder a Internet, la pila de red en el servidor VPN probablemente estará configurada para actuar como un enrutador NAT, por lo que modifica la fuente del paquete y la envía de vuelta a Internet.

Cuando la respuesta regresa, ocurre el mismo proceso. El paquete llega, el proceso NAT se invierte, se devuelve al software VPN a través de la interfaz virtual, se encapsula y se envía nuevamente al software VPN en el cliente que lo desencapsula y lo devuelve a la pila de red para que se puede entregar a la aplicación del cliente.