NAT sobre WLAN

[JAP]

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 -- any eth1 anywhere
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

[fernando sainz]

¿has habilidato el ip_forwarding?

# Habilitamos el ip forwarding.
echo 1 > /proc/sys/net/ipv4/ip_forward


S2.

[JavierDebian]

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

[Camaleón]

(...)

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

[JAP]

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

[Camaleón]

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

[JAP]

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,
>

[Camaleón]

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

[JAP]

El 07/06/16 a las 15:34, JAP escribió:

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 UNA CONEXIÓN A UNA
PLACA DE RED ASOCIADA A UNA CUENTA DE USUARIO, razón por la cual NO ES
POSIBLE UTILIZAR TÉCNICAS DE PUENTE (bridging), como describo en
http://wiki.debian.org/es/Compartir_red_fisica_con_WiFi

1. Instalar lo necesario

# aptiude install iw wireless-tools hostapd dhcp3-server

2. Configurar el enrutador

2.1. Modificar /etc/default/hostapd y activar la siguiente línea:

DAEMON_CONF="/etc/hostapd/hostapd.conf"

2.2. Modificar /etc/hostapd/hostapd.conf de la siguiente manera:

#######################################################################
interface=wlan0
driver=nl80211
auth_algs=1
ignore_broadcast_ssid=0
logger_syslog=-1
logger_syslog_level=0
hw_mode=g
ssid=MiWiFi #(Nombre del Punto de Acceso)
channel=11
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=ClaveMuyDificil #(Clave de acceso)
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
#######################################################################

2.3. Modificar /etc/dhcp3/dhcpd.conf de la siguiente manera:

#######################################################################
ddns-update-style none;
option domain-name "servidor.org";
option domain-name-servers 192.168.0.1;
authoritative;
log-facility local7;

subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.10 192.168.0.20;
option routers 192.168.0.1;
}
#######################################################################


3. Modificar /etc/network/interfaces con los datos de las TRES redes que
tengo:

#######################################################################
# /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

########
# WiFi Access Point Internet
auto wlan0
iface wlan0 inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255

post-up /etc/init.d/hostapd force-reload

########
# Intranet
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 10.18.5.50
netmask 255.255.255.0
network 10.18.5.0
broadcast 10.18.5.255
gateway 10.18.5.254

hostname MiTerminal
dns-search MiRed.org
dns-domain MiRed.org
dns-nameserver 10.18.1.101

########
# Internet
auto eth1
allow-hotplug eth1
iface eth1 inet dhcp

hostname MiOtroNombreDeTerminal
dns-nameserver 8.8.8.8
dns-nameserver 8.8.4.4

########
# Enrutamiento de base

post-up ip route change default via 192.168.2.1 dev eth1
post-up route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.18.5.254 dev eth0

########
# Enrutamiento específico (Éstas son dos máquinas en la red
# corporativa en las que a veces se pone lento el acceso
# si no indico la ruta taxativamente)

post-up route add -host 10.25.1.201 gw 10.18.5.254 dev eth0
post-up route add -host 10.95.1.205 gw 10.18.5.254 dev eth0

#######################################################################

4. Modificar /etc/rc.local con las reglas de IPTables:

#######################################################################
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.


# Configuración IPTables
# Eliminar todas las reglas
iptables -F
iptables -t nat -F
iptables -t mangle -F

# Configurar NAT
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth1 -j MASQUERADE

exit 0
#######################################################################

5. REINICIAR EL SISTEMA
Sí, a lo Winbugs.
Las órdenes "/etc/init.d/xxx restart" o "systemctl restart xxx.service",
a veces, NO FUNCIONAN COMO DEBIERAN.


De esta manera, queda todo configurado.
En el equipo que hace de enrutador, deberemos identificarnos a través de
un navegador en el portal cautivo ZeroShell para que la conexión se
habilite.
Una forma de automatizarlo, es mediante el guión python de
https://code.google.com/archive/p/zeroshell-autologin/downloads

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.

Gracias a todos.

JAP

[Camaleón]

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