Cómo monté mi servidor - Empiezan los problemas serios: esto se cuelga

Ahora me tocaba hacer un cortafuegos y probar la seguridad, así que le hice varios nmap como de costumbre. Lo curioso fue que al cabo de varios nmaps empezó a tener los puertos cerrados. Me extrañó, porque aún no había puesto ningún IDS, pero luego descubrí -levantándome y sacándole de su sitio- que se había quedado colgado. (Quizás es un nuevo sistema de seguridad; lo he visto en acción en las últimas versiones de Windows).

No me costó mucho descubrir cuál era el problema, ya que al pasar archivos grandes por FTP pasaba lo mismo. Curiosamente, el ping -f lo aguantaba, pero los escaneos rápidos de nmap no. Usando las opciones de velocidad de nmap, vi que se colgaba sólo con -T3 para arriba, el -T2 ya iba bien. Lo característico del -T2 es que manda los paquetes en serie, o sea uno detrás del otro. -T3 ya empieza a mandar varios a la vez, y eso es lo que hacía que se colgara la tarjeta de red PCMCIA.

Comparar distancias entre ordenadores

Haciendo pruebas con el ping -f y otros descubrí el 'ping adaptativo', estaba en la primera página del man ping. La sintaxis es ping -A host y consiste en mandar pings lo más rápido que pueda sin perder paquetes. Eso no quiere decir 'muy muy rápido', sinó lo más rápido posible. Si ve que se pierden paquetes manda más despacio.

Mandamos un ping, que viaja a través del cable, llega a su destino y vuelve en forma de respuesta. Nada más llegar mandamos otro, y así todo el rato. Por el tiempo que tardan en volver podemos adivinar cómo de lejos está el destino. Naturalmente, depende de muchas condiciones, por eso no he hablado de medir distancias sinó de comparar. Las pruebas que he hecho en mi casa son creíbles y se corresponden con la topología de mi red.

Supongo que si se llaman ICMP echo request y reply es por esto; también podemos saber cómo de lejos está una pared por el tiempo que tarda en llegar el eco.

No pierdo el honor; arreglo lo del cuelgue

La verdad es que no tenía ni idea de por qué fallaba la tarjeta de red, sólo sabía que no era normal. Probé muchas cosas sin parar, porque no puedo ir diciendo por ahí que 'mi Linux se cuelga y no sé cómo arreglarlo'. Después de tocar muchas cosas y de compilar muchos kernels, descubrí la opción mágica que lo solucionaba:

Dentro de la sección de dispositivos de red, en la del 8139too, "RealTek RTL-8139 PCI Fast Ethernet Adapter support", hay una que pone "Use PIO instead of MMIO". Hay que activarla.

Ahora aguanta sin problemas un while :; do nmap -vv -P0 -T5 -p1-65535 -r amarok; done

iptables

Nada complicado; el servidor usará FTP y HTTP desde fuera y SSH desde mi ordenador 'grande' (cuya dirección MAC es estática y por tanto siempre corresponderá a la misma IP).

Además sólo analizo las conexiones nuevas (las que sólo tienen el bit SYN activado), acepto las de loopback, no acepto UDP, y sí que dejo ICMP request y reply. Todo lo demás lo ignoro (DROP). Las conexiones salientes las acepto (para que funcione el FTP) pero el forwarding no.

Me queda este script para ejecutar al inicio:

Cambios en el router

El ordenador destino por defecto es el grande, de nombre pc. Para el servidor sólo tuve que redirigirle los puertos 20, 21 y 80; el resto de puertos se refieren al ordenador grande.

Normalmente el router (OCR 812) tiene una página web de configuración en el puerto 80; la cambié al puerto 8000 de esta forma:

Cómo probé el virtual hosting yo solito

Ahora necesitaba probarlo todo un poco: pedí que me hicieran unos escaneos de puertos, pero aún me quedaba mucho por probar sobre lo de servir páginas distintas dependiendo de la página pedida.

Puse dos páginas diferentes: una para cuando se entrara por 172.26.0.11 y otro para cuando se entrara por 217.126.10.173. ¿Cuál es el problema? Pues que si yo, desde el host pc (172.26.0.2), intento conectar a 217.126.10.173, la petición llega al router, y éste debería redirigirla al servidor (172.26.0.11) aplicando el NAT, pero no lo hace. No lo hace porque está configurado para aplicar estas reglas de redirección de puertos sólo a las conexiones que vienen de la red ATM que tiene configurada, o sea de fuera.

Para simular conexiones desde fuera lo más cómodo es tener una shell en algún ordenador y conectar desde ahí, pero en ese momento no tenía ningún login y password preparados para eso. Lo que hice fue buscarme unos proxys de Telefónica, configurar mi navegador, y acceder a mi IP (pública). Entonces la petición sí que venía de fuera, y el router la redirigía al puerto 80 del servidor. Le dije al Mozilla que no usara proxy para acceder a los 172.26.0.*, y así ya podía entrar al mismo ordenador de dos formas distintas, y cada una recibiendo una respuesta distinta.