Re: NAT sobre WLAN [SOLUCIONADO]
El Thu, 09 Jun 2016 14:06:46 -0300, JAP escribió: > TIP: > "El orden de las interfaces en /etc/network/interfaces, > ALTERA EL PRODUCTO" (...) Bueno, no es que "altere el resultado" sino que los datos del archivo "interfaces" se ejecutan por orden, por lo que si invocas un comando que añade una ruta hacia una interfaz que aún no se ha cargado lo que sucede simplemente es que esa orden no se va a ejecutar (en tu caso, las reglas "post-up" seguramente son las que te ha generado el problema). > Todo el problema que tuve para lograr el funcionamiento, se debió a lo > siguiente, por orden de importancia: > > A - El orden de inicio de las interfaces de red. > B - El uso de "restart" en lugar de reiniciar el sistema. Realmente no es necesario reiniciar el sistema, pero no siempre se sabe qué demonios o procesos son los que necesitan recargarse y resulta más sencillo reiniciar el sistema completo. Saludos, -- Camaleón
Re: NAT sobre WLAN [SOLUCIONADO]
El 07/06/16 a las 15:34, JAP escribió: Estimados: Una vez más, yo peleándome con las redes. Paso a explicar. Tengo un equipo corriendo Debian "jessie": # uname -a Linux javier 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) x86_64 GNU/Linux ¿Qué quiero hacer? Que los equipos conectados por WiFi a la placa wlan0 accedan a internet a través de la placa eth1. Tengo una red cableada a Internet: # ifconfig eth1 eth1 Link encap:Ethernet HWaddr a0:f3:c1:01:da:92 inet addr:192.168.2.52 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::a2f3:c1ff:fe01:da92/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1523 errors:0 dropped:0 overruns:0 frame:0 TX packets:1596 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:705060 (688.5 KiB) TX bytes:299878 (292.8 KiB) Me conecto a dicha red mediante un portal cautivo provisto por un servido ZeroShell, sobre el cual me identifico con un "script" en python. Tengo una placa de red inalámbrica que provee servicio dhcp para mis otros aparatos: En otro entorno más "natural", lo que he hecho toda mi vida, fue montar un puente br0 desde eth1 a wlan0. El problema que tengo es que en este lugar, debo pasar por el portal cautivo, y el maldito no me permite más de una conexión con una mac definida. Los puentes (bridges), generan una nueva MAC, y asignan direcciones IP del servidor. Y como dije, con una clave, no puedo tener más de una conexión. Y el BAFH no me da otra clave de acceso. Por lo que presto y diligente, decidí hacer una conexión NAT. Para ello, monté un servidor dhcp con isc-dhcp-server, el cual da su servicio a través de la placa inalámbrica: # ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr 00:87:30:23:0e:a8 inet addr:192.168.5.1 Bcast:192.168.5.255 Mask:255.255.255.0 inet6 addr: fe80::287:30ff:fe23:ea8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:265 errors:0 dropped:0 overruns:0 frame:0 TX packets:861 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:12142 (11.8 KiB) TX bytes:60578 (59.1 KiB) Mi celular se conecta al enrutador configurado sin inconvenientes: # ping 192.168.5.10 -c 3 PING 192.168.5.10 (192.168.5.10) 56(84) bytes of data. 64 bytes from 192.168.5.10: icmp_seq=1 ttl=64 time=150 ms 64 bytes from 192.168.5.10: icmp_seq=2 ttl=64 time=195 ms 64 bytes from 192.168.5.10: icmp_seq=3 ttl=64 time=203 ms --- 192.168.5.10 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 150.223/183.033/203.074/23.394 ms He intentado montar una NAT de no menos de 30 formas distintas, y no logro hacer que el navegador del celular vea internet. Las órdenes que he estado utilizando básicamente son iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE iptables -A FORWARD -i wlan0 -j ACCEPT Que, si la teoría no me falla, enmascara eth1, y reenvía los paquetes que vienen de wlan0. # iptables -t nat -L -v Chain PREROUTING (policy ACCEPT 3 packets, 545 bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 2 packets, 307 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 58 packets, 5878 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 36 packets, 2841 bytes) pkts bytes target prot opt in out source destination 22 3037 MASQUERADE all -- anyeth1anywhere anywhere Las reglas de iptables, las he variado en muchas formas, y realmente, ya no sé qué hacer. Otros ejemplo que he usado: iptables -t nat -A POSTROUTING ! -d 192.168.5.0/24 -o eth1 -j SNAT --to-source 192.168.2.52 También: iptables -t nat -A POSTROUTING ! -d 192.168.5.0/24 -o eth1 -j MASQUERADE Bueno. No funciona. El teléfono no tiene accesos a internet. Google no me da la solución. Escucho ofertas Muchas gracias en adelanto. JAP TIP: "El orden de las interfaces en /etc/network/interfaces, ALTERA EL PRODUCTO" He solucionado el problema. Mi red tiene ADEMÁS de las dos que mencioné, una interfaz en el segmento 10.0.0.0. Yo estaba haciendo todo bien, salvo que el ORDEN de inicio de las interfaces estaba generando el problema. Como "receta" para el futuro, transcribo todo lo que hice. CÓMO COMPARTIR POR WiFi UNA CONEXIÓN DE RED EN UN AMBIENTE MUY CONTROLADO POR UN BAFH. Entorno: Una red corporativa conectada a eth0 en el segmento 10.0.0.0 Una red internet, conectada a un enrutador de portal cautivo ZeroShell a eth1 en el segmento 192.168.2.0/24 Una red WiFi, como enrutador privado, conectado a wlan0, en el segmento 192.128.0.0/24 ¿Qué queremos hacer? Habilitar la conexión de aparatos con WiFi, como una NAT hacia internet. Es de destacar que el portal cautivo SÓLO PERMITE
Re: NAT sobre WLAN
El Wed, 08 Jun 2016 12:50:23 -0300, JAP escribió: > El 08/06/16 a las 12:43, Camaleón escribió: (...) >>> He intentado tu consejo. >>> El clonado hace que aparezca otra interfaz con la misma MAC, pero como >>> es un Portal Cautivo ZeroShell, me pide la contraseña nuevamente, y >>> por ende, no me deja tener más de una sesión abierta. >> >> Pues echa un ojo a ver cómo funciona ese portal, si conoces a tu >> enemigo podrás derrotarlo :-) >> >> The enemies of the Captive Portal >> http://www.zeroshell.org/hotspot-router/#issues >> > Eso lo he estudiado a fondo, y por ello mi sistema tiene un script > python en vez de andar trasteando con una pantalla del navegador siempre > abierto. ¿Y ya sabes qué tipo de filtro aplica ese portal? Por número de sesiones no es, desde luego y según dices, por MAC tampoco. >>> Lo que me "vuela" la cabeza, es que con VirtualBox, armé una NAT >>> interna, y es transparente para las máquinas virtuales. >> >> ¿Quieres decir que desde una máquina virtual de VB te permitía acceder >> al portal? >> > Sí. Accede en forma transparente. > Por eso no entiendo qué estoy haciendo mal. ¿Qué tipo de sistema red tienes configurada en el adaptador de la máquina virtual? Saludos, -- Camaleón
Re: NAT sobre WLAN
El 08/06/16 a las 12:43, Camaleón escribió: El Wed, 08 Jun 2016 12:08:28 -0300, JAP escribió: El 08/06/16 a las 10:52, Camaleón escribió: (...) Un truco muy habitual que solían hacer los clientes de Ono (antigua operadora de cable en España) era clonar la MAC de todos los equipos de la red interna (de su casa) para poder acceder a Internet a través del cable-módem que la operadora les instalaba. Cuento esto porque quizá te sirva hacer lo mismo en tu caso, teniendo en cuenta que el portal cautivo es el que te impide la conexión, seguramente mediante técnicas similares de identificación de los clientes. He intentado tu consejo. El clonado hace que aparezca otra interfaz con la misma MAC, pero como es un Portal Cautivo ZeroShell, me pide la contraseña nuevamente, y por ende, no me deja tener más de una sesión abierta. Pues echa un ojo a ver cómo funciona ese portal, si conoces a tu enemigo podrás derrotarlo :-) The enemies of the Captive Portal http://www.zeroshell.org/hotspot-router/#issues Eso lo he estudiado a fondo, y por ello mi sistema tiene un script python en vez de andar trasteando con una pantalla del navegador siempre abierto. Lo que me "vuela" la cabeza, es que con VirtualBox, armé una NAT interna, y es transparente para las máquinas virtuales. ¿Quieres decir que desde una máquina virtual de VB te permitía acceder al portal? Sí. Accede en forma transparente. Por eso no entiendo qué estoy haciendo mal. Saludos,
Re: NAT sobre WLAN
El Wed, 08 Jun 2016 12:08:28 -0300, JAP escribió: > El 08/06/16 a las 10:52, Camaleón escribió: >> (...) >> >> Un truco muy habitual que solían hacer los clientes de Ono (antigua >> operadora de cable en España) era clonar la MAC de todos los equipos de >> la red interna (de su casa) para poder acceder a Internet a través del >> cable-módem que la operadora les instalaba. >> >> Cuento esto porque quizá te sirva hacer lo mismo en tu caso, teniendo >> en cuenta que el portal cautivo es el que te impide la conexión, >> seguramente mediante técnicas similares de identificación de los >> clientes. >> > > He intentado tu consejo. > El clonado hace que aparezca otra interfaz con la misma MAC, pero como > es un Portal Cautivo ZeroShell, me pide la contraseña nuevamente, y por > ende, no me deja tener más de una sesión abierta. Pues echa un ojo a ver cómo funciona ese portal, si conoces a tu enemigo podrás derrotarlo :-) The enemies of the Captive Portal http://www.zeroshell.org/hotspot-router/#issues > Lo que me "vuela" la cabeza, es que con VirtualBox, armé una NAT > interna, y es transparente para las máquinas virtuales. ¿Quieres decir que desde una máquina virtual de VB te permitía acceder al portal? Saludos, -- Camaleón
Re: NAT sobre WLAN
El 08/06/16 a las 10:52, Camaleón escribió: (...) Un truco muy habitual que solían hacer los clientes de Ono (antigua operadora de cable en España) era clonar la MAC de todos los equipos de la red interna (de su casa) para poder acceder a Internet a través del cable-módem que la operadora les instalaba. Cuento esto porque quizá te sirva hacer lo mismo en tu caso, teniendo en cuenta que el portal cautivo es el que te impide la conexión, seguramente mediante técnicas similares de identificación de los clientes. Saludos, -- Camaleón He intentado tu consejo. El clonado hace que aparezca otra interfaz con la misma MAC, pero como es un Portal Cautivo ZeroShell, me pide la contraseña nuevamente, y por ende, no me deja tener más de una sesión abierta. Lo que me "vuela" la cabeza, es que con VirtualBox, armé una NAT interna, y es transparente para las máquinas virtuales. JAP
Re: NAT sobre WLAN
El Tue, 07 Jun 2016 15:34:45 -0300, JAP escribió: > Tengo un equipo corriendo Debian "jessie": > # uname -a Linux javier 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 > (2016-03-06) x86_64 GNU/Linux > > ¿Qué quiero hacer? > Que los equipos conectados por WiFi a la placa wlan0 accedan a internet > a través de la placa eth1. > > > Tengo una red cableada a Internet: > # ifconfig eth1 eth1 Link encap:Ethernet HWaddr a0:f3:c1:01:da:92 >inet addr:192.168.2.52 Bcast:192.168.2.255 >Mask:255.255.255.0 inet6 addr: fe80::a2f3:c1ff:fe01:da92/64 >Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >RX packets:1523 errors:0 dropped:0 overruns:0 frame:0 TX >packets:1596 errors:0 dropped:0 overruns:0 carrier:0 >collisions:0 txqueuelen:1000 RX bytes:705060 (688.5 KiB) TX >bytes:299878 (292.8 KiB) > > Me conecto a dicha red mediante un portal cautivo provisto por un > servido ZeroShell, sobre el cual me identifico con un "script" en > python. > > Tengo una placa de red inalámbrica que provee servicio dhcp para mis > otros aparatos: > > En otro entorno más "natural", lo que he hecho toda mi vida, fue montar > un puente br0 desde eth1 a wlan0. > El problema que tengo es que en este lugar, debo pasar por el portal > cautivo, y el maldito no me permite más de una conexión con una mac > definida. Los puentes (bridges), generan una nueva MAC, y asignan > direcciones IP del servidor. Y como dije, con una clave, no puedo tener > más de una conexión. Y el BAFH no me da otra clave de acceso. (...) Un truco muy habitual que solían hacer los clientes de Ono (antigua operadora de cable en España) era clonar la MAC de todos los equipos de la red interna (de su casa) para poder acceder a Internet a través del cable-módem que la operadora les instalaba. Cuento esto porque quizá te sirva hacer lo mismo en tu caso, teniendo en cuenta que el portal cautivo es el que te impide la conexión, seguramente mediante técnicas similares de identificación de los clientes. Saludos, -- Camaleón
Re: NAT sobre WLAN
El 07/06/16 a las 18:59, fernando sainz escribió: ¿has habilidato el ip_forwarding? # Habilitamos el ip forwarding. echo 1 > /proc/sys/net/ipv4/ip_forward S2. Básico. Es lo primero que se hace. Es más, está habilitado desde el /etc/sysctl.conf. JAP
Re: NAT sobre WLAN
El día 7 de junio de 2016, 20:34, JAP escribió: > Estimados: > > Una vez más, yo peleándome con las redes. > Paso a explicar. > > Tengo un equipo corriendo Debian "jessie": > # uname -a > Linux javier 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) x86_64 > GNU/Linux > > ¿Qué quiero hacer? > Que los equipos conectados por WiFi a la placa wlan0 accedan a internet a > través de la placa eth1. > > > Tengo una red cableada a Internet: > # ifconfig eth1 > eth1 Link encap:Ethernet HWaddr a0:f3:c1:01:da:92 > inet addr:192.168.2.52 Bcast:192.168.2.255 Mask:255.255.255.0 > inet6 addr: fe80::a2f3:c1ff:fe01:da92/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:1523 errors:0 dropped:0 overruns:0 frame:0 > TX packets:1596 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:705060 (688.5 KiB) TX bytes:299878 (292.8 KiB) > > Me conecto a dicha red mediante un portal cautivo provisto por un servido > ZeroShell, sobre el cual me identifico con un "script" en python. > > Tengo una placa de red inalámbrica que provee servicio dhcp para mis otros > aparatos: > > En otro entorno más "natural", lo que he hecho toda mi vida, fue montar un > puente br0 desde eth1 a wlan0. > El problema que tengo es que en este lugar, debo pasar por el portal > cautivo, y el maldito no me permite más de una conexión con una mac > definida. Los puentes (bridges), generan una nueva MAC, y asignan > direcciones IP del servidor. Y como dije, con una clave, no puedo tener más > de una conexión. Y el BAFH no me da otra clave de acceso. > > Por lo que presto y diligente, decidí hacer una conexión NAT. > Para ello, monté un servidor dhcp con isc-dhcp-server, el cual da su > servicio a través de la placa inalámbrica: > # ifconfig wlan0 > wlan0 Link encap:Ethernet HWaddr 00:87:30:23:0e:a8 > inet addr:192.168.5.1 Bcast:192.168.5.255 Mask:255.255.255.0 > inet6 addr: fe80::287:30ff:fe23:ea8/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:265 errors:0 dropped:0 overruns:0 frame:0 > TX packets:861 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:12142 (11.8 KiB) TX bytes:60578 (59.1 KiB) > > Mi celular se conecta al enrutador configurado sin inconvenientes: > # ping 192.168.5.10 -c 3 > PING 192.168.5.10 (192.168.5.10) 56(84) bytes of data. > 64 bytes from 192.168.5.10: icmp_seq=1 ttl=64 time=150 ms > 64 bytes from 192.168.5.10: icmp_seq=2 ttl=64 time=195 ms > 64 bytes from 192.168.5.10: icmp_seq=3 ttl=64 time=203 ms > --- 192.168.5.10 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 1999ms > rtt min/avg/max/mdev = 150.223/183.033/203.074/23.394 ms > > > He intentado montar una NAT de no menos de 30 formas distintas, y no logro > hacer que el navegador del celular vea internet. > Las órdenes que he estado utilizando básicamente son > > iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE > iptables -A FORWARD -i wlan0 -j ACCEPT > > Que, si la teoría no me falla, enmascara eth1, y reenvía los paquetes que > vienen de wlan0. > > # iptables -t nat -L -v > Chain PREROUTING (policy ACCEPT 3 packets, 545 bytes) > pkts bytes target prot opt in out source destination > > Chain INPUT (policy ACCEPT 2 packets, 307 bytes) > pkts bytes target prot opt in out source destination > > Chain OUTPUT (policy ACCEPT 58 packets, 5878 bytes) > pkts bytes target prot opt in out source destination > > Chain POSTROUTING (policy ACCEPT 36 packets, 2841 bytes) > pkts bytes target prot opt in out source destination >22 3037 MASQUERADE all -- anyeth1anywhere anywhere > > Las reglas de iptables, las he variado en muchas formas, y realmente, ya no > sé qué hacer. > Otros ejemplo que he usado: > > iptables -t nat -A POSTROUTING ! -d 192.168.5.0/24 -o eth1 -j SNAT > --to-source 192.168.2.52 > > También: > iptables -t nat -A POSTROUTING ! -d 192.168.5.0/24 -o eth1 -j MASQUERADE > > Bueno. No funciona. > El teléfono no tiene accesos a internet. > Google no me da la solución. > > Escucho ofertas > > Muchas gracias en adelanto. > > JAP > ¿has habilidato el ip_forwarding? # Habilitamos el ip forwarding. echo 1 > /proc/sys/net/ipv4/ip_forward S2.
