Resulta que los websocket no pasan tan fácilmente por el proxy inverso. Llevan su burumba.

Aquí por ejemplo, haremos un proxy inverso con SSL para una aplicación que escucha por el puerto 8888.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

server {
   listen 80 default_server;
   return 301 https://$host$request_uri;
}


server {
  listen 443 ssl default_server;
   ssl_certificate /etc/nginx/nginx.crt;
   ssl_certificate_key /etc/nginx/nginx.key;
   location / {
      proxy_set_header        Host $host;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header        X-Forwarded-Proto $scheme;
      proxy_pass http://127.0.0.1:8888/;
      proxy_http_version 1.1;
      proxy_set_header Connection "upgrade";
      proxy_set_header Upgrade $http_upgrade;
      proxy_redirect default;
      proxy_read_timeout 1800;
      client_max_body_size 128G;
   }
}

Note como los encabezados Upgrade son seteados. Ese es el truco…

En el 5to infierno de infomed, con la vida detrás del proxy que ya he mencionado incontables veces; todo se vuelve difícil.

Por suerte freebsd ha mejorado en materia de soporte de proxy. Si bien en csh, basta con usar:

1
2

setenv http_proxy http://proxy.sld.cu:3128
setenv https_proxy $http_proxy

Operaciones de rutinas como pkg audit -F suelen fallar al ser ejecutadas por el cron. Setear el proxy de manera global es una opción; pero nunca ha sido de mi agrado. Por suerte, el nuevo gestor de paquetes de freebsd soporta proxy en su configuración.

El fichero de configuración está en una ubicación bien extravagante. Nada menos que en /usr/local/etc/pkg.conf. Los comentarios hablan por si solos, vale la pena mirarlos; no necesitarás leer manual ni buscar en google para darte cuenta que:

1
2
3

PKG_ENV : {
   http_proxy: "http://proxy.sld.cu:3128",
}

¡Establece el proxy!

Con eso pkg audit corrido desde el cron funcionará perfectamente. Además de las demás operaciones que requieran bajar contenido de internet; claro está.

OJO! Nota que al final de la declaración del proxy, lo que hay es una coma, NO un punto y coma. La configuración parece ser un json.

La técnica port-knocking o knockd para otros, es en mi opinión, pilar de la seguridad en cualquier servidor que use SSH. Aunque es bastante versátil y puede ser usado hasta para reiniciar servicios sin loguearte.

Una de las cosas que empece a extrañar en FreeBSD fue knockd, pero gracias a la flexbilidad de ipfw, podemos usar este poderoso software. En FreeBSD el fichero se encuentra en /usr/local/etc/knockd.conf.sample y el paquete se llama knock.

OJO!! Muy importante especificarle la interfaz por la cual va a escuchar.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

 [options]
         logfile = /var/log/knockd.log
         interface = xn0

 [openSSH]
         sequence    = 111,222,333
         seq_timeout = 9
         command     = /sbin/ipfw -q add 00001 allow all from %IP% to me
         tcpflags    = syn

 [closeSSH]
         sequence    = 222,111,333
         seq_timeout = 9
         command     = /sbin/ipfw -q delete 00001
         tcpflags    = syn

Nada, resumiendo, que el truco está en poner la regla con el número 00001. Recuerdas que ipfw te permite (casi te obliga a) especificar un número para cada regla. Pues usaremos ese numerito diminuto para ponerla de primera.

Los tipos ortodoxos criticarán que es una regla al tetón. Pienso que no vale la pena abrir solo el 22; si voy a pasar tanto trabajo, que se me abra la puerta completa.

Por cierto, junto con knock, viene un programita para hacer el knocking. Yo solía hacerlo con netcat pero knock es más cómodo.

1

   knock 192.168.3.1 111,222,333

En mi .bashrc, tengo esta función declarada.

1
2
3
4
5

 abrete_cesamo() {
    knock  $1 111 222 333
    ssh root@$1
    knock  $1 222 111 333
 }

No tengo que decirte que la combinación de puertos está de acorde al ejemplo de la entrada y que debes cambiarla por la que tu establezcas. Así de esa manera, hacerle SSH a un servidor es ejecutar abrete_cesamo ip.del.servidor Luego al terminar la sesión ssh, se ejecuta la secuencia de cerrado.

Y hablando de implementaciones raras de knockd!

En alpine linux, iptables está en /sbin, no en /usr/sbin. Sin embargo, el fichero de configuración tiene puesto que está en /usr/sbin/, lo cual, repito; no es correcto.

Además, tanto en debian como alpine. No importa que pongas en la configuración porque interfaz escuchará. Siempre lo hará por eth0. Para cambiar esta situación; debes:

En alpine linux, configurar la interfaz en el fichero /etc/conf.d/knockd

En debian, configurar la interfaz (y poner un 1) en /etc/default/knockd

Recuerda que en linux, el comando de iptables, viene con “-A INPUT”. Si tienes un firewall corriendo, obviamente que no pincha; por tanto, ponlo con “-I INPUT”.

Seguimos con bind…

No hace mucho le comentaba a alguien, a raíz de una duda que tenía el colega Paradyx; la manera correcta de configurar un servidor bind para una red que cuelga de infomed.

Le comentaba que no vale la pena usar un forward por defecto; que hacer del dominio ‘.sld.cu’ una zona forward sería más que suficiente. Digo esto porque infomed no resuelve ningún dominio que valla más allá de “.sld.cu”, por tanto, no vale la pena transferirle las sepetecientas peticiones que hacen cuanta mierda se conecta a nuestra red (especialmente android).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

options {
   directory "/etc/bind/";
   pid-file "/run/named/named.pid";
   listen-on { 10.1.1.1; localhost; };
   allow-transfer { none; };
   allow-update { none; };
   version none;
   hostname none;
   server-id none;
};


view lan {

   match-clients {10.1.1.0/24;};

   zone "localhost" IN {
      type master;
      file "localhost.zone";
   };

   zone "hcg.sld.cu" IN {
      type master;
      file "hcg.zone";
      notify no;
   };

   zone "sld.cu" {
      forwarders { 201.220.222.131; 201.220.222.132; };
      type forward;
      forward only;
   };

}; // view lan

Como mi dominio es hcg.sld.cu (subdominio de .sld.cu) lo declaramos ARRIBA del dominio sld.cu. El dominio hcg.sld.cu es una zona master, sin embargo, el dominio sld.cu es del tipo forward y entonces ahí declaramos los forwarders (los dns de infomed).

Así solo le reenviaremos a infomed, aquellas peticiones que sean para infomed.

En mi opinión esto no es necesario. Tanto así, que la zona donde infomed hace forward; la tengo para los servidores. En el caso de la zona para LAN, simplemente declaro los servidores de correo en un fakeroot y listo.

Acá en el 5to infierno de infomed, algunos usuarios; están acostumbrados a usar un “MUA” (léase “cliente de correo”) para alar el correo de infomed. Con el boom de la wifi, los médicos querían tener su correo de infomed en el puñetero cliente de correo de android/ios. Tras hacer un forward a los smtp y pop de infomed, el ancho de vianda se fue a la mierda. Por tanto, surgió la necesidad de chapiar el tráfico que va desde/hacia infomed. Por ejemplo, el tráfico smtp, es saliente (subida), sin embargo, el tráfico pop es entrante (bajada).

El servidor que uso como “router”, es un alpine linux. El trinomio bind, dhcp e iptables, sumado al kernel grsec; convierte en mi opinión a alpinelinux en la mejor opción para un router.

Entrando en materia. Tenemos un canal de 2 megabit (256 KB/s). Pero en HDSL, la subida es más triste que la bajada; y además, hay más gente bajando correo que subiendo. Por tanto, usaremos un canal para el smtp, más estrecho que el del pop. En este caso, eth0 será la interfaz donde está el router.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# reiniciamos las colas que hallan en eth0
# para empezar a trabajar en limpio
tc qdisc del root dev eth0
tc qdisc add dev eth0 root handle 1: htb default 30

# un canal de 256 KB/s lo partimos en dos
# una fracción de 10 KB/s y otro de 20KB/s
tc class add dev eth0 parent 1:  classid 1:1  htb rate 256kbps burst 5k
tc class add dev eth0 parent 1:1 classid 1:10 htb rate  20kbps burst 5k
tc class add dev eth0 parent 1:1 classid 1:11 htb rate  10kbps burst 5k

# lo que valla para el pop e imap, lo dejamos en el :10 con 20kbps
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 201.220.211.7 match ip sport 110 0xffff flowid 1:10
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 201.220.211.7 match ip sport 143 0xffff flowid 1:10

# lo que valla por el smtp, en el :11 de 10kbps
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst 201.220.211.39 match ip dport 25 0xffff flowid 1:11

Note como en el caso de lo que venga del “.7”, (src) de los puertos pop e imap (sport) pasarán por la cola 1:10. Mientras que en el “.39”, se usan las cláusulas dst y dport.

pero aquí NO terminan las aventuras de QoS

Resulta que el tráfico proveniente de las WiFi era apabullante para el servidor proxy. Mientras que de una IP de una máquina entran 3 peticiones, de la IP de un router wifi entran 30.

En un principio pensaba usar un delay_pool especial para estas ip, pero sería complicar más el esquema de delay_pool que funciona bien por usuarios. Por tanto, el tema de la bajada ya está cubierto. Ningún usuario puede acaparar todo el ancho de banda con una descarga. Sin embargo, 1’000 peticiones de basura (android con proxy configurado) ahogan al proxy. La medida fue, que el tráfico entrante de la wifi, no exceda los 200KB.

En mi caso, los AP usan la ip 10 al 15, por tanto, haciendo un pipe de dummynet y metiéndolos a todos en ese pipe: -que se fajen por los 200KB!

1
2
3
4
5
6
7

ipfw pipe 1 config bw 200KBytes
ipfw add pipe 1 ip from 10.1.1.10 to me
ipfw add pipe 1 ip from 10.1.1.11 to me
ipfw add pipe 1 ip from 10.1.1.12 to me
ipfw add pipe 1 ip from 10.1.1.13 to me
ipfw add pipe 1 ip from 10.1.1.14 to me
ipfw add pipe 1 ip from 10.1.1.15 to me

Una cosa que me jode, es que linux el tema de los múltiples DNS no los maneje bien. Por ejemplo, estamos en una LAN con red 192.168.1.0/24 y además, tenemos una conexión a internet.

Entonces seteas dos DNS en el resolv.conf y no pincha!

Además, si la situación es itinerante (vas a múltiples LAN) mantener la configuración DNS se vuelve un rollo. Aunque el networkmanager te permita configurarlo, volvemos a la situación anterior.

Solución, tenemos un bin con sus debidos forwarders para cada red. En mi caso, el /etc/named.conf me quedó así:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// vim:set ts=4 sw=4 et:
options {
        directory "/etc/bind/";
        pid-file "/run/named/named.pid";
        allow-recursion { 127.0.0.1; };
        allow-transfer { 127.0.0.1; };
        allow-update { 127.0.0.1; };
        version none;
        hostname none;
        server-id none;
        recursion yes;
        auth-nxdomain no;
        listen-on { 127.0.0.1; };
};


// la lan por su DNS local
zone "dominio.cu" {
  type forward;
  forwarders { 192.168.1.3; };
};


// lo demás por google
zone "." {
  type forward;
  forwarders { 8.8.8.8; 8.8.4.4; };
};

De esta manera, el dominio de la LAN (dominio.cu), será resuelto a través del servidor DNS 192.168.1.3; que es el de la LAN. Para eso usamos la zona “dominio.cu” del tipo forward y especificamos a 192.168.1.3 como su forward.

El resto, o sea, la zona “.”, será también del tipo forward y para este ejemplo, usamos los dns de google como forward.

Ahora solo te queda actualizar el /etc/resolv.conf y setear a 127.0.0.1 como tu servidor dns

1
2

# Generated by resolvconf
nameserver 127.0.0.1

Recuerda que cada configuración automatizada, actualiza este fichero. Te recomiendo que no te fajes con el fichero, si no que en cada conexión que desees usar tu servidor, se lo especifiques. Por ejemplo, con networkmanager, le dices a N conexión, que el servidor dns es manual y será 127.0.0.1. Si usas Gnome (NetworkManager), te recomiendo usar la utilidad nm-connection-editor. Te permitirá especificar el dominio de búsqueda, cosa que no he visto como hacer con el administrador de conexiones de gnome.