Softethervpn: NicSetSetting: el cambio de dirección MAC no tiene efecto hasta que se reinicia manualmente el cliente VPN
He estado usando NicSetSetting para configurar la dirección MAC de las NIC virtuales que se unen a un Hub. Usé arrendamientos estáticos, por lo que la dirección MAC determina efectivamente la dirección IP que debe obtener la NIC.
Sin embargo, he notado que el cambio de dirección MAC, aunque registrado en los datos de Softether, no se refleja en el sistema operativo real, hasta después de reiniciar el cliente VPN. Esto significa que, en el primer contacto, mis NIC están configuradas con direcciones IP incorrectas.
También probé:
- Habilitar y deshabilitar NIC
- Configurándolo varias veces
- Desconectar cualquier cuenta y luego reconectarse.
Sin embargo, solo vpnclient stop && vpnclient start funciona para mí. Estoy usando dos clientes separados:
- Versión 4.17 compilación 9562 en Debian Wheezy
- Versión 4.18 compilación 9570 en Raspbian
Ambos exhiben el mismo comportamiento. ¿Es esto un error o una característica?
scandox
Todos 4 comentarios
¿Podría verificar que este problema persiste?
moatazelmasry2
en 24 nov. 2017
@ moatazelmasry2 Perdón por la respuesta lenta. No he estado activo con Softether durante algunos meses.
Hoy le eché un vistazo a esto.
- Configuro un servidor y un cliente
- Conectado al cliente
- Verificó la dirección MAC que era 00: AC: B2: 5A: 26: 93
- Inició sesión en vpncmd y ejecutó "NicSetSetting ether MAC: / 00-AC-BA-B5-B4-78
- Cerró la sesión de vpncmd y ejecutó ifconfig. Todavía veo MAC terminando con 93
- Vpnclient reiniciado
- Ejecutó ifconfig y ahora veo que MAC termina con 78
Así que me parece que este número aún está activo. Las versiones de Server y Client fueron:
- Client Ver 4.24, compilación 9651 en Ubuntu 16.06
- Versión del servidor 4.24, compilación 9651 en Ubuntu 16.06
scandox
en 1 dic. 2017
@ moatazelmasry2 No soy realmente una persona de C ++, pero me parece que el problema radica en o alrededor del código aquí:
r en este caso siendo el resultado de r = Search(c->UnixVLanList, &t); . Después de esto, hay llamadas a CiSaveConfigurationFile y CiNotify y CiSendGlobalPulse , ninguna de las cuales parece hacer mucho en el nivel del sistema operativo. Entonces, ¿tal vez simplemente esté configurando el MAC en la lista interna, guardándolo en una configuración y luego no intentando actualizar el adaptador virtual?
Cuando el cliente se reinicia, por supuesto, inicializará el adaptador correctamente con lo que encuentre en la configuración.
Mirando más a fondo la inicialización del dispositivo TAP para la NIC virtual, vemos esta línea que parece establecer la dirección MAC en init:
Esto está en una función llamada UnixCreateTapDeviceEx , así que supongo que lo que necesitamos es una llamada UnixModifyTapDevice , que en realidad llama a ioctl con la nueva MAC. Dado que esto aún no existe, ¡quizás haya una buena razón!
scandox
en 5 dic. 2017
No lo probé todavía, pero parece un muy buen análisis. ¡¡¡Trabajo sólido!!!. Ahora necesitamos que alguien lo implemente :)
moatazelmasry2
en 5 dic. 2017
Temas relacionados
connLAN
·
9Comentarios
GlennMatthys
·
6Comentarios
Adrian-Voelker
·
16Comentarios
suyash95
·
4Comentarios
forever8938
·
8Comentarios
Comentario más útil
@ moatazelmasry2 No soy realmente una persona de C ++, pero me parece que el problema radica en o alrededor del código aquí:
https://github.com/SoftEtherVPN/SoftEtherVPN/blob/bed99f9a56e29a0fcd7a9e3d02f84f9d8621eb3d/src/Cedar/Client.c#L8104
ren este caso siendo el resultado der = Search(c->UnixVLanList, &t);. Después de esto, hay llamadas aCiSaveConfigurationFileyCiNotifyyCiSendGlobalPulse, ninguna de las cuales parece hacer mucho en el nivel del sistema operativo. Entonces, ¿tal vez simplemente esté configurando el MAC en la lista interna, guardándolo en una configuración y luego no intentando actualizar el adaptador virtual?Cuando el cliente se reinicia, por supuesto, inicializará el adaptador correctamente con lo que encuentre en la configuración.
Mirando más a fondo la inicialización del dispositivo TAP para la NIC virtual, vemos esta línea que parece establecer la dirección MAC en init:
https://github.com/SoftEtherVPN/SoftEtherVPN/blob/d7d0e6d36fe1d73eca6205d9b2144ded67f52b13/src/Cedar/VLanUnix.c#L527
Esto está en una función llamada
UnixCreateTapDeviceEx, así que supongo que lo que necesitamos es una llamadaUnixModifyTapDevice, que en realidad llama aioctlcon la nueva MAC. Dado que esto aún no existe, ¡quizás haya una buena razón!