WireGuard, configurando múltiples clientes para NAT, y ¿a dónde va STUN?

En este momento, estamos lanzando acceso a servidores basados ​​en WireGuard y hoy quiero hablar sobre cómo configurar clientes que están detrás de NAT, aunque tampoco nos olvidaremos de la configuración del servidor.

Primero, sobre las ventajas de WireGuard y el reverso de la moneda, sobre las dificultades que surgen junto con las ventajas. WireGuard es una implementación bastante joven de un túnel entre dos puntos, ya que UDP utiliza el protocolo de transmisión. Es por eso, y también porque la implementación de Linux en sí misma se implementa como un módulo de kernel, las pruebas muestran una ventaja de velocidad decente sobre los competidores. Esto no puede considerarse una red punto a punto, aunque los nodos finales se denominan pares . La esencia de una red punto a punto no solo es que sería posible conectar dos nodos arbitrarios. Por supuesto, con este kit de herramientas, puede construir una infraestructura de red muy compleja, pero no tengo ese objetivo. Consideraremos conectarnos a un nodo del servidor y acceder a Internet a través de él.

Obviamente, si dos nodos, el servidor y un cliente tienen IP blancas , en este caso no debería haber ninguna dificultad en la configuración. Pero a menudo los clientes están detrás de NAT, y en este caso, al configurar el servidor, debe especificar la dirección IP incorrecta que se emite / registra en el dispositivo. En este sentido, el protocolo STUN puede ayudar. Este protocolo se usa a menudo cuando se trabaja con VoIP, especialmente cuando ambos clientes están detrás de NAT. Pero en nuestro caso, también ayudará. A juzgar por la información en Wikipedia, STUN no funciona con todos los tipos de NAT; en uno de los 4 tipos de NAT, un cliente (simétrico) puede tener una IP diferente a la que se puede definir externamente utilizando el cliente STUN.

Los clientes STUN existen en todos los sistemas operativos populares, excepto iOS. Bajo este sistema operativo, no pude encontrar el cliente STUN. Daré un ejemplo para macOS. Primero, debe instalar el cliente STUN.

$ brew install stunman 

Hay toneladas de servidores STUN en Internet y no es difícil encontrar ningún servidor para la prueba. Usaré stun.ekiga.net . Para la prueba, deberá utilizar el puerto local, el que utilizaremos para configurar:

 $ stunclient --localport 51820 stun.ekiga.net 

Con una prueba exitosa, obtenemos aproximadamente la siguiente conclusión:

 Binding test: success Local address: 192.168.88.23:51820 Mapped address: 82.207.27.3:51820 

La dirección asignada es exactamente la IP que necesitará usar al configurar el servidor. De hecho, esta es la dirección IP que en mi caso proporcionará cualquier servicio para determinar la IP externa. Por lo tanto, puede usar su servicio favorito para determinar la IP, pero, por supuesto, vale la pena considerar que esta prueba será indirecta y no hay garantía de que todo funcione como se esperaba.

Para conectarse, en el lado del cliente, para el servidor, debe proporcionar: IP, puerto y clave pública. Para la configuración en el lado del cliente, necesita exactamente la misma lista provista en el lado del servidor. A continuación, sugeriré opciones para configuraciones, si las usa como ejemplos, se recomienda regenerar las claves.

En Linux, esto se puede hacer desde la línea de comandos, en macOS a través de la interfaz de usuario oficial del cliente.

 $ wg genkey | tee privatekey | wg pubkey > publickey 

En este caso, en el lugar de la llamada, la clave privada se creará en el archivo privatekey, public in en publickey, respectivamente.

Primero, considere la configuración del cliente:

 #       [Interface] #       PrivateKey = YPuKo2QXndQ2Vc3S/y90oKT7AJ0Swhq/HWKiF7GwS04= #         ListenPort = 51820 #  IP   ,        #    Address = 10.8.0.2/24 # DNS   ,      DNS = 8.8.8.8 #     [Peer] #   ,     PublicKey = nFjDIkgsAh1RMZuaCJ+AKs7JmbMxxthhZ0POjUSTvkc= #     ,       # IP  ,          #     ,      #     WireGuard . IP   , #   . AllowedIPs = 0.0.0.0/0 #  IP    Endpoint = 46.101.122.130:51820 #  2 .  -    ,     , #    AllowedIPs         #   .  -     # ,    -  25 . PersistentKeepalive = 25 

Ahora es el momento para la configuración del servidor:

 #       [Interface] # IP      Address = 10.8.0.1/24 #     ListenPort = 51820 #  ,      PrivateKey = MNnxOy79xtXtSQ3UySWtdlOMbG7ff9dXGjeSTPEByn8= #  2 ,      wg0  PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE #     [Peer] #   ,    PublicKey = TdRtYd6XXI+ynPDXU6FF5TT3L5t/YlQVZswr2xsou34= #   IP ,     , #     AllowedIPs = 10.8.0.2/32 #  IP ,   ,     STUN  EndPoint = 82.207.27.3:51820 

Cuando se usan estas configuraciones como ejemplos, se recomienda eliminar los comentarios en ruso, el servidor y el cliente en el caso de comentarios no están garantizados.

Utilicé los siguientes recursos para configurar: el sitio oficial , ArchWiki y este tutorial .

Al final, también me gustaría aclarar un par de posibles preguntas:

1. ¿Es posible crear varias secciones del mismo Peer en el servidor, que solo diferirán en EndPoint ?

Sí, es posible, e incluso puede ser útil si utiliza el servicio desde diferentes lugares, por ejemplo, en el trabajo y en el hogar. Pero pueden surgir problemas si tales pares se conectan simultáneamente, en este caso habrá un conflicto de direcciones IP.

2. ¿Qué IP externa y puerto serán determinados por el protocolo STUN para varios clientes por NAT?

Lo mismo para todos los clientes, será lo mismo. ¿Sería esto un problema? Todo depende de la configuración de su proveedor / enrutador, pero fundamentalmente no deben surgir problemas, ya que el enrutador debe transmitir paquetes UDP dentro de la red por la máscara de red local, respectivamente, las partes receptoras que pueden descifrar los paquetes deben recibirlos con éxito. Realizamos pruebas en nuestros equipos, las pruebas fueron exitosas.

El propósito del artículo no era escribir un tutorial completo sobre cómo configurar WireGuard, no es difícil hacerlo utilizando la documentación oficial. Queríamos mostrar cómo WireGuard puede funcionar para NAT.

Si desea probar WireGuard en los negocios, puede contactarnos, tenemos acceso en modo de prueba.

UPD:
Como señaló correctamente el habitante aborigen , solo una IP blanca es suficiente para que el canal de datos funcione sin problemas. En consecuencia, EndPoint for Peer puede omitirse de la configuración del servidor, y esto facilita la configuración. Y el manual descrito puede ser útil si ambos nodos están detrás de NAT.

Source: https://habr.com/ru/post/481838/


All Articles