[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

NAT sobre WLAN



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


Reply to: