Author: Oriol Rius

MySQL crash

Reading time: 2 – 2 minutes

Per un dia que es posa a ploure i estic a casa treballant, tot un plaer per cert. S’ha posat a fer llamps i trons fins que ha marxat la llum uns 2s en un llamp que ha caigut ben aprop i el pitjor és que el SAI no ha tingut temps de fer saltar la bateria i se m’ha reiniciat el server. Cosa que tampoc seria tan greu si no fos perquè he perdut quasi 1h per poder re-iniciar el MySQL… bé per si a algú li passa algo semblan aquí tenius els sintomes i el remei.

Després de mirar els fitxers de logs de /var/log/mysql tan el mysql.err com el mysql.log. No he trobat res que m’indiques quin era l’error de fet, podriem dir que no hi havia res que parles d’erros. Així que m’he decidit a passar al mètode radical i veure quins errors donaven les cirdes a sistema que feia al llençar el servei:

strace -f -o mysql.trace /etc/init.d/mysql start

L’únic que he trobat és un petit inidcador de que el InnoDB no s’iniciava bé. Gràcies a aquesta pista he arribat fins als formus de gentoo on he trobat aquest post: MySQL doesn’t start anymore after upgrade to 4.0.25 tot i que le títol no és gaire indicatiu del meu problema, en un comentari he trobat la solució:

cd /var/lib/mysql
rm ib_logfile0
rm ib_logfile1
rm ibdata1

Tornem a llençar el servei i tot solucionat, s’havien corromput uns fitxers de logs que usa l’storage del motor de MySQL i al borrar-los s’han tornat a generar. Quin patiment per tanta tonteria.

Consum d’ampla de banda de l’OpenVPN

Reading time: 1 – 2 minutes

Com que he de montar algunes VPNs amb GPRS/UMTS i l’OpenVPN entre servidors i clients linux, doncs m’he decidit a fer una prova per fer les estimacions de costos d’aquests enllaços. Així doncs m’he ajudat de l’eina mesure feta pel pancake. Una d’aquelles petites meravelles que ens brinda el GPL. Doncs bé amb el codi que veieu he extret el següent calcul:

time ./mesure -i eth0 -K -p "tcp and port 443"
168
real    60m30.922s
user    0m0.004s
sys     0m0.004s

Com podeu veure he llençat el mesure durant 60min i 30s amb 922ms, el tràfic que s’ha cursat pel port 443 tcp que és on he aixecat i he parat l’VPN durant aquest temps ha estat de 168KBytes. Aquest tràfic sense que per dintre de la VPN passes cap dada meva, simplement dades del propi openvpn per tal de manterir l’enllaç aixecat.

Una altre dada que us pot interessar és que només per aixecar l’enllaç es consumeixen 16KBytes i per baixar-lo uns 2KBytes. Ara cadascu que tregui les seves propies conclusions sobre si és molt o poc.

blogcms v.4.0.0d

Reading time: < 1 minute

Nova versió del blogcms instal·lada, aquesta tarda m’he tirat unes 3h provant la nova versió, però sempre queden coses pendents. Així doncs si troveu alguna nova errada en el blog, o alguna cosa que no va, etc. Aviseu si us plau!

OpenVPN roadwarrior (client windows)

Reading time: 4 – 6 minutes

Com us comentava al meu anterior article OpenVPN roadwarrior (server i client linux) també podem tenir un roadwarrior de la nostre VPN funcionant amb windows. Així que us descriuré breument com configurar aquest client configuració que és pràcticament idèntica a la del client linux.

El primer que hem de fer és clar, és baixar el paquet de l’openVPN per windows, el podeu trobar a la web de l’openVPN GUI for Windows. Després de descarregar-lo el podeu instal·lar on més us agradi un cop fet això comença la part interessant.

NOTA: si llegiu la documentació de l’openVPN per windows veureu que no he col·locat els fitxers de configuració a les direccions on ell espera trobar-les. I tampoc uso la propietat de servei de windows que pot tenir el programa. Però si ho voleu fer com ‘deu mana’ només cal modificar les rutes i treballar amb el servei de windows encomptes del meu script. Però jo he preferit fer-ho així de cara a tenir un control més personal del programa. Odio la transaparència del windows, prefereixo el meu sistema. Tot són gustos.

NOTA II: els mac també tenen un client d’openVPN anomenat Tunnelblick GUI for mac OS X. Però no tinc el gust de disposar d’un mac per provar i explicar-vos com va, us haureu de conformar amb les instruccions de la seva pàgina web.

Certificiat client

Aquesta part és igual que en linux, o sigui, que podeu mirar el post que us comentava més amunt i sabreu com es fa. Un cop tinguem el certificat client i la clau privada, copiem aquests dos fitxers juntament amb el ‘root CA’ a una carpeta de windows. Jo el que he fet és crear-me una carpeta que es diu openvpn a l’escriptori i dins he creat el directori certs, on hi he copiat els tres fitxers.

Configuració del client

Dins de la carpeta openvpn que comentava dins del punt anterior he creat un fitxer de configuració que es diu local.conf amb el següent contingut:

client
verb 1
remote 2.2.2.2 443
dev tun
comp-lzo
nobind
proto tcp-client
ca ./certs/cacert.pem
cert ./certs/vpn-clientwin-cert.pem
key  ./certs/vpn-clientwin-key.pem

Com podeu veure el fitxer és pràcticament identic al de linux, només li he baixat el nivell de debug (verb 1) perquè aquí la sortida de logs es farà per consola i si pugem molt el nivell de debug ens ompla de bassura la consola.

Configuració interficie TAP/Win-32

Després d’instal·lar el paquet d’openvpn per win veureu que teniu una nova interficie de xarxa:

interficie.png

Aquesta interficie com podeu veure l’he renombra i l’he anomenat tun al fitxer de configuració que heu vist més amunt també uso la interficie tun i no la tap que és el nom del driver de l’interficie. La veritat no sé si hi té molt a veure això però havia tingut alguns problemes al configurar i al final m’ha quedat tal com veieu funciona.

Cal que tinguem la interficie configurada en mode DHCP, per tal de que agafi la IP de túnel automàticament:

configuracio.png

Script de llençament

Finalment el que m’he fet és un petit script (.bat) per llençar la VPN l’he anomenat vpn.bat i el contingut és tan senzill com:

cd "H:\Documents and Settings\Oriol\Escritorio\openvpn"
openvpn --config local.conf

Col·locar-me a la carpeta on hi ha tots els fitxers i després llençar l’openvpn informant-lo del fitxer de configuració que ha d’usar. És importnat indicar la carpeta de treball així el fitxer de configuració com podeu veure usa direccions relatives per referir-se als certificats. Molt més senzill que no pas haver d’escriure el ‘peazo’ directori absolut.

Depuració i proves d’ús

Aquí podeu fer les mateixes proes que amb el linux, també veureu que la interficie tun té el ‘cable de xarxa desconnectat’ fins que no es connecta l’VPN que passa a estar en mode ‘connectat’. Si feu un ipconfig /all des de la consola del windows també podreu veure la interficie tun amb la IP de túnel un cop connectada i si feu un route print les rutes estàtiques que li ha assignat el servidor de la VPN al crear-se la mateixa. Recordeu que això el servidor ho feia a través de la comanda push.

OpenVPN roadwarrior (server i client linux)

Reading time: 7 – 12 minutes

Doncs ja fa temps que sóc usuari de l’OpenVPN per mi un dels millors softwares per montar VPNs i pel que sembla no sóc l’únic, ja que a newsforge també es pot llegir un article que defensa el mateix: SSL VPNs and OpenVPN: A lot of lies and a shred of truth. Doncs bé fer un enllaç LAN2LAN ho podeu fer amb molt pocs segons, jo diria que amb menys d’1min. A més permet tan montar-les per tcp, com per udp, a més de passar per sobre de HTTP proxies d’això ja en parlaré en un altre article.

El que vull explicar aquí és com he configurat l’OpenVPN per poder connectar-me des de qualsevol lloc a la xarxa de casa (i d’altres xarxes que ara no venen al cas). L’autenticació i xifrat de l’enllaç el faré amb SSL/TLS. Així doncs quasi tot el que vaig explicar sobre CAs a l’article: HTTPs, SSL i Certificats en Servidor i Client – Webs privades amb una C.A. ho podrem aplicar aquí.

L’esquema del que anem a montar el podeu veure en el següent gràfic:

Certificats

Així doncs, anem a resumir el tema dels certificats, com que tenim un servidor i un client, hem de generar el certificat pel servidor i pel client, no cal generar el CA, perquè ja en tenim un de l’article comentat. Així que ens col·loquem al directori ~/CA i creem els 3 fitxers tal i com indica l’article al que ens referim.

Ara tindrem els 3 fitxers de rigor:

newreq.pem -> petició de certificat que fem al CA
newcert.pem -> el certificat que ens torna el CA, després de signar la nostre petició de certificat
newkey.pem -> la clau privada del nostre certificat

Només afegir un comentari: mentre creem els fitxers comentats ens demani el ‘Common Name’ podeu posar algún nom representatiu ara no estem lligats a un nom de domini com en l’article en el que ens basem per crear els certificats. Per tal d’organitzar-nos el que farem és renombrar aquests fitxers amb els següents noms:

newcert.pem -> vpn-server-cert.pem
newkey.pem -> vpn-server-key.pem

La petició de certificat la podem borrar si volem. No la farem servir. Per completar els fitxers que ens fan falta per montar el servidor només cal crear el fitxer de paràmetres Diffie-Hellman. Escencialment ens ajudarà a establir VPNs segures en canals no segurs mentre s’intercanvien les claus simètriques que s’usaran per fer la VPN. Recordeu que les claus assimètriques (certificats que usem) només es fan servir com a mitja per establir un canal segur per on intercanviar una clau simètrica molt més ràpida de xifrar/desxifrar pels extrems que ens permetran mantenir un canal segur i el més ràpid possible.

Bé doncs creem aquest fitxer de paràmetres Diffie-Hellman: (dh1024.pem)

openssl dhparam -out dh1024.pem 1024

Jo només l’he fet de 1024bits però el podeu fer tan segur com volgueu 2048, 4096 o fins on tingueu ganes d’arribar. Jo he preferit no carregar els sistemes amb claus inútilment llargues pel tipus de seguretat que necessito. Bé doncs, ara només cal que creem els certificats del client tal i com hem creat els del servidor i com sempre us recomano canviar-li els noms al nou certificat, jo faré els següents canvis de nom:

newcert.pem -> vpn-client-cert.pem
newkey.pem -> vpn-client-key.pem

NOTA: Si voleu tenir més d’un client que es connecti de forma simultànea a l’VPN heu de crear un certificat per cada client.

Fitxer de configuració del servidor OpenVPN

Ara que ja tenim els certificats apunt els copio al servidor al directori /etc/openvpn/roadwarrior/certs. Anem a veure que hem de fer per preparar el fitxer de configuració, que en Gentoo va a /etc/openvpn/roadwarrior, al fitxer l’anomeno local.conf:

verb 5
status /var/log/openvpn-status.log
user nobody
group nogroup
persist-key
persist-tun
local 2.2.2.2
port 443
proto tcp-server
dev tun
comp-lzo
ca   /etc/openvpn/roadwarrior/certs/cacert.pem
cert /etc/openvpn/roadwarrior/certs/vpn-server-cert.pem
key  /etc/openvpn/roadwarrior/certs/vpn-server-key.pem
dh   /etc/openvpn/roadwarrior/certs/dh1024.pem
server 10.0.1.0 255.255.255.252
keepalive 10 120
push "route 10.0.0.0 255.255.255.0"

Si anem per ordre, a l’inici l’únic que fem és dir-li el nivell de debug que volem que es guardi i a quin fitxer. Després definim que el procés openvpn que tindrem corrent al sistema no tingui privilegis sobre el linux (nobody:nogroup). La part on comencem a tenir informació interessant és on ens indica amb la comanda local quina és la IP del firewall que esta escoltant peticions i ens diu que ho fa pel port 443 i sobre protocol TCP. Pot semblar una mica raro que escolti en un port pensat per ser usat per HTTPs però tinc els meus motius, de totes formes si no us agrada el port el canvieu. En un altre article que parlaré de com montar VPNs sobre HTTP proxies explicaré el perquè del port 443. Després li diem amb quina interficie de túnel treballarem i que usarem compresió per les dades que hi passin.

Arribem a la part de certificats on com veieu usem tots els fitxers que em creat anteriorment i el cacert.perm que és el certificat del ‘root CA’ que varem crear a l’article al que em refereixo tota l’estona. A les últimes tres línies el més destacat és que li diem de quin rang han de ser les IPs de la interficie de túnel, això ho fem amb la comanda server i després amb la comanda push llencem una ruta estàtica que li dirà al client com arribar a la LAN que tenim connectada a l’interior de firewall.

Si ara llenço el dimoni de l’OpenVPN (/etc/init.d/openvpn start) puc veure com el port 443 de la interficie pública esta escoltant les connexions que li arriben això ho podeu mirar amb un netstat -lpn.

Configuració del client

Primer comentar que el fitxer de configuració estarà guardat a /etc/openvpn/casa/ amb el nom local.conf i els certificats de client els copiem a /etc/openvpn/casa/certs/, anem a donar un cop d’ull al fitxer de configuració:

client
verb 5
remote 2.2.2.2 443
dev tun
comp-lzo
nobind
proto tcp-client
ca /etc/openvpn/casa/certs/cacert.pem
cert /etc/openvpn/casa/certs/vpn-client-cert.pem
key  /etc/openvpn/casa/certs/vpn-client-key.pem

Com podeu comprovar la configuració del client és mínima, la part més important és la que amb la comanda remote indiquem quina és la IP pública i el port on hi ha el servei que ens ofereix la VPN. Fixeu-vos amb la comanda nobind on li diem que el client no ha d’estar escoltant a cap port, només obrir una connexió contra el servidor. Indiquem quins són els fitxers a usar pel certificat de client i el certificat de la ‘root CA’ i llestos, ja tenim el client a punt.

Per llençar el client, podeu igual que al servidor llençar la comanda /etc/init.d/openvpn start.

TCP vs UDP

Com podeu veure he montat la VPN sobre TCP però també es pot montar sobre UDP, és tan senzill com canviar la comanda proto tcp-server del servidor i proto tcp-client del client, per la comanda proto udp. Per traspassar alguns firewalls i per montar VPNs darrera de NATs sense redirigir ports és molt útil poder-la montar en NAT, ja us explicaré com es pot fer tot això amb un altre article.

Com ja he comentat abans si no us agrada el port 443, també es pot canviar pel que volgueu, no sé si a nivell de IANA es recomana usar algún port en concret per aquest tipus d’VPNs.

Depurar

Per veure quins són els missatges que treu el servidor ho podeu fer al fitxer que indica el propi fitxer de configuració, o sigui, /var/log/openvpn-status.log. Per veure els missatges del client podeu mirar el vostre fitxer de log’s general del sistema sovint: /etc/log/messages.

Si alguna cosa no us funciona us recomano que repasseu tots els passos comentats i que mireu els enllaços de les pàgines en que jo m’he basat per fer la meva configuració.

La prova

Com és lògic la prova de foc està en des del client fer un ping a una IP privada de la intranet de darrera el firewall, per exemple, si 10.0.0.1 és un server de la xarxa 10.0.0.0/24 doncs des del portatil fent ping 10.0.0.1 aquest ens hauria de tornar i si fem un traceroute -n 10.0.0.1 només hauria d’haver-hi dos salts, el firewall i el server destí. Perquè tota la comunicació va per dins el túnel i els salts que es fan per internet són transparents des de dintre el túnel.

Enllaços

Webs d’on he tret la informació per montar tot això:

Automontem el pendrive o les flash cards

Reading time: 4 – 6 minutes

pendrive.jpg

Si treballeu amb udev i us instal�leu el paquet autofs, amb quatre retocs al kernel i quatre l�nies de configuraci� podeu fer que quan us enxufeu un pendrive amb linux aquest es monti i desmonti autom�ticament. De fet, aquesta soluci� esta explicada de mil formes diferents en un munt de howtos i d’altres similars. Hi ha gent que arriba nivells de sofisticaci� brutals. Per� despr�s d’estar mirant ‘largo y tendido’ tota aquesta informaci� he decidit no complicar la cosa i montar algo ben senzill que em permeti anar per feina amb els pendrives i les flash cards; que �s el que m�s uso al port�til.

Doncs b� per comen�ar el que farem �s que quan es detecti que s’ha connectat un dispositiu de tipus /dev/sdX1 (sent la X=a,b,c,d,etc) que es monti autom�ticament. Com sabeu el sistema de fitxers virtual udev genera autom�ticament els fitxers que representen els dispositius i a m�s tamb� genera uns events que es poden capturar. Si voleu monitoritzar aquests events podeu executar la comanda udevmonitor i podeu provar d’enxufar i desenxufar, per exemple, un pendrive i veureu com es generen els events que comento.

Doncs b� el primer que he fet �s que es generi un symlink autom�tic al detectar-se una partici� en un d’aquests dispositius que comentava, per tal de que aix� passi nom�s hem de modificar el fitxer: /etc/udev/rules.d/00.rules per aconseguir la funcionalitat que comentava nom�s cal afegir-hi aix�:

BUS="usb", KERNEL="sd?1", NAME="%k", SYMLINK="pendrive"

Tal com comentava si busqueu una mica podeu millorar molt�ssim fent per exemple, que nom�s es generi el enlla� din�mic (symlink) si el dispositiu �s de la marca tal o qual, model no s� quin, o que sigui de tipus usb mass-storage, etc. B� doncs, un cop ja tenim l’enlla� din�mic ara el que farem �s que quan intentem accedir a aquest dispositiu es monti autom�ticament el dispositiu i que si passats X’s segons no s’ha usat el dispositiu que es desmonti solet.

Aix� que comento ho farem amb el autofs, per configurar el dimoni ho podem fer al fitxer /etc/conf.d/autofs jo l’�nic que he tocat del fitxer de configuraci� del dimoni �s el timeout per tal de que es desmonti als 2s de no usar-lo:

...
# additional options for automount, ie. timeout
daemonoptions = '--timeout 2'
...

Abans de llen�ar el dimoni, he modificat el seg�ent dels fitxers de configuraci� que es troben a /etc/autofs al fitxer auto.master he afegit aix�:

/var/autofs/removable   /etc/autofs/auto.removable

Despr�s he creat el fitxer auto.removable:

pendrive        -sync,dirsync,fstype=vfat,uid=1000,gid=100,umask=002            :/dev/pendrive

Amb aix� aconseguim que quan s’intenti accedir al recurs /dev/pendrive es monti a /var/autofs/removable/pendrive i despr�s per tal de mantenir l’estructura de directoris de tota la vida el que faig es crear un link a /mnt/pendrive que apunta a /var/autofs/removable/pendrive:

ln -s /var/autofs/removable/pendrive /mnt/pendrive

Ara si anem a /mnt/pendrive (cd /mnt/pendrive) i fem un ls veurem el contigut del dispositiu, potser el primer ls que feu no funciona doneu-li uns segons perqu� pugui reaccionar tot plegat, a mi em triga uns 3 o 4s entre punxar el dispositiu i poder-hi accedir. Si quan acabeu d’usar el pendrive sortiu del directori veureu que al fer un df -a ja no esta montat.

Com comentava hi ha milers de howtos molt millors que el que acabo de fer, per� jo amb aix� ja he sortit del pas. Alguns howto’s que podeu mirar:

Carregador universal per USB

Reading time: < 1 minute

Avui en Jordi m’ha regalat un carregador universal per USB, no saps quin mega-favor m’has fet nano amb el regalet, perquè sovint estic fart d’oblidar-me algún dels carregadors que necessito just quan no l’he agafat, qui no coneix la llei de Murphy.

carregador.jpg

GRÀCIES NANO!

efemeride: Checkpoint compra Snort

Reading time: 2 – 2 minutes

snort.gif

Després d’un dia sense parar de fer de tècnic ni 1s i he vist que sense adonar-me’n se m’havien fet les 21h i m’he dit mirat el bloglines i plega per avui. Però quina ha estat la meva sorpresa al mirar el bloglines i veure que com a primera notícia d’slashdot hi havia: Checkpoint Acquires Snort. Com sabreu Checkpoint es consideren els inventors dels firewalls i Snort és un IDS amb llicència GPL comercialment esta sent explotat per l’empresa sourceFire que si no m’equivoco és del mateix tio de tota la vida, del programador de l’Snort, vull dir.

Perquè tanta sorpresa per la notícia doncs bé com potser alguns recordeu jo vaig fer el projecte final de carrera sobre IDSes i concretament vaig treballar moltíssim amb Snort instal·lat sobre FreeBSD, tot i que també el tenia instal·lat a casa sobre Linux en aquelles èpoques. De fet, ja fa molt de temps que em vaig cansar de mantenir una eina que dona tants falsos positius com un IDS per un entorn domèstic com és el que tinc. Però realment m’ha emocionat veure que el programet ha progressat tan com perquè Checkpoint fassi “ric” al seu autor.

Noms de pagès

Reading time: < 1 minute

El Carles m’envia des d’anglaterra un link ben català, que si li posem el nostre nom i cognom ens diu com ens hauriem de dir a pagès: Generador de noms de pagès. Boníssim jo encara ric, per cert, el meu nom de pagès és: Tonet de can Fonoll.

pages.gif

NTP public servers

Reading time: 2 – 2 minutes

sunclock.gif

Doncs gràcies a les aportacions del brainstorm al blog, he descobert el pool.ntp.org, de fet ja el coneixia com a client, el que no m’havia plantejat era el senzill que resulta ser un servidor d’NTP (Network Time Protocol) del ‘public pool NTP servers’. Amb això m’asseguro que les meves xarxes més importants estaràn sempre amb els servidors horaris ben sincronitzats i a part passo a formar part de la xarxa pública de servidors NTP perquè tothom se’n pugui beneficiar.

Els serveis de sincronització horaria pels usuaris domèstics no s’acostumen a valorar però en aplicacions distribuides i sobretot si aquestes donen serveis empresarials (on hi ha calers en joc) el tema de tenir tots els dispositius de xarxa ben sincronitzats és vital. Imagineu-vos el caos que suposaria que un caixer automàtic anès amb el rellotge atrassat…. no vull ni pensar-ho. Doncs bé jo no tinc caixers automàtics però si quioscos i d’altres coses semblants distribuides que necessito que les transaccions que realitzen estiguin ben sincronitzades perquè després em quadri la caixa 🙂

Bé doncs, si algú vol afegir-se a la xarxa de la que us parlo passeu-vos per ntp.pool.org val la pena amb 5min esteu al dia i amb 5min més heu montat el vostre propi servidor NTP públic i esteu dins la xarxa. Com a curiositat les dues IPs on he montat els meus servidors horaris són: 80.35.31.228 i 83.175.213.76. Obviament pel port 123/UDP.

Scroll to Top