Sep 23

pfSense deixava de re-enviar paquets misteriosament…

Reading time: 3 – 4 minutes

Intentaré explicar-vos un ‘expedient X’ d’aquells que ja tinc resolts, però que no tinc una explicació al 100% del comportament que tenia el pfSense davant del problema. La conclusió és que el pfSense descartava paquets per tenir massa connexions concurrents, però al ser connexions UDP costava identificar-les. El problema és que de forma completament misteriosa el pfSense descartava els primers X’s paquets cap a qualsevol IP. Aquesta número indeterminat, podia ser des de 2, 3 o 4 paquets fins a 100 o 200. O sigui, que hi havia moments on donava la sensació que s’havia perdut l’enllaç. Com a pecualiaritat de la configuració del firewall (pfSense) comentar que la targeta WAN estava en mode bridge amb la targeta de servidors d’internet. O sigui, que la DMZ rep el tràfic de les IPs públiques que allà hi han filtrat a través d’un bridge d’aquestes dues targetes de xarxa que he comentat.

Exemple, de la pèrdua de paquets que comentava. Ping realitzat a una IP d’internet (la de oriol.joor.net) des del propi firewall. Realment això d’operation not permitted em va tenir molt i molt desoncertat.

# ping 80.35.31.228
PING 80.35.31.228 (80.35.31.228): 56 data bytes
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
64 bytes from 80.35.31.228: icmp_seq=9 ttl=57 time=117.668 ms
64 bytes from 80.35.31.228: icmp_seq=10 ttl=57 time=86.728 ms

Des de qualsevol de les altres potes del firewall es patia el mateix efecte, fins hi tot si es feien els pings cap a la LAN. La solució vaig trigar quasi 48h en trobar-la, era una bogeria. Ja que al final per localitzar el problema varem aïllar el firewall d’internet i el fenòmen va deixar de passar.O sigui, ja mai passava això d’operation not permitted per molt tràfic que injectessim al firewall, no passava. Així doncs, gràcies a una molt bona idea del Manu varem tancar tot el tràfic des d’internet i varem anar obrint serveis cap a la DMZ, un per un. Fins que vaig descobrir que el servei d’NTP (123/upd) era el que probocava aquest extrany efecte al pfSense.

Després de diverses proves la conclusió, és que hi havia masses connexions concurrents contra el servei que comento. Així doncs, actualment el que he fet és filtrar el número de connexions que permeto contra aquest port:

pfsense.png

Aquestes opcions les podeu trobar editant la Rule, concretament a la sección on posa Advaced Options. Com podeu veure podeu deixar ben limitat quines connexions i quines no deixeu passar cap a un servei.

Potser el més important que he aprés d’aquesta història és no montar mai un firewall que no acompleixi la regla d’or: by default block all. O sigui, tanqueu sempre tot i ja anireu obrint a mesura que faci falta. Però a vegades per voler ser una mica més transigent ho fem alrevés i al final això s’acaba pagant, com en aquest cas. A mi ja no em tornarà a passar, espero que a vosaltres tampoc.

Nov 11

Problema Sincronització NTPd (openntpd)

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.

Oct 04

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.