Permítanme presentarles el escenario.
AP#1 <-----> (Linux #1) <-----> Red intermedia <-----> (Linux #2) <-----> Cliente inalámbrico
En resumen, necesito que una aplicación que se ejecuta en el cliente inalámbrico pueda comunicarse de forma transparente con el punto de acceso n.° 1 (AP#1).
Como puedes ver arriba, tengo un dispositivo llamadoAP#1, que genera un punto de acceso para una aplicación determinada. Esta aplicación se puede utilizar asociándose aAP#1y quiero que un cliente inalámbrico lo use de forma remota. Como no puedo tocar la configuración deAP#1, pero puedo configurar#1y#2, probé lo siguiente:
- #1asociados aAP#1usando el suplicante wpa, permaneciendo en la misma subred.
- #2crea un punto de acceso para el cliente inalámbrico en otra subred.
- El cliente inalámbrico habla con una IP fija en AP#1, y el tráfico se enruta y navega en#1, para que la comunicación conAP#1es transparente.
Hasta ahora todo bien, el cliente inalámbrico puede hacer ping a la dirección AP#1. Sin embargo, el cliente inalámbrico inicia la comunicación enviando un paquete UDP a 255.255.255.255, esperando queAP#1respuestas antes de que la aplicación realmente comience a funcionar. ¿Hay alguna forma de enrutar estas solicitudes de un lado a otro o 255.255.255.255 generalmente no se puede enrutar?
Pensé en cambiar esta configuración por un túnel gretap, pero esta topología es un poco diferente a los ejemplos que vi ya que no puedo configurarAP#1.
Asi que aqui están mis preguntas:
- ¿Cree que este problema se puede solucionar estableciendo algún tipo de túnel L2?
- Si es así ¿cuál sería la mejor opción?
- En ese caso, ¿sería posible eliminar la NAT en Linux #1 y hacer que la asociación entre AP#1 y el cliente inalámbrico sea totalmente transparente?
Gracias de antemano y perdón por las preguntas novatas.
Respuesta1
¿Cree que este problema se puede solucionar estableciendo algún tipo de túnel L2?
Sí, y puentes en ambos extremos. Pero es posible que Linux no facilite la conexión de una interfaz de cliente Wi-Fi (ver más abajo).
¿Hay alguna forma de enrutar estas solicitudes de un lado a otro o 255.255.255.255 generalmente no se puede enrutar?
No está prohibido reenviar transmisiones, por ejemplo Cisco IOS tenía esa opción, aunque los enrutadores no lo hacen por defecto para evitar bucles.
No estoy seguro de que Linux pueda hacer eso de forma nativa, aunque podría ser posible usando una regla de iptables poco conocida. Será más fácil utilizar un demonio de espacio de usuario bcrelayque pueda reenviar transmisiones en una dirección.
En ese caso, ¿sería posible eliminar la NAT en Linux #1 y hacer que la asociación entre AP#1 y el cliente inalámbrico sea totalmente transparente?
No completamente. Puede hacerlo completamente transparente a nivel de IP, pero un cliente Wi-Fi estándar solo puede enviar tramas con su propia dirección MAC, por lo que no podrá simplemente conectar la interfaz Wi-Fi del cliente; será necesarioNAT de capa 2de algún tipo en el dispositivo "Linux#1". (El dispositivo "Linux#2" es un AP por lo quepoderser completamente transparente en la capa 2.)
No sé cómo implementarlo en Linux estándar, aunque he visto ARPNAT en firmwares propietarios (dispositivos Mikrotik RouterOS y Ubiquiti airOS) cuando están configurados en modo estación. Creo que muchos "puentes inalámbricos" de consumidores también lo implementan.
(Linux admite la asociación en modo "4addr", que es totalmente puenteable, pero lo más probable es que su AP no lo admita).