MySQL crash
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
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
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)
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:
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:
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)
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
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: