Tengo dos clientes que necesitan conectarse a un servidor OpenVPN. ¿Es posible utilizar la misma puerta de enlace para ambos clientes en el parámetro ifconfig?
Client A config file
[...]
ifconfig 10.0.0.2 10.0.0.1
Client B config file
[...]
ifconfig 10.0.0.3 10.0.0.1
La situación en el servidor es la siguiente:
tun0
inet 10.10.0.1 destination 10.10.0.2
tun1
inet 10.10.0.1 destination 10.10.0.3
Ahora todo funciona bien, pero ¿podría dar algún problema de tiempo?
Me dijeron que usara una puerta de enlace diferente como esta:
Client A config file
[...]
ifconfig 10.0.0.2 10.0.0.1
Client B config file
[...]
ifconfig 10.0.1.2 10.0.1.1
Pero pensé que se necesitan diferentes puertas de enlace solo para propósitos de enrutamiento, si quiero agregar una ruta y reenviar mi tráfico en una interfaz tun específica, de hecho necesito una puerta de enlace diferente o el servidor no sabe cuál enviar los paquetes, pero si no ¿No necesito una ruta específica? ¿Puedo usar mi primera configuración?
Gracias
Respuesta1
Es posible y correcto. El parámetro gateway define la configuración en el cliente que se utiliza para enviar datos a la VPN, para que sea posible definir el enrutamiento como es habitual en IP. Una vez que el paquete se envía al proceso OpenVPN, este se encarga de su enrutamiento (hasta que abandona algún otro proceso OpenVPN).
En particular, usted define:
ifconfig 10.10.0.3 10.10.0.1
ElsoloEl resultado de este comando es como si ejecutara los siguientes comandos en el cliente:
ip address add 10.10.0.3 dev tun0
ip route add 10.10.0.1 dev tun0
Eso es todo. Otros clientes, un servidor, sistemas externos: nadie más conoce la configuración de este cliente.
Lo único donde se usa la puerta de enlace es escribir rutas hacia VPN de esta manera:
ip route add 192.168.0.0/24 via 10.10.0.1
por ejemplo, para configurar esta red para que sea accesible a través de VPN. Por ejemplo, la ruta al servidor VPN y otros clientes se hace así. Por supuesto, si tiene varios clientes, puede utilizar la misma dirección de puerta de enlace en ellos (y esto se hace naturalmente, por ejemplo, para computadoras vecinas en la misma LAN).
Lo mismo se aplica también a un servidor. Por ejemplo, ejecuto varias VPN en una sola máquina (una es a través de UDP, la otra es a través de TCP en el puerto 443 con la opción de compartir puerto, para poder atravesar firewalls que bloquean los puertos habituales pero permiten el 443 e incluso comprobar si hay es un servidor web). Ambos servidores tienen el mismolocaldirección configurada y difieren segúnremoto(Eso hace posible configurar a través de qué VPN enrito el paquete).
Ahora sobre los problemas que encontrarás. Con Linux OpenVPN en toda regla no hay problemas, por supuesto. Si va a utilizar el "Cliente OpenVPN", ya sea un cliente Linux, Windows, iOS/iPadOS/macOS o Android, depende de lo que topologyconfigure. En net30topología rechazarán dicha configuración como inválida. En este caso, la dirección del cliente y su control remoto deben pertenecer a la misma subred /30.
Respuesta2
Normalmente, una interfaz punto a punto, como tun0cualquier otra interfaz similar a un túnel, necesita una dirección local sólo para fines de gestión de túnel o para una identificación de túnel particular.
Piense en una interfaz de túnel como un punto final conectado remotamente. Esta interfaz tiene dos extremos: usted yel otro extremo. En general, no es necesario utilizarcualquierdirecciones en interfaces como esta cuando solo dos partes conectadas participan en el intercambio de datos: simplemente puede enviar un paquete a través de esta interfaz y se entregará al otro extremo, no hay otra manera.
Las cosas se vuelven un poco más complicadas si algún tercero necesita poder comunicarse con su punto final remoto conectado. Para llegar a este punto final necesitarán undirección remotacomo destino del paquete. El lado remoto, por el contrario, utiliza su dirección local para identificar su versión deel otro extremocuando es necesario, es decir, le instala la ruta predeterminada; sin embargo, podría usar la interfaz del túnel como destino de la ruta sin siquiera conocer su dirección local y aún así funcionaría.
Entonces, a menos que necesite identificar la interfaz de su túnel por su punto final local (es decir, usarla como dirección de origen para ciertos escenarios de protocolo de enrutamiento dinámico a través del túnel), puede usar cualquier dirección que desee como dirección local en el túnel; Ni siquiera es necesario estar en la misma subred que la dirección remota.