Tag: Networking

mikrotik: failover gateway

2008/02/26 3 comentaris

Reading time: 4 – 6 minutes

Avui he refrescat una mica la meva memòria, feia algún que altre mes que no jugava amb els mikrotik. Doncs bé, per un client havia de montar un failover gateway i com que ja sabeu que sóc un fan declarat dels mikrotik per fer això he usat un RB150. Per si això ús sona a xinès segur que amb una petita explicació ho trobareu molt útil. Doncs bé, cada cop més empreses tenen dos sortides a internet i el que volen és que quan alguna de les dues sortides caigui l’altre sortida assumeixi tot el tràfic sense haver de tocar res.

Obviament per fer això el que hem de tenir és un element que s’encarregui de redirigir tot el tràfic cap a un router o cap a l’altre segons si la sortida a internet esta fallant o no. La solució que plantejo és molt simple i pot perfeccionar-se moltíssim. Per exemple, l’únic que explicaré és a usar un dels dos routers i quan aquest falla enviar el tràfic cap a l’altre però no és gaire difícil crear unes policy routes per balancejar tràfic entre els dos routers mentre aquests estiguin operatius. Però per no liar la cosa em quedaré amb l’exemple bàsic. A partir d’aquí, la base estarà més que feta perquè feu coses més xules.

escenari

El RB150 tindrà a l’ethernet 1 la xarxa LAN. A la ethernet 4 la WAN1 i a la ethernet 5 la WAN2. Amdues interficies tenen el router ADSL en monopuesto. O sigui, que tinc la IP pública a l’interficie del router.

funcionament

Per defecte, sortirem per la WAN1 i quan aquesta falli sortirem per la WAN2.

configuració

Assumeixo que les configuracions bàsiques ja estan fetes, o sigui, assignació d’IPs a interficies i l’enmascarament d’IP internes cap a internet. Això suposo que no té cap dificultat si algú necessita ajuda que avisi.

Creem dos scripts a llençar quan s’hagi de llençar la connexió via WAN1 i l’altre via WAN2:

Script per la WAN1:

:log info wan_1
/ip route set [/ip route find dst-address="0.0.0.0/0"] gateway=IP_GW_WAN1

Script per la WAN2:

:log info wan_2
/ip route set [/ip route find dst-address="0.0.0.0/0"] gateway=IP_GW_WAN2

Si ens interessa en cada un dels scripts hi podem afegir el que calgui. Per si no esteu habituats a treballar amb scripts al mikrotik els heu de colocar a /system scripts. Allà afegiu dues entrades i llestos. Com sempre això serà molt més còmode fer-ho des del winbox que no pas des de la cli.

Ara només cal que creem una entrada a l’eina netwatch, això es fa a /tool netwatch. A l’entrada li direm que faci pings cada un interval de temps que decidirem i que tingui un timeout fixe i si els pings no tornen llavors s’executarà l’script indicat. Bàsicament le entrades de netwatch tenen dos estats el up i el down i podem associar un script a llençar en cas de que hi hagi una oscil·lació cap a un dels dos estats. Això es fa així:

add host=208.67.222.222 timeout=10s interval=1m up-script=wan1 down-script=wan2 \
comment="Failover Gateway Script" disabled=no

El que fem és mirar si arribem a un dels servidors d’OpenDNS cada 1minut i ens esperem com a molt 10s perquè el ping torni. Després fixeu-vos com associem cada un dels scripts que em programat abans als estats d’aquesta prova.

Com podeu veure això és ben senzill, la gràcia esta en que jugueu amb els ECMP i els policy routing i feu del RB150 tot un balencejador de càrrega amb suport de fallides de línia. També és molt senzill que balancegeu el tràfic d’entrada d’internet cap a una ADSL o cap a l’altre, per fer això ús recomano que jugueu amb el DDNS que podeu actualitzar a través dels scripts comentats, només cal que li llenceu la petició d’actualitzar la IP associada al DDNS i els usuaris remots entraran per una o altre línia.

Evolution ‘search folders’

2007/11/22 2 comentaris

Reading time: 2 – 4 minutes

Aquesta funcionalitat d’Evolution fa molt temps que la vaig veure, però no se m’havia mai acudit com treure-li rendiment amb la meva forma d’usar el correu. Com sabeu de fa molt de temps tinc les carpetes organitzades intentant seguir la idea de GTD. Doncs bé, malgrat això tenia certs problemes per seguir alguns llistes de correu i d’altres informacions que m’arriben al correu però que són de caire més secundari o personal. La solució l’he trobat gràcies a aquestes carpetes tan especials que em permeten agrupar correus en funcionar de paràmetres ben diferents.

Per si això de les search folders ni ús sona, jo ho definiria com carpetes amb continguts virtuals, és a dir, imagineu que teniu configurades diverses comptes de correu, llavors tindreu divers carpetes d’entrada de correu (inbox) si a més cada una de les comptes té diverses carpetes creades això farà que els diversos inbox no capiguen a la pantalla. Llavors sempre haureu d’estar fent scroll per estar al corrent dels nous correus que ús entren en les diverses comptes i diverses carpetes de cada compte.

Llista de carpetes de tipus search folder:

La solució és tan senzilla com la de configurar, per exemple, un general inbox:

Un altre search folder que tinc configurada és una que m’agrupa tots els missatges que tinc marcats com a importants, això ho acostumo a usar moltíssim per varies funcions. Per exemple, contestar correus en llistes de correu, saber tasques importants que esperant que es facin ja, o coses importants que espero que arribin fetes, etc.

A més d’aquests dos exemples que he comentat tinc ues quantes carpetes més d’aquest tipus, com la de missatges no llegits, tasques a fer, tasques en espera, etc. a mi aquesta idea realment m’ha canviat la forma d’usar Evolution.

No oblideu que els missatges realment, no tenen perquè pertanyer a la mateix compte de correu i que la carpeta virtual no és una carpeta real. Així doncs, no s’hi poden arrossegar elements a dintre. De totes formes, si que es poden arrossegar correus de dintre cap a un altre carpeta, no virtual. Així doncs el focus de treball del meu Evolution ha canviat molt i ara treballo sempre amb la vista posada a la part on hi ha aquestes carpetes especials i a sobre tinc obertes totes les carpetes de la compte de correu principal. Així puc anar arrossegant i organitzant les tasques tal com feia abans.

pfSense deixava de re-enviar paquets misteriosament…

2007/09/23 No hi ha comentaris

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:

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.

pop2smtp: POP3 (“recojetodo”) a SMTP amb múltiples destins

2007/07/22 No hi ha comentaris

Reading time: 2 – 3 minutes

Alguns ISPs ens permeten tenir una compte que reculli tot el correu enviat a un domini, això per exemple es pot usar com a mail-backup del nostre domini. Doncs bé a través de fetchmail és molt senzill re-injectar el correu enmagatzemat a una compte POP3 a un servidor SMTP contra un usuari. El més complicat, és si el correu que hi ha a la compte POP3 pot anar a més d’un destí, com el que deia fa un moment en comptes POP3 tipus ‘recojetodo’ o cul de sac com diuen alguns.

Doncs bé, per això he fet un petit script en python que a partir d’un fitxer BSMTP modifica la companda RCPT TO en funció de la informació de l’etiqueta Envelope to que conté una llista de les comptes d’email destí a qui va dirigit el correu. Així doncs, bàsicament la tasca consisteix en buscar quines comptes d’email apareixen a l’etiqueta comentada i després borrem la comanda RCPT TO i creem tantes comandes d’aquest tipus com faci falta en el seu lloc per enviar copies del correu que volem enviar als seus destins. Aquest nou fitxer BSMTP modificat l’injectem al nostre MTA. Aquest MTA serà l’encarregat de processar aquest correus i entregar-los a les comptes destí.

En el meu cas he decidit fer un petit shell script que s’executa des del crontab cada 10min. Aquest script, Crida a fetchmail per obtenir el fitxer BSMTP amb el correu que hi havia a la compte POP3, després crida l’script de python per modificar el fitxer BSMTP d’entrada tal com he comentat i crea un nou fitxer BSMTP de sortida. Finalment aquest fitxer s’injecta via SMTP cridant un petit script que gràcies al NetCat envia per SMTP el contingut del fitxer BSMTP de sortida.

L’script amb l’estructura de directoris empaquetat en un fitxer: pop2smtp_r1.tar.gz.

Segur que hi ha formes més elegants de resoldre el problema, però la veritat no les he sabut trobar.

Servidor FTP darrera un NAT (pure-ftpd)

2007/07/05 No hi ha comentaris

Reading time: 2 – 2 minutes

Sovint quan montem un servidor FTP darrera d’un Firewall que fa DNAT per publicar els ports FTP (20, 21, tcp i udp) a internet ens deixa de funcionar l’FTP en mode Passive On. Llavors hem de fer allò tan molest i depenent del client tan difícil; o sigui, fer un Passive Off perquè la transmissió d’arxius, llistats de fitxers, etc. funcioni bé. Doncs avui cansat d’això en un servidor pure-ftpd que tinc montat a la feina i he posat solució ja que sinó tenia als tècnics molt limitats quan es trobaven a casa dels clients.

La cosa ha estat ben senzilla, només he hagut de llençar el pure-ftpd amb el paràmetre -p i especificar un rang de ports per on es faran les connexions passives. Jo he decidit que anessin entre el port 40000 i el 50000. Així doncs, el paràmetre ha quedat així: -p 40000:50000. Després al firewall he redirigit tot aquest rang de ports contra la IP interna del servidor i llestos (fent un DNAT). Ara ja funcionen perfectament els FTP passius.

Si tot això d’FTP passiu i no passiu, ús sona a xinès he trobat una petita web molt bona que explica la diferència entre un sistema i l’altre: Active FTP vs. Passive FTP, a Definitive Explanation (local).

Python: Reiniciem el router si no hi ha internet

2007/06/03 No hi ha comentaris

Reading time: 1 – 2 minutes

Malgrat fa uns dies vaig canviar el meu vell Zyxel per un Cisco 837 a casa, la línia ADSL es continua penjant per motius desconneguts. Ja que quan les dades no circulen ni amunt ni aball les interficies ATM estan aixecades i tot sembla funcionar correctament. Així doncs, no m’ha tocat altre remei que fer-me un petit script amb Python a través del qual cada 5min comprovo si tornen els pings contra un dels servidors de OpenDNS. Si això no és així llavors es connecta contra el router Cisco i el reinicia. Ja que he fet proves baixant i pujant la interficie ATM i no hi ha manera. No se m’ha acudit cap millor idea que llençar un reload.

L’script guarda un fitxer de log a /var/log/online.log i usa el modul pexpect de Python. La resta de coses que usa són moduls que van instal·lats per defecte.

Si a algú li pot fer falta l’script el podeu descarregar: router.py.

pfSense: amb una Intel Quad PRO/1000 cal una versió >1.0.1

2007/05/15 8 comentaris

Reading time: 2 – 4 minutes

Avui he patit una d’aquelles feines d’administrador tan tontes i que et fan perdre tan de temps. Havia d’instal·lar una Intel PRO/1000 GT QUAD PORT en un servidor Compaq Proliant DL320 per fer de firewall amb un pfSense i el coi de servidor no tenia CDROM. El problema de connectar-li un CD extern és que detectava la tapa oberta i no s’engegava un cop superat aquest tema, com que la BIOS és vella i propietaria, no permetia arrencar amb un CD IDE sinó que volia que uses la controladora que porta instal·lada especialmet per aixo sinó no podia arrencara des de CD per instal·lar el pfSense. Al final he tret un dels disc durs del servidor, encara sort que són IDE, l’he posat a un ordinador nomal i l’hi he instal·lat el pfSense al fer el canvi de PC tot perfecte. Només un però, resulta que la versió 1.0.1 del pfSense no reconeix de forma automàtica la versió GT de la targeta de 4 ports d’intel. Així doncs, he hagut de baixar-me la versió beta de la 1.2 del pfSense que ha carregat el driver em del FreeBSD que reconeix a la perfecció la targeta de 4 ports.

Realment una odissea de dia per fer una cosa ben senzilla. Ho comento perquè no perdeu el temps com jo intentant fer meravelles amb la versió 1.0.1 aneu directament a la 1.2 que malgrat estar en beta funciona molt bé. De moment diria que prou bé com per tenir-la en producció. El firewall finalment m’ha quedat amb 6 targetes de xarxa 2 a 100Mbps i 4 a 1000Mpbs. Dels 4 ports a 1000 n’hi ha 3 que hauran de treballar a plè rendiment quan hagi fet les proves d’estrés ja comentaré què tal. De totes formes, imagino que els resultats seràn excel·lents perquè FreeBSD realment és molt bo fent gestió de tràfic i més amb drivers tan madurs com el em per controlar el hardware d’intel.

Per cert, una altre odissea va ser trobar la targeta d’intel. Ja que malgrat fa molt de temps n’havia comprat una. De fet, el model que havia tocat era el MT i la que he montat avui és la GT, de fet ni el fabricant s’aclareix en decidir quina és la diferència real entre elles. Només anotar per si algún dia se’m torna a oblidar que les targetes les he trobat ben aprop de casa a un proveïdor de Vilafranca del Penedès que es diu ELPO. Bàsicament es dediquen al món dels SAIs però també fan de majoristes d’informàtica en general. El curiós és que en cap més distribuidor oficial de networking d’intel a l’estat la tenien ni me la volien portar.

Python trick: error Address already in use

2007/04/27 No hi ha comentaris

Reading time: 1 – 2 minutes

Quan treballem amb sockets en python sovint al publicar un port si matem el procés que publicava el port encara que sigui de forma correcte ens trobem que al llençar-lo de nou, o sigui, a l’intentar publicar altre cop el procés aquest dona error un error que diu algo així com Address already in use. O sigui, que el sistema operatiu es pensa que el port encara esta sent publicat pel procés que ja em matat. Si fem un netstat veiem que el port no hi és, però encanvi fins al cap d’una estoneta (alguns segons o minuts) no hi ha manera de poder usar de nou aquest port.

Doncs bé, un petit truquillo perquè això no passi i el poguem usar a l’instant és fer això després de crear l’objecte de la classe socket:

# creació de l'objecte
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# afegim noves propietats a l'objecte
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

TCP bouncer o TCP relay digueu-li com volgueu

2007/04/24 No hi ha comentaris

Reading time: 1 – 2 minutes

Encara m’enrecordo fa quasi 10 anys que per entrar a l’IRC usabem aplicatius d’aquest tipus per tal d’spoofejar la nostre IP. Doncs bé, avui he hagut de montar un procés que fa el mateix que usaben en aquelles èpoques però aquest cop per temes més seriosos. Així doncs, perquè si a algú li cal una eina que re-envii una connexió TCP d’un servidor a un altre de forma estàtica simple senzilla i ben fet he trobat el tcpxd. Ell mateix permet llençar-se com a dimoni, suporta múltiples connexions simultanees de forma asíncrona, de fet les típiques funcions xorres de tota la vida i amb una sintaxis ben senzilla:

tcpxd 7802 10.0.0.1 7802

Són d’aquelles eines xorres que t’ajuden a sortir de més d’un embolic quan la potència del NAT del firewall, router o el que sigui que tinguem pel mig no ens permet fer el que volem.

mini-remember: dig i DNS

2007/04/17 No hi ha comentaris

Reading time: 1 – 2 minutes

Mai recordo aquest carai de paràmetre del dig:

oriol@mini2 ~ $ dig @80.35.31.228 joor.net axfr
; <<>> DiG 9.3.4 <<>> @80.35.31.228 joor.net axfr
; (1 server found)
;; global options:  printcmd
joor.net.               86400   IN      SOA     s0-ret.inforcomsoft.net. root.inforcomsoft.net. 2007041701 60 60 60 60
joor.net.               86400   IN      MX      20 s0-ret.inforcomsoft.net.
joor.net.               86400   IN      NS      oriol.joor.net.
joor.net.               86400   IN      NS      s0-ret.inforcomsoft.net.
joor.net.               86400   IN      NS      s1-ret.inforcomsoft.net.
joor.net.               86400   IN      A       83.175.213.75
adsl.joor.net.          86400   IN      A       62.37.147.231
bali.joor.net.          86400   IN      A       83.175.213.75
www.bali.joor.net.      86400   IN      A       83.175.213.75
dades.joor.net.         86400   IN      A       83.175.213.76
daphne.joor.net.        86400   IN      A       80.35.31.228
ftp.joor.net.           86400   IN      A       83.175.213.75
imatges.joor.net.       86400   IN      A       83.175.213.76
mail.joor.net.          86400   IN      A       83.175.213.75
medicinachina.joor.net. 86400   IN      A       80.35.35.228
oriol.joor.net.         86400   IN      MX      30 s0-ret.inforcomsoft.net.
oriol.joor.net.         86400   IN      A       80.35.31.228
s0.oriol.joor.net.      86400   IN      MX      30 s0-ret.inforcomsoft.net.
s0.oriol.joor.net.      86400   IN      A       80.35.31.228
tcm.joor.net.           86400   IN      A       80.35.31.228
webmail.joor.net.       86400   IN      A       83.175.213.75
www.joor.net.           86400   IN      A       83.175.213.75
joor.net.               86400   IN      SOA     s0-ret.inforcomsoft.net. root.inforcomsoft.net. 2007041701 60 60 60 60
;; Query time: 191 msec
;; SERVER: 80.35.31.228#53(80.35.31.228)
;; WHEN: Tue Apr 17 12:18:15 2007
;; XFR size: 23 records (messages 1)

Així que aquí queda el recordatori. Aprofito també per enllçar un petit manual que esta molt bé sobre el dig: Dig: consultando la configuración dns.