¿Cómo hacer que diferentes aplicaciones usen wifi vs ethernet?

Me gustaría enrutar algunas aplicaciones a través de WiFi y otras aplicaciones a través de Ethernet. Dado que OSX tiene una amplia gama de herramientas y utilidades del sistema, así como una rica ecosfera de aplicaciones, ¿cómo puedo hacer que eso suceda?*

básicamente estoy buscando algo como el conjunto de aplicaciones de rogue ameba, pero que manejen redes en lugar de audio

Respuestas (3)

Me gustaría enrutar algunas aplicaciones a través de WiFi y otras aplicaciones a través de Ethernet.

Desafortunadamente, esta no es la forma en que funciona (la creación de redes). No puede decir que quiere que Safari pase por un puerto de red e iTunes pase por otro. El problema con esto radica en el hecho de que las aplicaciones en sí mismas no realizan la conexión de red: realiza una llamada a la API de red ( conectores de Berkeley ) que realiza la conexión y vincula el proceso al propio zócalo.

En los términos más simples, el flujo se ve así

ingrese la descripción de la imagen aquí

Cuando su proceso local (la aplicación en cuestión) quiere hacer una conexión, solicita que se cree un socket. Parte de esa solicitud incluye la dirección IP, luego se realiza la conexión y la aplicación está vinculada a ella. Luego, la aplicación envía y recibe datos a través de ese socket.

La clave para recordar aquí es que la aplicación solicita un socket en función de la dirección de red. Aparte de (suponiendo que esté en una red con un solo segmento), solo tiene dos rutas:

  • tu red local
  • todo lo demás (es decir, Internet)

Si tiene dos interfaces conectadas a esta única red, sus rutas se superpondrán y la interfaz con prioridad será la principal.

Cualquiera que sea la aplicación que se esté ejecutando, dirá "Quiero ir a foo.bar.com", lo que se traducirá en una dirección IP y se creará un socket en la ruta que lo llevará allí. El punto es que su aplicación no tiene control sobre el asunto.

Sin embargo, supongamos que está conectado a dos redes diferentes:

  • Ethernet (en0) -> 1.2.3.0
  • WiFi (en1) -> 5.6.7.0

Si hay un servidor de archivos con una IP de 1.2.3.4, todo el tráfico destinado a esa dirección pasará por Ethernet. Si su WiFi está configurado para acceso a Internet, todas las llamadas a 1.2.3.0 y todas las demás direcciones pasarán por en1. Una vez más, su aplicación no tiene nada que decir al respecto y el socket se realizará en función del destino.

¿Puede una aplicación usar una interfaz de red específica?

Sí, por supuesto que puede, pero esto es algo que se hace en el nivel de origen de la aplicación porque es el que realiza la llamada a la API. Si lo codifica para usar una interfaz específica, lo hará (no es práctico en ningún sentido, pero tiene la capacidad).

En pocas palabras: para que una aplicación externa redirija el tráfico en función de la aplicación que usa, tendría que insertarse entre la aplicación y la pila de protocolos del sistema operativo y eso simplemente no sucederá.

Depende de las aplicaciones de las que estemos hablando y de lo que quieras lograr exactamente. En algunos casos, puede arreglárselas usando pf y enrutamiento basado en políticas (enrutamiento de origen) según el puerto de origen o los puertos de destino de sus aplicaciones. Sin embargo, esto normalmente solo es posible con aplicaciones que son "simples" en cuanto a la red (es decir, por ejemplo, solo se conecta a un único servidor).

Todavía no parece existir una solución genérica en un formato perfectamente empaquetado que pueda descargar y usar sin experiencia especial.

Si desea implementar una solución de este tipo, querrá usar la variable de entorno DYLD_INSERT_LIBRARIES al iniciar sus aplicaciones para inyectar su propia biblioteca compartida en el proceso. Esa biblioteca compartida debería anular la llamada bind() para asegurarse de que el proceso se vincule a la IP de su interfaz WiFi o Ethernet, según la aplicación.

Lo más parecido que puedo pensar para esto se llama priorización de paquetes (para que las aplicaciones no estén en la misma conexión Ethernet interfiriendo entre sí) está disponible en la placa base "Fatal1ty Z370 Professional Gaming i7" pero es una placa de $ 200 y es una solución de hardware, no creo que haya un software capaz de esto, pero podría estar equivocado, espero que esto haya ayudado.