OpenBSD: Autenticar usuario PPPoE Telefónica ADSL Colombia

Luego de la situación presentada hace dos dias acerca de la no respuesta en la resolución de la conectividad de una LAN atravezando los nat's entre la caja openbsd y el modem ADSL+ ZTE ZXV-W300 publiqué a un foro de OpenBSD-Colombia (hasta este momento no recibi sugerencias o comentarios algunos) y via identi.ca repliqué el mensaje a otras redes sociales. Desde Facebook un amigo y colega de años atrás, el Ing. Manuel Serrano "mañe" me comenta lo siguiente:

"Hola viejo wil, esto que tu estas intentando hacer se conoce como nat sobre nat, aunque te deberia de funcionar sin problemas te recomiendo que configures el modem adsl en modo bridge y le delegues la autenticacion pppoe a la caja con esto la ip publica sera full administrada por la caja y el modem zte solo estara practicamente trabajando en un 20%. Saludos..."

Le comentaba entonces a "Mañe" que estaría averiguando al respecto, que la solución anterior que habia logrado con triple-nat era a medias pero tenia total desinformación acerca de esa técnica. Me di la tarea de averiguarme un poco mas y fue asi cuando encontre información googleando. COn el temor de desconfigurar el modem ZTE, conversé con mi padre para que me facilitara un modelo Billion ADSL cuyos patrones de una tia por parte de papa le obsequiaron por que ya no lo necesitaban. Me traje el router... verifique las configuraciones de los patrones de la conexion ADSL (PVC0 VPI 0  VCI 35) y los registré junto con los MTU y anuncio de la puerta de enlace. Efectivamente ya la luz indicaba enlace DSL  y PPP pero algo ocurría y que habría olvidado, ya tenia el nombre de usuario PPPoE pero la contraseña.. cual sería... ?
Intentando recordar le colocaba los ultimos seis digitos de la cedula del suscriptor, los digitos completos y nada.. Luego de recoger todo entonces recordé algo que tenia que ver con la contraseña default de acceso a la cuenta de correo electrónico asignada pero me acosté a dormir... A la mañana siguiente antes de tomar rumbo a laborar, tomé el modem Billion y efectivamente logró autenticar el PPPoE. Las siguientes pruebas esa noche serían ya para verificar el mecanismo de bridge del modem y como dijo Manuel, hacerlo de tal forma que delegara sus actividades de Autenticación PPPoE, TCP/IP, enrutamiento y cortafuegos a un tercero (router Wi-Fi personal o en este caso la caja servidora con openbsd) [1]

En la próxima entrega, comentaré entonces la experiencia de lograr hacer que OpenBSD a través de la configuración de PPPoE en ella, me permitiese autenticar y/o asignar la dirección ip pública.
Hasta pronto.

[1] http://openbsd-wiki.org/index.php?title=PPPoE_Router_and_Firewall

OpenBSD: extraño caso de fallo de nat con PF

Bueno me encuentro en una situación a la que la he denomidado como
curiosamente extraordinaria. Tengo una box OpenBSD 4.7 con kernel
stable "GENERIC" y sistema base actualizado via cvsup:

OpenBSD 4.7-stable (GENERIC) #0: Mon Oct 25 07:25:13 COT 2010
    root@garagbsd.my.domain:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) CPU 2.00GHz ("GenuineIntel" 686-class) 2 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID,xTPR
real mem  = 527986688 (503MB)
avail mem = 502870016 (479MB)

imagenes:
http://www.flickr.com/photos/m0n0/4982033658/
http://www.flickr.com/photos/m0n0/4981450139/

Como lo observan es una box con hardware antiguo y limitado, y que el
sistema operativo "lo pone a andar" sin contratiempos y con
personalidad xD. Lo tengo andando en un cafe internet de mi padre como
cortafuegos,proxy y control de contenido, los dos ultimos operan sin
novedad. Ahora mi inquietud es que hay una regla especial dentro de
pf.conf que me está "mamando gallo" en ciertas condiciones.

Topología:
La conexión a internet es via ADSL de Telefónica, un modem ZTE ZXV10
W300 (feo con aspecto desechable!). los puertos LAN se asignan bajo
DHCP ( 32 direcciones a partir de la 192.168.1.2/24). Sigue entonces
la caja OpenBSD con interfaz rl0 (LAN con asignación manual
192.168.3.1/24) y rl1 (WAN asignada via DHCP desde el ZTE)
Efectivamente mi interfaz rl1 via dhcp recibe la dirección y con la
config defacto que viene con PF hace el NAT sin contratiempos desde la
misma caja. Pero si voy a una estación por debajo de la LAN de la caja
no me lo permite!. Este es la config pf.conf minimo qu usé para esto:

/etc/pf.conf
int_if="rl0"
ext_if="rl1"
localnet=$int_if:network
torrent="{ 6881:6999 }"
# scrub incoming packets
match in all scrub (no-df)


# Configuring NAT
# NOTE: This information is for OpenBSD 4.7. NAT configuration was
significantly different in earlier versions.
pass out on $ext_if from $localnet to any nat-to ($ext_if)


# Default deny
block in all
block out all


table const { self }
set skip on lo
antispoof log for $ext_if
block in quick from urpf-failed


# pass all traffic to and from the local network.
# these rules will create state entries due to the default
# "keep state" option which will automatically be applied.


pass in  on $int_if from $localnet
pass out on $int_if to $localnet


pass out on $ext_if proto { tcp, udp, icmp } all modulate state


# pass in log on $ext_if inet proto icmp to $ext_if
pass in log on $ext_if inet proto tcp to ! port { ssh,http
} synproxy state



Resumen hasta ahora: "Pienso que inexplicablemente algo ocurre entre
los "NAT's" del PF y del ZTE que no se entienden pa' nada!"

Debido a ello y revisando el FAQ oficial de openbsd con respecto al
tratamiento de NAT hago un cambio en la linea
pass out on $ext_if from $localnet to any nat-to ($ext_if)
comentandola y ajustandola por
match out on $ext_if from $localnet to any nat-to ($ext_if)

Yupi!, funciona el NAT con la estación debajo de la LAN :D pero pero
pero.. el tratamiento del pf.conf es insuficiente ya que las reglas de
block return out quick on $ext_if subsiguientes no hacen absolutamente
nada, no filtran no bloquean ya que ese cambio de forma para NAT no es
controlable con esos guiones.

==============================================
Topología: Segundo Intento!
No me doy por vencido y agrego entonces un router/AP Linksys por
debajo del ZTE y por encima de la caja openbsd.

ZTE-LAN: DHCP (IP:192-168.1.1) -> Linkys WRT54-RangeBooster WAN
(192.168.1.2), LAN DHCP (IP:192.168.2.1) -> openbsd wan
(IP:192.168.2.107) , LAN DHCP (IP:192.168.3.1)

En firmware propietario del LinkSys agrego una ruta estatica para
resolver la red 192.168.3.0 cuyo gateway es la interfaz wan de la caja
obsd (192.168.2.107). Entonces efectivamente el tratamiento de nat en
pf oficial usando

pass out on $ext_if from $localnet to any nat-to ($ext_if)

en el /etc/pf.conf Funciona permitiendome restringir entonces todo lo
demas y efectivamente poder controlar todo con mi pf

Como la ven, muy complicada la cosa ?.-..
finalmente, a que se deberá eso señores!, comentarios?

Compilando el Linux-Kernel con usuario "non-root!"

Leyendo el README que viene en las distribuciones fuentes del Linux Kernel encontré un tip interesante para compilar el kernel linux sin intervencion de root directamente. Esto se hace creando una carpeta local al usuario "non-root" donde generaremos la estructura de compilación del nucleo.

$ mkdir ~/build/kernel
$ cd /usr/src/linux-2.6.N
$ make O=~/build/kernel menuconfig
$ make O=~/build/kernel
$ sudo make O=~/build/kernel modules_install install


Recuerde especificar el nuevo nucleo y sus parametros necesarios para arrancar en /boot/grub/grub.conf

uso de GPU's en High Performance Computing

Hace un tiempo cuando apenas me asomaba al mundo de la computación de alto desempeño, gracias al amigo y colega bogotano Andres Calderon me enteré del tema de las GPUs y el impacto que estos estarían añadiendo a la computación en general.

Segun estas tecnologias de uso de GPU's para resolver problemas computacionales, son muchisimo mas eficientes que las mismas CPUs tradicionales que conocemos. Estos dispositivos Se adhieren a los servidores para "acompañar" el computo del procesador convencional y asi pulverizar hasta un cluster (al menos el orgulloso que tenemos lo deja ya lejitos) entonces.. pequeñito, con mas ahorro de energia para mas potencia computacional. 

En un principio el uso de GPUs se limitaba a la eficiencia de los graficos en 3D y caracteristicas similares como el antialiasing y el shading pero al darse cuenta que se podría aprovechar para computación en general se empezó a masificar y a popularizar mas el uso de esta tecnología en los principales centros de computo del mundo. Actualmente nVidia produce un pequeño dispositivo que en teoría será capaz de generar por si solo mas de 1TeraFLOP de potencia a menor tamaño consumo siendo entonces muy práctico y sobre todo mas refrigerado y eficiente que un cluster comptuacional que muchos conocemos. Interesante!

Veamos lo que dice la compañía Nvidia al respecto (Tomado de http://www.nvidia.com/object/GPU_Computing.html ):

What is GPU Computing?

 

 

GPU computing or GPGPU is the use of a GPU (graphics processing unit) to do general purpose scientific and engineering computing.

The model for GPU computing is to use a CPU and GPU together in a heterogeneous co-processing computing model. The sequential part of the application runs on the CPU and the computationally-intensive part is accelerated by the GPU. From the user’s perspective, the application just runs faster because it is using the high-performance of the GPU to boost performance. 

¿Hacia donde vamos a llegar?

http://www.nvidia.com/object/product_tesla_C2050_C2070_us.html

http://es.wikipedia.org/wiki/CUDA

http://es.wikipedia.org/wiki/GPGPU

http://es.wikipedia.org/wiki/Unidad_de_procesamiento_gr%C3%A1fico

¡Hay que seguir redactando experiencias!

Hemos vivido un invierno nefasto en esta zona norte de Colombia, muchisima lluvia y al parecer en Cartagena nos olvidamos de los mas afectados con estas "fiestas de la Independencia".

Bueno despues de mas de 7 meses volvemos a esta casa! retomando fuerzas, muchos apuntes y definitivamente hay que volver a escribir las experiencias del diario vivir en el universo de la información y computación. Intentare retomar este espacio para llenarlo de buena vibra con la firme convicción de transmitir el conocimiento lo mejor posible. En hora buena, bienvenidos.