oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: linux

Problema Sincronització NTPd (openntpd)

2005/11/11 No hi ha comentaris

Reading time: 2 – 2 minutes

Fa unes setmanes ús vaig explicar que havia posat dos dels meus servidors NTP (Network Time Protocol) al pool d’espanya. Doncs bé hi ha un servidor el 83.175.213.76 que s’em tenia greus problemes per mantenir el sincronis-me, ja que l’openntp si té un ‘desfasse’ massa gran no et sincronitza la màquina i per tant el meu score dins del pool és un desastre. Per tal de solucionar el problema ara llenço el dimoni ntpd amb el paràmetre -s. Si useu gentoo l’únic que heu de fer és afegir el paràmetre a:

# cat /etc/conf.d/ntpd
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/net-misc/openntpd/files/openntpd.conf.d,v 1.2 2004/11/22 15:27:51 vapier Exp $
NTPD_HOME=/var/empty
NTPD_OPTS="-s"

Aquí podeu veure les perdues d’score que havia acumulat el servidor:

ntp.png

Update:Des del canvi comentat podeu verure l’evolució:

ntp2.png

Update II he trobat aquesta ‘deducció’ que vaig fer jo solet de casualitat en un HOWTO d’OpenNTPD per Gentoo.

Gentoo Trick: module-rebuild

2005/11/11 No hi ha comentaris

Reading time: 2 – 2 minutes

El pof en el seu dia i la GWN (Gentoo Weekly News) en una de les seves últimes edicions ens han parlat algún cop d’aquesta eina tan útil i que mai recordo com es diu exactament. A més sempre és quan més la necessites, o sigui, quan fas un update de kernel. Serveix per algo tan útil com recompilar els mòduls que no són natius del kernel per la nova versió de kernel que ens acabem d’instal·lar, estalviant-nos el mal moment que hem passat tots de necessitar just el mòdul que controla el dispositiu que no estava suportat de forma genèrica pel kernel i just en aquell moment no tenim el mòdul compilat.

Suppose you’ve just booted into a freshly updated kernel. First of all,
check which packages are using modules that haven’t been built with the
new sources yet: 

module-rebuild list

and then you can rebuild them all by simply going:

module-rebuild rebuild

Per disposar del module-rebuild feu un emerge a:

*  sys-kernel/module-rebuild
      Latest version available: 0.5
      Latest version installed: 0.5
      Size of downloaded files: 0 kB
      Homepage:    http://www.gentoo.org/
      Description: A utility to rebuild any kernel modules which you have installed.
      License:     GPL-2

UPDATE 5/6/2006: fixeu-vos al fer el list que no sempre hi ha tots els paquetes que instal·len moduls a la vostre llista, per tant, us recomano que afegiu els paquets que tenen mòduls amb l’opció add de la companda module-rebuild a partir de llavors ja es recordarà ell d’aquesta dependencia en el rebuild.

Un ordinador Linux dins una CF

2005/11/06 No hi ha comentaris

Reading time: 2 – 2 minutes

Segueixo amb la meva línia de referenciar mini-ordinadors, aquest cop es trata d’ordinadors ecastats dins d’una Compact Flash (CF). Amb unes característiques força interessants i una filosofia d’ampliació certament impressionant.

  • 43 * 37 * 5 mm
  • Compact Flash Type II Card
  • 16 Bit CF expansion bus
  • Interfaces to CF cards
  • 32 bit Coldfire cpu 40MHz
  • 32 MB SRAM
  • 8 MB FLASH
  • ucLinux 2.4
  • RS-232
  • Motorola BDM port

Ideal per desevolupaments ràpids i per fer prototips de petits dispositius. A més al usar el bus CF, podem usar unes ‘plaques d’expanció’ que ens permeten endollar moltes altres CF compatibles: ethernet, wifi, bluetooth, gps, usb, gsm/gprs, camera, disc/storage, etc. La CF amb l’ordinador val uns ~200$ i els kits de desenvolupament de 400 a 600$ segons quants slots porti la ‘placa d’expanció’.

linux-cf.gif

Alguns links interssants sobre el dispositiu:

InterScan Messaging de TrendMicro problematic amb kernel 2.4 i ECN

2005/11/04 No hi ha comentaris

Reading time: 2 – 2 minutes

Tenia un problema amb un servidor de correu SMTP al qual no podia accedir des del servidor de correu de la feina. Encanvi des d’altres IPs del nostre mateix rang si que tenia accés al port 25/tcp d’aquest servidor remot. Doncs resulta que el servidor en qüestió té instal·lat un InterScan Messaging Security Suite de la casa TrendMicro i al servidor de correu de l’empresa jo hi tenia activat el ECN (Explicit Congestion Notification). El problema esta en que quan s’envia un “SYN” en el handshake TCP entre els nostres servidors el paquet TCP té activats dos flags més a part del ‘SYN’, el ‘W’ i el ‘E’.

Aquí podeu veure el que envia el meu servidor amb ECN, flags SWE:

14:12:31.257939 IP 1.1.1.1.44435 > 2.2.2.2.25: SWE 2986809236:2986809236(0) win 5840 <mss 1460,sackOK,timestamp 338497211 0,nop,wscale 0>

El que envia un altre servidor que no té ECN, flag S:

14:13:02.225358 IP 1.1.1.2.37876 > 2.2.2.2.25: S 3871099907:3871099907(0) win 5840 <mss 1460,sackOK,timestamp 3419720577 0,nop,wscale 2>

Per comprovar si realment tenim el ECN activat al kernel:

# cat /proc/sys/net/ipv4/tcp_ecn

Per desactivar el ECN del nostre kernel:

echo 0 > /proc/sys/net/ipv4/tcp_ecn

Només fent això la cosa ja ha començat a funcionar perfectament. Així doncs, dubto que mai a algú li passi algo tan enravassat com el que m’acaba de pasar però aquí queda explicat.

Feina, feina, feina…

2005/10/27 1 comentari

Reading time: 2 – 3 minutes

tux.png

ah! i més feina… si ens queda una estona lliure recorda: feina! ja tinc ganes de que arribi el pont, ah si!!! que pont vol dir fer festa… però jo? FEINA! com sabeu això normalment no acaba impedint que escrigui al blog però aquests dies els nivells ja m’estan superant com a persona. Tot i amb això tinc milers de temes que esperen sortir… així que paciència. El primer que em sap greu perdrem és la trobada de linuxeros penedesencs que es fa aquest cap de setmana :'(

M’hagués agradat poder penjar el cartell de la trobada però no me l’han enviat i m’he quedat amb les ganes de penjar-lo/tenir-lo… però bé segur que tindrem oportunitat de veure’l per algún dels blogs dels companys ‘pingüineros’. Apa que us vagi molt bé i espero veuren molta informació al forum.

Per cert, canviant de tema tinc pendent penjar el nou mapa de la xarxa sense fils del poble, ja que tenim dos nous punts, la cosa no para de creixer tot i que ara almenys per la meva part penso parar el creixement i intentar actualitzar la informació de la nostre xarxa a guifi.net.

Una altre novetat important a comentar i pendent encara, fins hi tot de provar, és que m’ha arribat la comanda de material de VoIP que s’ha fet des de guifi a xina. Jo m’he firat un tlf VoIP, que encara no en tenia cap de meu, un ATA i una altre targeta FXO.

Parlant de VoIP aquest dissabte he de montar una targeta de digium amb 4 ports FXO, per treballar junt amb la QuadBRI que us vaig comentar que havia montat. Tinc unes ganes boges de liar-me amb el tema.

nat traversal

2005/10/23 No hi ha comentaris

Reading time: 2 – 4 minutes

A vegades tampoc em funcionen les coses a mi, a què ve aquest comentari? doncs resulta que hi ha més d’un amic que em diu que li dona la sensació que sempre me’n surto de tot doncs bé. Aquí us parlo d’una eina que no he aconseguit que em funcionés tinc diverses teories del perquè però la veritat és que com que de moment no la necessito m’he cansat de seguir provant, o sigui, que de moment he de dir que no me n’he sortit a usar-la.

L’eina té molt bona pinta es diu nat-traversal serveix per connectar a ports de màquines internes que estan darrera de sistemes enmascarats (darrera de NAT). La web és molt explicativa i útil.

nat-traverse establishes connections between nodes which are behind NAT gateways, i.e. hosts which do not have public IP addresses. Additionally, you can setup a small VPN by using pppd on top of nat-traverse. nat-traverse does not need an external server on the Internet, and it isn’t necessary to reconfigure the involved NAT gateways, either. nat-traverse works out-of-the-box.

Tot i amb això trobo súper interessant la tècnica que usent fer entrar a través del NAT fins al PC que teoricament no té els ports públics:

1.Firstly, nat-traverse on host left sends garbage UDP packets to the NAT gateway of right. These packets are, of course, discarded by the firewall.

2.Then right’s nat-traverse sends garbage UDP packets to the NAT gateway of left. These packets are not discarded, as left’s NAT gateway thinks these packets are replies to the packets sent in step 1!

3.left’s nat-traverse continues to send garbage packets to right’s NAT gateway. These packets are now not dropped either, as the NAT gateway thinks the packets are replies to the packets sent in step 2.

4.Finally, both hosts send an acknowledgement packet to signal readiness. When these packets are received, the connection is established and nat-traverse can either relay STDIN to the socket or execute a program.

Jo concretament el que he provat és de redirigir un port amb el netcat, però el problema que crec que tinc és que jo no faig un ‘masquerade’ al firewall que tinc davant, sinó un ‘SNAT’ i per si fos poc abans d’arribar al firewall passo per un router intern, així doncs segur que hi ha alguna cosa pel camí que m’està estorbant, però com comentava abans com que de moment no necessito l’eina ja m’he cansat d’insisitir. Aquí queda el tema fins que realment em fassi falta o algú s’hi posi i em digui què tal.

OpenVPN roadwarrior over PROXY

2005/10/17 No hi ha comentaris

Reading time: 2 – 4 minutes

Com ja sabeu fa uns dies em vaig montar un sistema per poder anar pel món amb el portàtil i connectar-me a la xarxa interna de casa, des de qualsevol lloc. Doncs bé hi ha llocs on no tenim una sortida a internet sinó que aquesta és a través d’un proxy, a vegades fins hi tot autenticat. Fins hi tot ens podem trobar en que no tenim ni DNS a la xarxa en la que estem sinó que tot es fa a través de l’HTTP PROXY.

Doncs bé quan ens ho posen tan difícil també podem usar l’OpenVPN per connectar a casa i fins hi tot navegar per internet a través de la xarxa de casa disfrutant de tots els serveis de la xarxa i no amb els ports ‘capats’ com ens obliga el proxy/firewall de torn. L’únic que cal és modificar la configuració del client d’OpenVPN per poder sortir a través del proxy de torn contra el port del servidor de l’OpenVPN que tenim a casa.

Al document on explicava com connectar-nos per VPN a casa, sent nosaltres roadwarriors, vaig posar el servidor al port 443/TCP. Doncs ara veieu el motiu, la idea és que si el servidor esta en aquest port el servidor proxy ens deixa passar a través seu per connectar-hi pensant que on connecteu és una web segura (HTTPs), al accedir a un servei xifrat el proxy/firewall no poden inspeccionar els paquets que passen a través seu i podem establir la VPN usant com a protcol de transport el SSL.

A continuació encomptes d’ensenyar-vos una connexió real amb un proxy d’una empresa el que faig és usar un proxy públic dels que hi ha per poder navegar de forma anònima per internet. Si en voleu una llista la podeu trobar a: llista pública de proxies. Concretament per la configuració de prova jo he usat el 194.80.193.161 pel port 8082. Així doncs al fitxer de configuració del client he afegit:

http-proxy 194.80.193.161 8082

Per disimular encara més el rastre de la vostre VPN podeu usar les següents comandes i el firewall en qüestió, ni tan sols olorarà que monteu una VPN:

http-proxy-option VERSION 1.1
http-proxy-option AGENT "compatible; MSIE 6.0; Windows NT 5.1"

Molt senzill,oi? si el proxy és autenticat podeu consultar el man openvpn les comandes per enviar l’usuari i el password. A mi de moment no m’ha calgut.

Apa doncs ja poden anar posant servidors proxy i firewalls que nosaltres ens les continuarem empescant per sortir a internet com deu mana i no pas reduint internet al servei de web. Que tot i ser dels més usats sempre és limitadíssim.

MySQL crash

2005/10/13 No hi ha comentaris

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

2005/10/13 No hi ha comentaris

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.

OpenVPN roadwarrior (server i client linux)

2005/10/10 No hi ha comentaris

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ò: