oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: Networking

Netgear ProSafe SSL VPN Concentrator SSL312

Reading time: 4 – 6 minutes

NetGear SSL312Havia tingut l’oportunintat de veure funcionar aquest tipus de concentradors d’VPN en diverses ocasions però mai n’havia configurat cap. De fet, el model en concret del que us parlo el vaig descobrir a través de Tecnología Pymes. El que més em va sorprendre és la quantitat d’VPNs que gestionava i el seu preu, són 25 VPNs concurrents per uns 350€ de PVD. Després vaig estar mirant-me a fons el manual i les seves especificacions tècniques i crec que és una de les solucions més competitives per montar VPNs a usuaris remots (roadwarriors) de forma senzilla. En aquest cas, senzilla vol dir que no s’hagi d’anar usuari per usuari a configurar-los l’VPN. Sinó que ells mateixos simplement accedint a una pàgina web i amb un simple usuari/password més el suport d’un plug-in Java/ActiveX passin a ser un client de l’VPN.

Al accedir via web després de l’autenticació el dispositiu facilita un portal d’enllaços als usuaris on poden amb un simple clic accedir a aplicacions a través del navegador, per exemple, usant VNC, RDP, Telnet, SSH, IE i d’altres protocols l’usuari pot iniciar per exemple una sessió amb una aplicació que estigui en un servidor local: Word, Excel, ERP, CRM, Web,  etc. O sigui, que és ideal per quan tenim usuaris amb coneixements molt bàsics perquè els podem donar accés directe a les típiques coses que usaran i per l’usuari és molt senzill d’entendre. Obviament si no volem accedir via web a la xarxa remota ho podem fer des del sistema, o sigui, que per exmemple si obrim una consola podem llençar un ping sense problemes als servidors remots. No deixa de ser una VPN de les de sempre, però usant com a client el navegador.

Pel que fa al firmware que usa després de connectar-hi via RS232 he pogut veure que és un Linux, al qual pel mateix CLI serie podem tenir-hi accés i tocar el que ens convingui. Per cert, enlloc he trobat la configuració del port serie per connectar-hi però fent proves la que m’ha funcionat ha estat: 9600 8N1 no control de fluxe per hardware ni tampoc per software.

Al iniciar el router aquest portava un firmware força antic que no suportava Windows Vista i que només podia treballar amb clients IE via ActiveX. Però després d’actualitzar el firmware a la versió 2.3.03 no només ja es suporta el Windows Vista sinó que també funciona amb clients Linux amb Firefox usant un applet de Java. Això si hem de tenir permisos d’administrador perquè sinó no pot crear les rutes i d’altres similars al sistema.

# uname -a
Linux vpn0 2.4.20-br264 #25 Fri Nov 14 12:23:42 IST 2008 POLO unknown

Els usuaris de l’VPN poden estar guardats en diversos llocs:

  • Local user database
  • Microsoft Active Directory
  • LDAP directory
  • NT domains
  • RADIUS (PAP, CHAP, MSCHAP, MSCHAPv2)

A més disposa d’un sistema de grups i de polítiques de permisos que malgrat no ser res de l’altre món ens permet crear certs tipus de perfils restringint els accessos de forma simple i fàcil de gestionar als grups o usuaris.

Quan montem aquesta solució podem treballar de diverses formes. Diposa de dues sortides ethernet i podem treballar amb només una sortida:

topologia 1

o usant dues interficies de xarxa:

topologia 2

a partir d’aquí podem adaptar el sistema d’VPN al que més ens interessi dins de l’empresa.

Abans d’acabar només un apunt sobre el tema de la configuració. Cal dir que no és complicat de configurar, però en primera instància és una mica engorrós tenir tantes opcions i tan poc intuitives. Una bona recomanació és que no deixeu de llegir-vos atentament l’ajuda en línia (apareix a la part dreta) que es mostra en la WebUI de configuració.

Un altre cop doncs NetGear ens ha presentat un producte molt decent i recomanable, he de dir que és una marca que al igual que Linksys m’acostuma a deixar un bon gust de boca.

Pàgina del producte:  ProSafe SSL VPN Concentrator SSL312

pfqueue – GUI per la gestió de cues del Postfix

Reading time: 1 – 2 minutes

Amb el pfqueue podreu gestionar les cues del Postfix v1 i v2, a més de l’exim. Jo en realitat només l’he provat per la v2 de postfix. L’eina malgrat no ser molt ràpida és realment còmode i potent. En poques paraules facilita molt la feina de gestió de les cues. No és senzill jugar amb els IDs dels correus que tenim amb les múltiples cues de postfix. Posar-los en hold, reencuar-los, fer-los flush, eliminar-los, etc. Gràcies a aquesta interficie els veurem amb una llista poden fins hi tot fer clic sobre de cadascún per veure en detall la informació de contexte dels mateixos i el contingut. Després a través de les tecles d’accés ràpid a les accions podrem fer el mateix que si usessim la comanda postsuper i algunes coses més.

pfqueue screenshot

Aquesta eina l’he trobat disponible a Gentoo i a Ubuntu 8.04.1 però no a Ubuntu 6.06. Per altre banda, és realment senzill compilar-la i instal·lar-la en una 6.06 així doncs si realment teniu un postfix en aquesta distro ús recomano molt l’eina.

Després em pregunten perquè no m’agrada el Windows…

Reading time: 2 – 2 minutes

Aquesta tarda he patit un expedient X’s, de fet, tots estem acostumats a ser víctimes d’aquests fenòmens quan treballem amb ordinadors i si és amb Win encara més. La qüestió ha estat amb una placa IB830H. Aquesta placa porta embeded una Intel PRO/100 VE una targeta més que típica i tòpica en sistemes professionals. A més podria afegir que és una de les targetes que més m’agradan. Per si fos poc el seu suport en sistemes de Microsoft estan soportadíssimes, com no podia ser d’altre forma.

Doncs la qüestió és que després d’instal·lar els drivers que havia descarregat des de la web d’intel la targeta es detectava perfectament i si esnifava el canal fins hi tot veia a passar paquets però en cap cas la targeta rebia cap paquet.

Després de fer mil proves i canviar els drivers un munt de vegades, la cosa no ha canviat gens i quan ja estava apunt de llençar la toballola he provat una cosa tan estúpida i simple com:

  • Entrar a la BIOS
  • Desactivar la targeta de xarxa
  • Arrancar el Windows
  • Després apaguem
  • Tornem a entrar a la BIOS
  • Activar la targeta de xarxa
  • Tornem a entrar al Windows
  • … i ja va tot sense tocar res!!!

Increible, eh!? doncs això és el bonic que té el Windows. He de dir que com sempre passa durant tot aquest procés incert he arrencat amb una CD de Gentoo i la targeta de xarxa sense fer totes aquestes tonteries funcionava perfectament. O sigui, que rebia i enviava paquets sense problemes. Realment això és una altre prova de com el Windows és contraproduent en molts i molts sentits!

podcast 1×13: desafio networking [la solución]

Reading time: < 1 minute A pesar de que la solución se alcanzó y aplico durante los meses de agosto y septiembre, hasta hoy no he podido grabar la solución en este podcast. Espero que haya sabido explicarla bien y que quede claro como se ha hecho para solucionar el problema, sinó preguntad.

El meu primer package de pfSense ‘dd_adv’

Reading time: 4 – 6 minutes

Enllaç directe a la documentació:

En aquest article intentaré descriure quins són els passos que he hagut de seguir per fer un package pel pfSense. En aquest cas el package que he fet és la extenció d’una funció que ja té el pfSense però que no es comportava com jo necessito. Concretament estic parlant del servei de ‘dynamic DNS’. S’ha de reconeixer que el suport és per molts serveis públics, i de pagament, per publicar un nemónic per una IP dinàmica. Cosa que el fa molt bo. Però hi ha diversos comportaments del suport que té pfSense per aquestes funcions que no s’ajustaben a les meves necessitats. Tal com esta programat aquest suport el pfSense el que fa és agafar la IP pública de la interficie WAN i cada cop que aquesta canvia es fa l’actualització de la IP pública al servei de DNS remot.

El meu problema bé de dos llocs, per un costat la IP no la tinc assignada a la interficie amb internet, sinó a una altre interficie. Per altre banda, la interficie que té internet no té la IP pública assignada directament a ella sinó que la té un router que a través d’un procés de NAT li dona connectivitat a internet. Així doncs, el problema esta per un costat en saber sobre quina interficie accedirem a internet i per altre banda, quina és la IP pública a través de la qual s’accedeix a la xarxa. De retruc tenim encara un altre problema degut a que la IP pública no esta assignada a l’interficie del pfSense, suposo que és obvi que el problema és que no sabem quan aquesta canvia. Per tant, no sabem quan ho hem d’actualitzar al servei de DNS dinàmica.

La solució que he adoptat és crear un nou servei que a través d’un servei de pooling el que fa és anar preguntant de forma periódica a internet quina és la IP pública que té la nostre interficie. A més s’ha de poder seleccionar quina és aquesta interficie sobre la qual volem verificar quina és la IP pública. Ja que hem de forçar que el tràfic que es genera per descobrir la IP pública surti per la interficie que realment té connexió a internet. Aquesta casuística per extranya que sembli és molt habitual, perquè a una oficina o similar ens podem trobar amb la necessitat de tenir dues línies que van a internet, una que estarà a l’interficie WAN del pfSense i una altre que va per una altre interficie. Sovint a la interficie WAN hi tenim la sortida principal a internet i a una altre interficie la sortida de backup. Un exemple habitual en aquests dies que corren és usar una ADSL a la WAN i una altre sortida a través d’un router 3G de Vodafone o similar per una altre interficie.

Un cop ha quedat clar quin és l’objectiu del package de pfSense, aquest és l’aspecte del que volem aconseguir:

pfsense dynamic DNS advanced settings

La descripció dels passos per fer la configuració el teniu al wiki així si he de fer millores retocs, traduccions i similars crec que és un lloc més apropiat per posar-ho que no pas directament a un article al blog, perquè aquest acabarà sent massa llarg i difícil de referenciar, modificar i mantenir.

Vull destacar la poca documentació i exemples que té el pfSense sobretot pels nous desenvolupadors, ja que moltes vegades m’he hagut de posar a rascar codi o a posar-me a buscar en com ho havien fet altres programadors de ‘packages’ per saber com resoldre els meus problemes. Potser però el més difícil és la part de debugging del paquet ja que moltes vegades et troves amb problemes col·laterals de la programació del paquet que no saps com arreglar i que et fan perdre molt de temps. Per exemple, no sé per quin extrany problema en el procés de depuració deixava a tot el pfSense sense configuració i havia de reinciar i restaruar divereses vegades la configuració de tot el firewall per poder acabar trobant d’on venia el problema. El procés es fa tan llarg i pesat que acabes desesperante.

Zivios: Introducció

Reading time: 4 – 6 minutes

El mes de Juny vaig parlar-vos de la meva idea de com montar un sistea SSO, concretament era al podcast 1×10. Doncs Zivios malgrat no és literalment una implementació d’aquest sistema si que ens nutreix d’un munt d’eines per tenir un sistema que serveixi de base per aquella idea. De fet, serveix per moltes altres coses i potser la idea que porten els seus creadors és més semblant a crear un sistema de directori (tipus AD) que no pas només un sistema d’SSO. Però sigui com sigui, després d’experimentar unes quantes hores amb el Zivios crec que val la pena que ús en faci cinc cèntims.

Algunes de les funcions de Zivios són:

  • Identity managament
  • Single sign-on
  • User, group and computer provisioning
  • Remote management of services
  • Core Infrastructure Services (NTP,DNS, CA, etc)

El projecte esta encara molt i molt verd, tot just s’ha publicat la versió 0.5.1 i les he passat ‘canutes’ per fer coses ben simples o per entendre com usar l’eina degut a la seva poca documentació, tan és així, que fins hi tot vaig haver d’entrar al canal d’IRC que tenen com a suport a parlar amb alguns dels desenvolupadors perquè em donessin un cop de mà per entendre algunes coses. De fet, hi ha diverses coses que pretenc integrar amb Zivios que encara no hem funcionen. Però malgrat totes aquestes notes de poca maduresa del projecte, el tema promet moltíssim i l’enfoc que li han donat a les coses m’encanta.

Per començar, les eleccions de les aplicacions Open Source que han escollit ja m’han semblat un gran què: MySQL, OpenLDAP, Heimdal Kerberos, PHP5, Memcached, Python+Twisted, XMLRPC, OpenSSL i moltes altres eines que formen part del meu dia a dia. Així doncs, no suposa un gran problema anar a mirar les entranyes del Zivios per entendre com funcionen algunes de les seves parts. Totes aquestes eines es combinen en un model client-servidor per tal de poder administrar de forma centralitzada diverses funcions de les estacions de treball, servidors, serveis i d’altres.

Cal destacar també que els serveis que s’administren des de Zivios es poden ampliar mitjançant el desenvolupament de plug-ins. Per exemple, ja hi ha fets plug-ins per samba, asterisk i algún servei més. En el meu cas on estic posant més enfasi és en aconseguir integrar els servidors amb LDAP i Kerberos, així doncs puc tenir una base de dades d’usuaris, grups i autenticació pels accessos als servidors. A més a través de les ACL que té Zivios puc controlar qui pot i qui no entrar als servidors. Per altre banda, també he aconseguit connectar OpenFiler a Zivios, el problema que tinc ara és que no me’n ensurto amb l’autenticació però suposo que és qüestió de temps. Quan aconsegueixi combinar tot això i si els resultats són els esperats espero poder-ho montar com a plug-in.

Per posar un exemple pràctic i perquè es vegi la potència de la idea, podem des del panell de control web de l’eina donar d’alta una localització, dins una oficina, després els seus usuaris, grups d’usuaris, serveis, servidors i estacions de treball. Després podem sobre tots aquests agents definir per exemple, les extencions d’asterisk, els accessos als recursos compartits per samba, el seu sistema d’autenticació centralitzat, configuracions DNS, NTP i moltes d’altres configuracions tot de forma centralitzada còmode i senzilla d’aministrar. A més podem establir usuaris amb certs permisos d’administrador per delegar-los tasques que es podran gestionar des de l’interficie web.

Sota el meu punt de vista el projecte és molt ambiciós i veig difícil que pugui arribar a madurar prou com per poder fer tot el que s’apunta des d’un inici. Però sent pragmàtics només amb el que ja es dibuixa ara mateix i per gestionar les parts més comuns entre diversos sistemes ja em conformo. És a dir, com a evolució natural del sistema NIS i servei de SSO, crec que ja és més que vàlid. Després si puc fer que s’integri amb software appliances que uso de forma habitual crec que puc arribar a tenir un gestor de la infraestructura de xarxa més que decent. Quan parlo de software appliances ara mateix tinc al cap sobretot OpenFiler i pfSense.

TCP bouncer amb failover

Reading time: 2 – 4 minutes

Al projecte GATv2 fa un parell de dies que hi he publicat un subprojecte que anomeno tcp-fwd. Es tracta d’un petit i simple aplicatiu programat amb Python i Twisted. La funcionalitat és molt senzilla es tracta d’un bouncer TCP que en cas de no poder connectar amb el primer destí on re-enviar el tràfic TCP ho prova amb el segon, sinó el tercer i així fins a tants servidors com s’hagin definit. Si no es pot acabar establint la connexió es desconnecta l’enllaç TCP cap al bouncer. O sigui, el comportament és transparent pel client original. Pels que no estigueu familiaritzats amb la funcionalitat d’un bouncer la intentaré explicar. Es tracta d’un socket TCP que escolta en un port i actua com un reverse proxy. O sigui, quan rep una connexió acte seguis s’obre una altre connexió cap al servidor i si aquesta es pot establir llavors connecta la primera connexió amb la segona.

L’inconvenient més gran que veig en aquesta idea és que la connexió que arriba al servidor final no té com a origien la IP del client, sinó la IP del servidor que fa de bouncer això fa que el fitxer de logs del servidor final no tingui la informació IP del client que realment s’ha connectat. Malgrat axiò hi ha escenaris en que aquesta eina és molt útil, ja que no sempre el més important són aquests logs sinó que el client acaba obtenint el servei que volia de forma trasparent i el sistema de failover que uso sempre segueix la mateixa seqüència de prova i error per cada socket que s’obre, així doncs, el sistema de failover és instantani i no perd ni una sola crida.

Una de les aplicacions per les que l’estic usant és per fer l’entrega de correu a un postfix. Es tracta d’un servidor de correu que només fa filtratge de correu i els correus que passen els filtres s’entreguen al servidor de correu real de l’empresa, doncs bé, per saber quin és el servidor de l’empresa uso el fitxer de configuració /etc/postfix/transport on s’indica segons el domini el servidor on entregar el correu. Però no he sabut veure com dir-li més d’un servidor de correu on fer l’entrega. Així doncs, el que faig és posar com a IP i port de transport una IP localhost i un port al atzar, llavors el postfix entrega el correu al bouncer situat en aquesta IP localhost i és el bouncer que intenta connectar aquest socket amb algún dels servidors de correu interns. Per tant, el tema és completament transparent pel postfix i els servidors que reben el correu tenen la mateixa IP origen que si ho haguessin rebut directament del postfix.

Suposo que la idea ha quedat ben definida, sinó ja sabeu que podeu fer-me les preguntes que calguin. El codi del projecte el teniu a: tcp-fwd.

ssldump depuració de tràfic xifrat

Reading time: 2 – 2 minutes

Tothom coneix el TCPdump i fins hi tot hi ha gent com jo que l’usem a diari, de fet, no fa massa temps  vaig re-descobrir el TCPflow (ja l’havia descobert abans, però vaig cometre el gran error d’oblidar-lo). Doncs bé, el problema d’aquestes eines és que són molt útils per tràfic sense xifrar però quan es tracta de tràfic xifrat amb SSL/TLS com ara HTTPs o d’altres protocols que viatgen xifrats i volem saber perquè no funcionen hem de recorrer a eines com el ssldump.

SSLdump permet seguir el fluxe de les conexions TCP xifrades amb SSLv3/TLS. Obviament per aconseguir desxifrar el contingut de l’enllaç hem de facilitar-li els certificats corresponents a l’eina. Però no només ens permet depurar a nivell de dades que corren per TCP sinó que també ens dona informació del propi protocol de xifrat descrita de forma humana. O sigui, que podem saber si el problema de l’enllaç és produeix durant el procés de handshake, ChangeCipherSpec o dins del protocol.

El que jo feia fins ara per poder analitzar el contingut d’un protocol que viatge xifrat és ajudar-me de l’eina sslproxy. La qual feia de bouncer al servidor de protocol o al client, així doncs obtenia un tram de la conexió que no anava xifrat i a través del tcpflow o el tcpdump podia obtenir el tràfic en clar. La tècnica és enginyosa i útil però ferragosa en comparació al ssldump.

Huawei E960: router HSDPA de Vodafone

Reading time: 4 – 6 minutes

Huawei E960Aquesta tarda he estat provant el Huawei E960 de Voafone, després de l’experiència llarga i dur amb els Linksys WRT54G3G avui tocava descobrir el nou producte de Vodafone. Doncs bé, dir que venint dels Linksys que tants i tants problemes m’han donat, penseu que en tenim ara mateix instal·lats més de 200 i s’espera tenir-ne molts més en els propers mesos i la cosa esta lluny de funcionar bé. Per un costat els problemes de cobertura de l’operadora sobre els que no s’hi poden fer res i per l’altre el fet de que les targetes PCMCIA no acaben de funcionar massa bé ni soles ni amb el router Linksys com a host.

HSDPA router/modem Vodafone

Els problemes típics han estat connexions que el router no informava correctament amb els leds, problemes de bloqueix de SIM per excés de reintents després de que la configuració es guardés malament, molts problemes d’accés a l’interficie web per la configuració i moltes connexions en falç fetes pel propi router. O sigui, connexions no demanades, connexions demanades i no detectades, etc. Per no parlar de la pobre configuració del linux que porta el Linksys dintre que fan que el rendiment del petit switch que incorpora l’aparell funcioni prou malament amb d’altres linux connectats a ell.

Bé doncs, al que toca. El nou router de Vodafone no és pas la ‘panacea‘ ni la solució a tots els malts de caps, però de moment sembla molt més estable i el que ja salta a la vista és que aquest mateix article l’estic escribint connectat des de casa meva a 2.6Mbps que malgrat estar lluny de ser reals donen un bon servei. Així doncs, això pot ser una gran notícia per alguns torrelavidencs que no disposen d’ADSL per manca de qualitat en les seves línies.

Pros a favor del modem/router:

  • Pots connectar-hi un telèfon analògic i usar el router per trucar com si es tractés d’un fix
  • 4 ports ethernet, que sembla que funcionen millor que en el Linksys
  • CD d’instal·lació com a dispositiu Mass Storage USB dins el propi router
  • Alimentació amb connector USB tipus B, via port USB o via transformador
  • Suporta molts mètodes d’autenticació wi-fi, lluny de ser professional però destaca el suport d’WPA2
  • Molt compacte
  • No usa PCMCIA, per tant, disposa d’un compartiment especial per la SIM
  • Sembla estable, de moment
  • Bones orelles, o sigui, deu tenir una bona antena per aconseguir treure connexions HDSPA des del meu poble
  • Fàcil usar-lo en mode DMZ o redirigit conta un servidor/firewall

Contres:

  • No hem funciona com a modem USB a la primera al connectar-lo a un WinXP amb SP2, no he intentat arreglar el problema
  • Interficie web de configuració molt pobre i lletja, malgrat això sembla que funciona ràpid i bé
  • Firewall intern molt lamentable, lleig i limitat. Poc intuitiu el tema del NAT
  • No suporta DynDNS (o similars), el Linksys si que ho suportava

En poques paraules aquest és el meu anàlisis del dispositiu. Com ja deia no és per tirar coets però sembla que algo de millora si que és sobre el Linksys.

UPDATE: ahir estava una mica espès i no se’m va acudir enganxar el test de velocitat que vaig fer amb el dispositiu, aquí teniu el test fet des de casa meva al mig de la muntanya 😉

test speed of Huawei E960 from my home via Vodafone

podcast 1×12: mail-gateway (GatV2)

Reading time: 2 – 4 minutes

GatV2 es un servidor de correo para hacer smart-relay o para que se entienda mejor el concepto para usar como frontend del servidor de correo de la empresa o del ISP (backend). GatV2 nos filtra todo el correo UCE y nos ofrece una herramienta de gestión del SPAM.

El siguiente esquema ofrece una idea de donde estaría el GatV2:

GatV2 network schema

A través del podcast podreis seguir cual es el proceso que sigue un correo para pasar através del GatV2. Obviamente no es sencillo entender a la primera todo lo que hace pero a través de este gráfico (pinchar encima para zoom), de la explicación y de la documentación de la web del proyecto espero que podais comprender mejor el proceso.

inside GatV2 process

Para ver las capturas de pantalla a las que se habla durante el podcast pasarós por la documentación del proyeco GatV2.

Finalmente el podcast:

[display_podcast]

El podcast dur alrededor de 1h, así pues Jorge me ha ayudado a hacer una tabla de contenidos del mismo así pues, podeis ir directamente al minuto que os interesa del podcast gracias a la siguiente información:

  • Presentación: 0-1m44s
  • Historia: 1m44s – 3m
  • En que consiste: 3m – 8m15s
  • Los componentes: 8m15s – 24m20s
  • Como funciona: 24m20s – 42m49s
  • WebUI del DSPAM: 42m49 – 55m55s
  • Despedida y cierre: 55m55s – 56m56s

En los próximos dias publicaremos (Jorge y yo) el podcast dividido en pequeños MP3 en l página del proyecto GatV2 para mayor comodidad de los interesados en el proyecto.