Lo hice y lo entendí

El blog de Vicente Navarro
28 feb

Configurando routers domésticos desde la línea de comandos con wget

En ocasiones puede ser útil cambiar alguna configuración de nuestros routers domésticos (ADSL, cable, etc.) desde línea de comandos, de forma que podamos hacer cambios de forma automatizada con scripts.

Por ejemplo, podríamos querer abrir el puerto SSH en el router al detectar un Port Knocking. O podríamos querer abrir un puerto sólo a ciertas horas; o sólo como parte de otra tarea.

También puede ser útil para configurar el WiFi (desactivarlo, activarlo, cambiarle la clave, etc.). En esta entrada vamos a ver, a modo de ejemplo, cómo desactivar o activar el WiFi de varios routers domésticos interaccionando con su interfaz web usando únicamente wget. Un Zyxel P660HW-D1, un Home Station Amper ASL 26555 y un Cisco EPC3825 serán nuestros conejillos de indias.

Los servidores web de los routers domésticos a menudo usan autentificación básica (caso del Zyxel y del Home Station). En otros casos usan cookies para mantener la sesión (caso del Cisco). En ocasiones, la sesión se identifica únicamente con la IP del cliente, de forma que no se permiten accesos concurrentes desde otras IPs (caso del Zyxel). Dichas peticiones pueden hacerse con POSTs (Cisco, Zyxel) o simplemente con parámetros en la URL (Home Station).

La extensión “Live HTTP Headers” para Firefox nos hará muy sencillo ver qué ocurre mientras usamos la web de configuración del router. El wget nos permitirá replicar las mismas operaciones desde línea de comandos.

Sigue leyendo »

08 feb

rdiffdir: Sincronizando directorios entre sistemas distintos sin usar la red

Imaginemos que tenemos dos directorios muy grandes (de decenas o cientos de GB) que queremos mantener idénticos en dos sistemas diferentes. Por ejemplo, podríamos pensar en un directorio con documentos profesionales que queremos sincronizar entre el PC de casa y el del trabajo o en un directorio con fotos familiares que queremos sincronizar entre el PC de tu casa y el de tu madre.

La idea sería que tras modificar los ficheros en uno de los PCs, pudiéramos copiar sólo los cambios al otro PC (que en principio sería poco volumen de datos) sin tener que copiar todos los ficheros cada vez (recordemos que hablamos de muchos GB de datos).

Si ambos sistemas están conectados por red (local, Internet), aunque puede haber otras soluciones diferentes, mi solución preferida sería usar rsync (Backups con rsync), disponible en Linux, Mac OS X y Windows/Cygwin.

También podríamos optar por almacenar los datos en “La Nube“, con Dropbox, Google Drive, Skydrive, iCloud, etc. Así, si modificamos algunos ficheros en un sistema, los ficheros modificados se actualizan en la nube y, posteriormente, en los otros sistemas. Pero ojo, imaginemos que manejamos 100GB de datos. Además de que necesitamos tener al menos dicho espacio contratado en nuestro proveedor de almacenamiento en la nube, resulta que para subir inicialmente 100GB a la nube con una conexión a Internet de 1Mbps de subida necesitaríamos varios días:

100.000.000.000 bytes / ( 1.000.000 bit/s / 8 bytes/bit ) = 800.000 s = 9,26 días

Si no tenemos rsync, ni almacenamiento en la nube, y tal vez ni acceso por red, habría quien copiaría todos los ficheros a un disco duro externo (cientos de GB) o tal vez quien llevara cuenta de qué ficheros han cambiado para copiar sólo esos a una memoria USB. Y posteriormente aún habría que volver a copiar los ficheros en el sistema destino…

Bueno, pues resulta que rdiffdir es una solución excelente a este problema. rdiffdir está escrito en Python, es parte de la aplicación duplicity (para hacer backups de directorios), se basa en rdiff y usa la librería librsync. Con rdiffdir podemos crearnos muy fácilmente un fichero que contenga sólo los cambios con el algoritmo de rsync y aplicar dichos cambios en el sistema que esté desfasado.

Usemos por ejemplo el caso del directorio con documentos profesionales que queremos sincronizar entre el PC de casa y el del trabajo para entender cómo lo haríamos con rdiffdir:

Partimos de un escenario en el que los directorios están perfectamente sincronizados en ambos sistemas. Acabamos de llegar al trabajo, y el directorio que queremos sincronizar contiene lo siguiente:

trabajo ~ $ find directorio/
directorio/
directorio/subdirectorio1
directorio/subdirectorio1/ficheroA.txt
directorio/subdirectorio2
directorio/subdirectorio2/ficheroB.txt

trabajo ~ $ cat directorio/subdirectorio1/ficheroA.txt
Prueba A

trabajo ~ $ cat directorio/subdirectorio2/ficheroB.txt
Prueba B

Antes de comenzar a trabajar, generamos un fichero con los checksums de los bloques de los ficheros y con la información de los directorios con rdiffdir:

trabajo ~ $ rdiffdir signature directorio signature_$(date +%y%m%d).rdiffdir

Y comenzamos a trabajar: editamos ficheros, añadimos ficheros y directorios, borramos ficheros…

trabajo ~ $ echo "Nueva linea" >> directorio/subdirectorio1/ficheroA.txt

trabajo ~ $ rm -rf directorio/subdirectorio2/

trabajo ~ $ mkdir directorio/subdirectorio3

trabajo ~ $ echo "Prueba C" > directorio/subdirectorio3/ficheroC.txt

y al final de la jornada, copiamos el fichero de firmas y generamos un fichero con los cambios:

trabajo ~ $ rdiffdir delta signature_130208.rdiff directorio cambios_$(date +%y%m%d).rdiffdir

Nos vamos a casa, copiamos el fichero de cambios, y lo aplicamos sobre el directorio:

casa ~ $ rdiffdir patch directorio cambios_130208.rdiffdir

y verificamos que, efectivamente, tenemos los cambios del día:

casa ~ $ find directorio
directorio
directorio/subdirectorio1
directorio/subdirectorio1/ficheroA.txt
directorio/subdirectorio3
directorio/subdirectorio3/ficheroC.txt

casa ~ $ cat directorio/subdirectorio1/ficheroA.txt
Prueba A
Nueva linea

casa ~ $ cat directorio/subdirectorio3/ficheroC.txt
Prueba C

Si pensamos hacer cambios en casa, habría que repetir el proceso: generar un fichero de firmas antes de empezar, y uno de cambios al finalizar.

Pero, ¡a ver si va a costar más el collar que el perro! ¿Qué ocupa un fichero de firmas de un directorio enorme? ¿Qué tarda en generarlo? Pues acabo de probar con un directorio con 22000 ficheros, 1400 directorios y 10GB y ha tardado sobre 6 minutos y ocupa unos 130MB: Un tamaño adecuado para poder transportarlo en una memoria USB.

duplicity está disponible en algunas distribuciones Linux (Fedora, Ubuntu, Debian). En otras, podemos compilarlo. También podemos usarlo en Windows bajo Cygwin. Hay que instalar previamente los paquetes python, librsync1 y librsync-devel y luego, sólo hay que bajar el fichero con las fuentes, descomprimirlo, entrar en él desde la shell de Cygwin y ejecutar:

python setup.py install

:wq!

01 feb

Desempaquetando el firmware de móviles y tablets Android de Samsung

Acabo de aterrizar en el mundo Android con un móvil y una tablet de Samsung. Es increíble la cantidad de movimiento que hay con las roms personalizadas… ¡Quién tuviera más un poco más de tiempo!

De momento, aún no me he decidido a probar nada “no oficial” hasta que entienda un poco mejor cómo funciona todo, pero sí que me he atrevido a probar a actualizar con el firmware oficial de otro país (Instalar Jelly Bean [4.1.1][OFICIAL][P5110XXCLK7]). Cuando he visto que el fichero del firmware era un fichero .tar.md5, no he podido resistirme a desempaquetarlo e intentar entender qué hay dentro.

Lo primero que uno se pregunta es que qué es eso de .tar.md5. Pues es simplemente un fichero tar con formato “ustar” (POSIX.1-1988) al que le añadirmos al final un md5sum de sí mismo (How to make an Odin flashable .tar from .img):

$ tar -H ustar -c image_1 [image_2 ...] > your_odin_package.tar
$ md5sum -t your_odin_package.tar >> your_odin_package.tar
$ mv your_odin_package.tar your_odin_package.tar.md5

La siguiente pregunta sería: ¿cómo podemos verificar la integridad de un fichero .tar.md5?

Podemos ver que el resultado del md5sum está claramente visible al final del fichero:

$ tail -c 100 P5110XXCLK7_P5110OXACLK7_HOME.tar.md5 | hexdump -C -v
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  65 63 39 66 61 34 62 31  38 66 64 31 36 35 38 63  |ec9fa4b18fd1658c|
00000030  62 30 61 36 65 39 62 31  63 62 39 66 66 32 62 63  |b0a6e9b1cb9ff2bc|
00000040  20 20 50 35 31 31 30 58  58 43 4c 4b 37 5f 50 35  |  P5110XXCLK7_P5|
00000050  31 31 30 4f 58 41 43 4c  4b 37 5f 48 4f 4d 45 2e  |110OXACLK7_HOME.|
00000060  74 61 72 0a                                       |tar.|
00000064

Sabiendo que la longitud de un hash MD5 es 128-bits (32 dígitos hexadecimales), el tamaño del nombre del fichero y que el md5sum deja dos espacios entre el hash MD5 y el nombre y añade un fin de línea (0x0a), podemos extraer el fichero .md5 leyendo sólo los últimos “32(MD5)+2(espacios)+1(0x0a)-4(.md5)+nombre del fichero” caracteres:

$ FICHERO_FIRMWARE=P5110XXCLK7_P5110OXACLK7_HOME.tar.md5
$ tail -c $(( $( echo -n $FICHERO_FIRMWARE | wc -c )+32+2+1-4 )) $FICHERO_FIRMWARE
ec9fa4b18fd1658cb0a6e9b1cb9ff2bc  P5110XXCLK7_P5110OXACLK7_HOME.tar

y verificar la integridad del fichero leyendo todo el fichero menos la parte del md5sum:

$ head -c -$(( $( echo -n $FICHERO_FIRMWARE | wc -c )+32+2+1-4 )) $FICHERO_FIRMWARE | md5sum
ec9fa4b18fd1658cb0a6e9b1cb9ff2bc  -

Una vez verificada la integridad del fichero, se desempaqueta como cualquier otro fichero tar:

$ tar xvf P5110XXCLK7_P5110OXACLK7_HOME.tar.md5
Sbl.bin
boot.img
cache.img
hidden.img
recovery.img
system.img

El fichero Sbl.bin es el Secondary Bootloader, del que se suele hablar a menudo en los foros de XDA Developers (por ejemplo: [LISTING] Firmware with Fixed (OS X Compatible) Secondary Bootloader (Sbl.bin)). El artículo “The Android boot process from power on” es una buena referencia para entender cómo es el proceso de arranque de Android.

El resto de ficheros .img son imágenes de las particiones de Android (Android Partitions Explained: boot, system, recovery, data, cache & misc).

Los ficheros boot.img y recovery.img contienen el kernel Linux y un initrd para arrancar el sistema. boot.img es el principal y recovery.img se usa para arrancar en modo recovery (en las tablets Samsung, suele ser arrancar con el botón de Power y el de “volumen abajo” apretados y en los móviles Samsung, suele ser arrancar con el botón de Power, Home y el de “volumen arriba” apretados).

Ambos ficheros están en formato Android Boot Images. Podemos desempaquetar dicho formato con abootimg o con el script del artículo Extracting, Editing and Re-Packing boot.img in Windows. Si nos decidimos por esta última opción, obtenemos los mencionados ficheros y las opciones de arranque que se le han de pasar al kernel:

$ ./split_bootimg.pl boot.img
Page size: 2048 (0x00000800)
Kernel size: 4385112 (0x0042e958)
Ramdisk size: 485026 (0x000766a2)
Second size: 0 (0x00000000)
Board name:
Command line: console=ttyO2,115200n8 mem=1024M androidboot.console=ttyO2 vram=20M omapfb.vram=0:16M androidboot.carrier=wifi
Writing boot.img-kernel ... complete.
Writing boot.img-ramdisk.gz ... complete.

$ ./split_bootimg.pl recovery.img
Page size: 2048 (0x00000800)
Kernel size: 4385112 (0x0042e958)
Ramdisk size: 1195680 (0x00123ea0)
Second size: 0 (0x00000000)
Board name:
Command line: console=ttyO2,115200n8 mem=1024M androidboot.console=ttyO2 vram=20M omapfb.vram=0:16M androidboot.carrier=wifi
Writing recovery.img-kernel ... complete.
Writing recovery.img-ramdisk.gz ... complete.

Los kernels de ambos ficheros son idénticos:

# md5sum boot.img-kernel recovery.img-kernel
89d3f9249d218e10e08f9b947188a76a  boot.img-kernel
89d3f9249d218e10e08f9b947188a76a  recovery.img-kernel

pero los initrd, no. Como es habitual en los initrd de los sistemas Linux de escritorio, es posible desempaquetarlos con “cpio -i -v” (o “cpio -t -v” si sólo queremos ver los ficheros que llevan):

gzip -d -c boot.img-ramdisk.gz | cpio -i -v
gzip -d -c recovery.img-ramdisk.gz | cpio -i -v

y veremos que más o menos llevan los mismos ficheros; con la particularidad de que el recovery.img-ramdisk.gz lleva además las típicas imágenes que componen la animación de cuando Android se está actualizando:

Android actualizándose

Finalmente, los ficheros cache.img, hidden.img y system.img son imágenes sparse de sistemas de ficheros ext4. Podemos convertirlas a imágenes normales con la utilidad simg2img (ver [REF] Unpacking and repacking stock rom .img files):

$ /tmp/ext4_utils/simg2img system.img system_normal.img

y ya montarla en modo loopback:

# mount -t ext4 -o loop system2.img /mnt/loop/

# ll /mnt/loop/
total 72
drwxr-xr-x  2 root root  8192 Nov 22 14:27 app
drwxr-xr-x  2 root 2000  4096 Nov 22 14:27 bin
-rw-r--r--  1 root root  2781 Nov 22 14:27 build.prop
drwxr-xr-x  2 root root  4096 Nov 22 14:27 cameradata
drwxr-xr-x 11 root root  4096 Nov 22 14:36 etc
drwxr-xr-x  2 root root  4096 Nov 22 14:27 fonts
drwxr-xr-x  2 root root  4096 Nov 22 14:27 framework
drwxr-xr-x  2 root root  4096 Nov 22 14:27 hdic
drwxr-xr-x  9 root root 12288 Nov 22 14:36 lib
drwxr-xr-x  4 root root  4096 Nov 22 14:27 media
drwxr-xr-x  4 root root  4096 Nov 22 14:27 tts
drwxr-xr-x  8 root root  4096 Nov 22 14:27 usr
drwxr-xr-x  8 root 2000  4096 Nov 22 14:36 vendor
drwxr-xr-x  4 root root  4096 Nov 22 14:27 vsc
drwxr-xr-x  2 root 2000  4096 Nov 22 14:27 xbin

Y en este punto, hemos conseguido acceso a todos los ficheros del firmware. Qué hacer ahora con ellos es otra, muy larga, historia…

Actualización 28/2/2013: He descubierto un interesante documento muy similar a esta entrada: HOWTO: Unpack, Edit, and Re-Pack Boot Images

:wq!

12 jun

Midiendo la calidad de la TDT en alta definición en España

Han pasado ya más de cuatro años desde que escribí “La TDT en alta definición en España: Llegará pero, ¿la podremos ver?“. La TDT en HD finalmente llegó; y aquellos que se compraron televisores nuevos que la soportaran, la pueden ver. Yo sigo con mi viejo televisor mastodóntico de tubo, que se sigue viendo fenomenal para contenidos de definición estándar. Pero recientemente, un familiar cercano se compró un buen televisor de los modernos, con muchas pulgadas y capaz de sintonizar TDT HD. Y con él, he tenido ocasión de comprobar detenidamente que la calidad de los contenidos en alta definición es notablemente mejor que los contenidos de definición estándar, pero que aún así, hay un abismo con la calidad de una fuente real de HD (como podría ser un Blu-Ray).

Es frecuente leer (HD sin hache, La Alta Definición en la TDT roza la ilegalidad en cuanto a calidad) que el problema de las emisiones de TDT en HD en España es que el bitrate es muy bajo (cuando no es que los contenidos son simplemente contenidos de definición estándar reescalados). He querido demostrar que realmente es así y me he puesto manos a la obra con mi viejo PC con la VIA EPIA SP8000E y sintonizadora Hauppauge WinTV-HVR-1100. Es fácil analizar en Debian las emisiones DVB-T gracias a los paquetes w-scan, dvbsnoop y dvb-tools.

Antes de empezar, conviene aclarar algunos conceptos del estándar DVB-T: En cada canal de radiofrecuencia de 8 MHz de los que tradicionalmente se usaban para la televisión analógica, el estándar DVB-T transmite un flujo de datos digitales (MPEG-TS) de entre unos 5 y 30 Mbps (en España típicamente 20 Mbps), en función de la modulación, codificación y otros parámetros (DVB-T: Available bitrates (Mbit/s) for a DVB-T system in 8 MHz channels). En ese flujo de datos, típicamente llamado múltiplex, se multiplexan en el tiempo varios flujos de datos de vídeo y de audio, permitiendo así que en cada múltiplex viajen varios programas de TV y de radio a la vez. Cada uno de los flujos de vídeo y audio tiene un PID (Program Identification) que lo identifica.

Pasemos ahora a medir el bitrate de los flujos de vídeo de las emisiones de TDT en España. Para usar los siguientes comandos se supone que tenemos una sintonizadora de DVB-T correctamente configurada en un sistema Linux.

Sigue leyendo »

25 nov

Pequeños trucos para Windows

Tengo por aquí apuntados unos cuantos pequeños trucos para Windows que he ido descubriendo últimamente y que me han venido muy bien. Me gustaría compartirlos en esta entrada.

Esconder un usuario de la pantalla inicial de selección de usuario

Cuando usamos Windows XP, Vista, 7, etc. con la configuración doméstica de por defecto (en la que sale una imagen para cada usuario y no en la que hay que escribir a mano el nombre del usuario), podemos querer ocultar alguno de los usuarios de dicha pantalla. Eso me pasó a mí recientemente tras instalar el servicio sshd de Cygwin en un Windows 7 (Servicios en Cygwin (syslogd, sshd, telnetd, ftpd, nfsd, etc.)): pasé de tener en la pantalla de inicio sólo el usuario habitual de Windows a tener también el usuario cyg_server (que aparece como Privileged User). Pude esconderlo con facilidad abriendo el regedit, yendo a:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon

y añadiendo una clave “SpecialAccounts” y dentro de ella otra llamada “UserList”. A continuación, dentro de:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\SpecialAccounts\UserList

creamos una entrada de tipo DWORD cuyo nombre sea el nombre del usuario que queremos esconder (en mi caso cyg_server) y con valor cero (0). Tras un reinicio, el usuario que no queremos ver deja de estar disponible.

Utilidad para configuración avanzada de usuarios

En Windows XP y Windows Vista, la utilidad estándar para configurar usuarios que encontramos en el Panel del Control es muy “doméstica” y le faltan muchas opciones. La utilidad típica de configurar usuarios que venía con Windows 2000 seguía estando en sus sucesores XP y Vista pero había que lanzarla a mano con el comando:

control userpasswords2

En Windows 7, la utilidad de gestión de usuarios estándar sigue siendo “doméstica” y la utilidad “alternativa” sigue estando disponible, aunque ahora hay que lanzarla con el comando:

netplwiz

Un dato importante es que desde esta utilidad no podremos lanzar la utilidad de gestión avanzada de usuarios y grupos locales en las versiones Home de Windows 7, sólo en las Professional, Ultimate y Enterpise.

Extraer los ficheros de un .msi

¿Te ha pasado alguna vez tener un fichero .msi de Windows Installer y necesitar extraer algún fichero de dentro pero sin querer instalar la aplicación? Sólo tienes que ejecutar este comando:

msiexec /a PathToMSIFile /qb TARGETDIR=DirectoryToExtractTo

Por ejemplo:

msiexec /a 7z920-x64.msi /qb TARGETDIR=c:\Temp\7z

El directorio destino se creará si no existe.

Obtener el BSSID y otros detalles adicionales de las redes WiFi al alcance

¿Necesitas saber más detalles sobre las redes WiFi que tienes a tu alcance y no tienes ninguna herramienta adicional, sólo las que trae Windows por defecto? En Windows Vista, 2008 y 7, ¡netsh te puede ayudar! (netsh está disponible en versiones anteriores, pero sólo en éstas lleva funciones de WiFi).

C:\Users\Usuario\Desktop>netsh
netsh>wlan
netsh wlan>show networks mode=Bssid

Interface name : Wireless Network Connection
There are 2 networks currently visible.

SSID 1 : Jazztel_A6
    Network type            : Infrastructure
    Authentication          : WPA-Personal
    Encryption              : CCMP
    BSSID 1                 : c4:75:0f:2b:b6:25
         Signal             : 52%
         Radio type         : 802.11g
         Channel            : 1
         Basic rates (Mbps) : 1 2 5.5 6 9 11 12 18 24 36 48 54

SSID 2 : WLAN_99
    Network type            : Infrastructure
    Authentication          : Open
    Encryption              : WEP
    BSSID 1                 : 01:21:c8:fe:6f:df
         Signal             : 63%
         Radio type         : 802.11g
         Channel            : 9
         Basic rates (Mbps) : 1 2 5.5 11
         Other rates (Mbps) : 6 9 12 18 24 36 48 54

Barra de inicio rápido (Quick Launch) en Windows 7

Aquellos de vosotros que, como yo, seáis unos reaccionarios de las nuevas interfaces de usuario (Windows 7, KDE 4, Gnome 3, Unity) seguro que renegaréis de la nueva barra de tareas de Windows 7 y tal vez tratéis de configurarla de la forma más parecida posible a lo que solía ser en versiones anteriores. En tal caso, seguro que os vendrá bien saber cómo volver a añadir la barra de inicio rápido.

Sólo hay que hacer clic con el botón derecho sobre la barra de tareas, ir a “Barras de herramientas”, elegir “Nueva barra de herramientas” y cuando nos pida la localización de ésta, escribir:

%userprofile%\appdata\roaming\microsoft\internet Explorer\Quick Launch

A continuación, haremos clic con el botón derecho sobre la nueva barra y quitaremos las opciones “Mostrar texto” y “Mostrar título” para tener una barra de inicio rápido como siempre.

Extender o reducir una partición NTFS de Windows

Imaginemos la siguiente situación bastante típica: Tienes un PC con Windows instalado en una única partición que ocupa todo el disco en el que queremos instalar, por ejemplo, alguna distribución de Linux. ¿Qué haríamos? Pues podríamos arrancar con cualquier LiveCD de alguna distribución de Linux que contenga el GParted (también tiene su propio LiveCD) y usarlo para hacer la partición de Windows más pequeña. Pero ahora, con Windows 7, también podemos usar el propio gestor de discos de Windows para hacerlo muy fácilmente. Lo lanzamos ejecutando:

diskmgmt.msc

Y aquí, haciendo clic con el botón derecho sobre cualquier partición, encontraremos opciones para reducir y ensanchar el tamaño de las particiones (siempre que estas operaciones sean posibles).

:wq!

04 nov

Mantener el reenvío de ventanas X de SSH tras hacer un su

Es muy común que sistemas UNIX/Linux a los que se accede por SSH no permitan acceso directo con root. Hay que autentificarse como un usuario normal y luego, si se necesita acceso de root, se usa su para obtener una shell de root. En sistemas con OpenSSH, en el fichero /etc/sshd/sshd_config encontraremos el parámetro PermitRootLogin, que está a “no” en muchos sistemas. Entre las ventajas de no permitir acceso directo de root está que el usuario -en teoría- no se pasará a root a menos que lo necesite y que queda registrado qué usuarios están/han estado en el sistema.

Pero esta configuración genera problemas con el reenvio de ventanas X11 a través de SSH. Por ejemplo, con sistemas HP-UX y Solaris (luego veremos qué pasa con Linux), cuando accedes por SSH con un usuario reenviando las ventanas X11 y luego haces un su, perdemos el túnel de X11:

$ ssh -X usuarioprueba@solx86
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
$
$ echo $DISPLAY
localhost:10.0
$
$ /usr/openwin/bin/xclock
$
$ su -
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
#
# echo $DISPLAY
#
# /usr/openwin/bin/xclock
Error: Can't open display:

Si ponemos a mano la variable $DISPLAY, el error pasará de ser que no puede acceder al display a que no tiene autorización para usar el display:

# DISPLAY=localhost:10.0
# export DISPLAY
# 
#  /usr/openwin/bin/xclock
X11 connection rejected because of wrong authentication.
X connection to localhost:10.0 broken (explicit kill or server shutdown).

Una solución, aprovechando que root puede acceder a los ficheros de todos los usuarios, es modificar la variable $XAUTHORITY para usar el fichero .Xauthority del usuario con el que entramos y no el de root:

# XAUTHORITY=/export/home/usuarioprueba/.Xauthority
# export XAUTHORITY
#
# /usr/openwin/bin/xclock

Al entrar a un sistema por SSH con la opción de reenvío de X11 activada, el servidor SSH añade una MIT-MAGIC-COOKIE-1 al fichero $HOME/.Xauthority para que sólo ese usuario (y no otros que estén conectados a la máquina e intenten usar el mismo $DISPLAY) pueda usar su túnel SSH para reenviar ventanas X11. Si el usuario root usa la misma magic cookie, pues podrá entrar sin problemas.

Otra opción para no reemplazar por completo el .Xauthority de root pasa por listar las magic cookies disponibles en el .Xauthority del usuario:

$ /usr/openwin/bin/xauth list
clientessh:0  MIT-MAGIC-COOKIE-1  e712f99f148d5bf00e5df9f345635434
sistemavncserver:1  MIT-MAGIC-COOKIE-1  d30c3ab6ca017837260ff6221fd80da7
solx86/unix:10  MIT-MAGIC-COOKIE-1  1d9076a2068a5e79d1259bea382cec2d

extraemos en formato binario sólo la entrada que nos interesa:

$  /usr/openwin/bin/xauth extract .Xauthority_solx86 solx86/unix:10

y ya como root, unimos la entrada a las existentes y ya podremos acceder al servidor X:

$ su -
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
# DISPLAY=localhost:10.0
# export DISPLAY
#
# /usr/openwin/bin/xauth merge /export/home/prueba/.Xauthority_solx86
#
# /usr/openwin/bin/xauth list
solx86/unix:10  MIT-MAGIC-COOKIE-1  1d9076a2068a5e79d1259bea382cec2d
#
# /usr/openwin/bin/xclock

Y otra opción más sería, tras listar las entradas existentes, simplemente añadir la magic cookie a mano en el .Xauthority de root:

# /usr/openwin/bin/xauth add solx86/unix:10  MIT-MAGIC-COOKIE-1  1d9076a2068a5e79d1259bea382cec2d
#
# /usr/openwin/bin/xclock

Decíamos que en Linux no tenemos este problema. Al pasarnos a root, la variable $DISPLAY se conserva y no necesitamos añadir la magic cookie para que el reenvío de ventanas X11, simplemente, siga funcionando:

# ssh -X usuariopruebap@rh5x64
usuariopruebap@rh5x64's password:
$
$ xclock
$
$ echo $DISPLAY
localhost:10.0
$
$ su -
Password:
[root@rh5x64 ~]# echo $DISPLAY
localhost:10.0

Esta magia de los sistemas Linux la proporciona el módulo PAM pam_xauth:

The pam_xauth PAM module is designed to forward xauth keys (sometimes referred to as “cookies”) between users.

Without pam_xauth, when xauth is enabled and a user uses the su(1) command to assume another user’s privileges, that user is no longer able to access the original user’s X display because the new user does not have the key needed to access the display. pam_xauth solves the problem by forwarding the key from the user running su (the source user) to the user whose identity the source user is assuming (the target user) when the session is created, and destroying the key when the session is torn down.

Así, en el fichero /etc/pam.d/su, típicamente encontraremos una línea como ésta:

session         optional        pam_xauth.so

El módulo guarda las magic cookies necesarias en diferentes ficheros $HOME/.xauth??????:

# xauth -f .xauthrBGj8r list
rh5x64/unix:10  MIT-MAGIC-COOKIE-1  aaceeca9bf499b5c85aba64a3ae42bd0

que, aunque normalmente se eliminan solos al salir, en ocasiones se quedan ahí abandonados. Por ello, en Google podemos encontrar bastantes casos de gente preguntando qué son dichos ficheros .xauthXXXXX y por qué tienen muchos.

Y para finalizar, una mención al Remote X Apps mini-HOWTO, en el que podremos repasar los conceptos básicos sobre cómo ejecutar aplicaciones X11 de un sistema en el servidor X de otro sistema UNIX/Linux.

:wq

20 oct

Port Knocking

Hace unas semanas leí por primera vez sobre el port knocking en “Security by Default: Una autenticación fuerte para Openvpn“. No conocía la idea y me ha parecido muy interesante y útil. Consiste en enviar una secuencia de paquetes a un sistema que active un servicio que anteriormente estaba cerrado.

Por ejemplo, cualquiera que tenga un sistema con un servidor SSH expuesto a Internet sabrá que no es nada infrecuente encontrar registrados diferentes intentos de intrusión en el sistema (en el /var/log/auth.log en un sistema Debian):

Oct 19 09:31:49 darkstar sshd[13481]: Invalid user fluffy from 202.102.XX.XX
Oct 19 09:32:02 darkstar sshd[13493]: Invalid user oracle from 202.102.XX.XX
Oct 19 09:32:08 darkstar sshd[13500]: Invalid user www from 202.102.XX.XX
Oct 19 09:32:17 darkstar sshd[13508]: Invalid user postmaster from 202.102.XX.XX
Oct 19 09:32:31 darkstar sshd[13520]: Invalid user file from 202.102.XX.XX

Si el servidor de SSH sólo permite autentificación por clave privada/pública (Autentificación trasparente por clave pública/privada con OpenSSH) podemos estar razonablemente tranquilos de que el intento de intrusión no tendrá éxito. Pero como nunca se puede estar seguro del todo, puede ser buena idea añadir, adicionalmente, un sistema de port knocking para abrir el puerto SSH sólo cuando realmente lo vayamos a usar.

En un sistema basado en Debian, esto se puede hacer muy fácilmente con el demonio knockd, uno de los paquetes oficiales de la distribución. Tras instalar el paquete, tenemos que editar el fichero /etc/default/knockd para permitir que el demonio arranque:

# PLEASE EDIT /etc/knockd.conf BEFORE ENABLING
START_KNOCKD=1

y especificarle cualquier opción que queramos usar, especialmente en qué interfaz tiene que escuchar si no es el "eth0":

# command line options
# KNOCKD_OPTS="-i eth1"

Hay que tener en cuenta que el knockd siempre ve los paquetes llegar, incluso si los puertos están cerrados y si alguna regla de iptables rechaza el paquete. Podríamos decir que se comporta como el tcpdump, en el sentido de que el interfaz se pone en modo promiscuo y ve todo lo que llega a él. Pero adicionalmente, según qué paquetes vea, ejecuta una acción. Por cierto, parece que no funciona poner dos interfaces con "-i eth0 -i eth1".

A continuación, tenemos que personalizar el fichero /etc/knockd.conf para especificar qué secuencia de puertos queremos y qué hacer cuando ésta llegue. En el “man knockd” encontramos interesantes ejemplos de uso, pero podemos centrarnos en el más típico que es el que instala Debian por defecto:

[openSSH]
        sequence    = 7000,8000,9000
        seq_timeout = 5
        command     = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
        tcpflags    = syn

[closeSSH]
        sequence    = 9000,8000,7000
        seq_timeout = 5
        command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
        tcpflags    = syn

Vemos que cuando llega una secuencia de paquetes TCP con el flag de SYN a los puertos 7000, 8000 y 9000 en menos de 5 segundos, el demonio knockd añade una regla de iptables para permitir el acceso al servicio SSH a la IP que ha hecho el port knocking. Y con otra secuencia, podemos cerrar el puerto posteriormente.

Tras configurar el /etc/knockd.conf a nuestro gusto, arrancamos el knockd con “/etc/init.d/knockd start“.

Para mandar la secuencia que active la acción podemos usar, desde otro sistema, el comando knock, que se instala también al instalar el paquete knockd:

[root@clientessh ~]# knock 192.168.100.2 7000 8000 9000

y en el sistema en el que hemos arrancado el knockd vemos cómo los paquetes llegan y se ejecuta la acción planificada para dicha secuencia:

Oct 19 21:55:17 darkstar knockd: 192.168.100.1: openSSH: Stage 1
Oct 19 21:55:17 darkstar knockd: 192.168.100.1: openSSH: Stage 2
Oct 19 21:55:17 darkstar knockd: 192.168.100.1: openSSH: Stage 3
Oct 19 21:55:17 darkstar knockd: 192.168.100.1: openSSH: OPEN SESAME
Oct 19 21:55:17 darkstar knockd: openSSH: running command: /sbin/iptables -A INPUT -s 192.168.100.1    -p tcp --dport 22 -j ACCEPT

El hecho de que podamos ejecutar cualquier comando nos da total flexibilidad. Por ejemplo, se me ocurre que en vez de, o adicionalmente a añadir o quitar reglas de iptables, también podríamos incluso arrancar o parar el demonio sshd:

[openSSH]
        sequence    = 7000,8000,9000
        seq_timeout = 5
        command     = /etc/init.d/ssh start
        tcpflags    = syn

[closeSSH]
        sequence    = 9000,8000,7000
        seq_timeout = 5
        command     = /etc/init.d/ssh stop
        tcpflags    = syn

Lo que nos quedaría por ver es qué alternativas tenemos para mandar la secuencia de puertos. Hemos visto que el propio paquete knockd de Debian lleva el comando knock. Pero, ¿hay alternativas? ¿y si queremos hacer port knocking desde Windows? ¿y si queremos hacerlo desde un sistema que no tenga ningún software especial?

La propia página de man de knockd nos sugiere algunas alternativas:

knock is the accompanying port-knock client, though telnet or netcat could be used for simple TCP knocks instead. For more advanced knocks, see hping, sendip or packit.

Una posibilidad para Windows también es el KnockKnock, descubierto gracias a “Add Port Knocking to SSH for Extra Security“:

pero un inconveniente del KnockKnock es que lanza la secuencia más de una vez:

Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: Stage 1
Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: Stage 2
Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: Stage 3
Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: Stage 4
Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: OPEN SESAME
Oct 19 22:38:32 darkstar knockd: Prueba: running command: /sbin/iptables -A INPUT -s 192.168.100.1    -p tcp --dport 22 -j ACCEPT
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 1
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 2
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 3
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 4
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: OPEN SESAME
Oct 19 22:38:33 darkstar knockd: Prueba: running command: /sbin/iptables -A INPUT -s 192.168.100.1    -p tcp --dport 22 -j ACCEPT
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 1
Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: Stage 2
Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: Stage 3
Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: Stage 4
Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: OPEN SESAME
Oct 19 22:38:34 darkstar knockd: Prueba: running command: /sbin/iptables -A INPUT -s 192.168.100.1    -p tcp --dport 22 -j ACCEPT

Si el comando a ejecutar se puede ejecutar más de una vez sin otros efectos, como es el caso del iptables, nos da igual, pero en otros casos, puede ser un problema.

Otra solución es usar el cliente de telnet de Windows contra los diferentes puertos para activar la secuencia. Para ello, en Windows se puede usar un .bat con este aspecto:

start telnet 192.168.100.2 7000
start telnet 192.168.100.2 8000
start telnet 192.168.100.2 9000

El resultado no siempre es el deseado. El telnet de Windows envía varios paquetes SYN cuando falla el primero y parece que el knockd no siempre acepta la secuencia. Pero bueno, normalmente antes de 4 o 5 intentos, ya ha funcionado la secuencia.

Por supuesto, el knockd es un punto de fallo adicional en el acceso al sistema. Si le pasa algo a este demonio, nos quedaremos sin poder acceder.

Actualización 21/10/11: Como comentan Dany y SebaMinguez en los comentarios, también podemos configurar port knocking sólo con reglas iptables: Multiple-port knocking Netfilter/IPtables only implementation.

:wq

07 oct

Accediendo a una red mediante NAT en Linux

En las últimas entradas he tratado bastante de cómo acceder a nodos de una red remota por “métodos no estándar”:

Cuando digo “métodos no estándar”, me refiero a que normalmente la conectividad entre redes en una intranet o en Internet se consigue con las rutas definidas en los routers de la red. Los routers saben (o deberían saber) cómo llegar de un nodo en la red A a otro nodo en la red B.

Ahora supongamos que estamos en una gran intranet corporativa con muchas subredes. Supongamos también que tenemos un sistema con Linux con dos interfaces Ethernet. Uno de ellos conectado a la red “oficial” y el otro conectado a un switch al que conectamos varios servidores (Linux, Windows, etc.). Necesitamos que dichos servidores puedan llegar a nodos de la intranet “oficial” y necesitamos acceder a ciertos servicios de los servidores desde la intranet. De momento, esos servidores estarán en una “red oculta” o “inalcanzable” para el resto de nodos de la intranet.

El “método estándar” sería que el administrador de la intranet definiera en los routers de la intranet una ruta para que todos los nodos de la red supieran llegar. Pero si eso no es posible o conveniente (lo contrario implicaría mucha burocracia, va a ser una situación temporal, así proporcionamos más seguridad a la red oculta), es cuando tenemos que usar “metodos no estándar”.

Las soluciones usando OpenSSH descritas en entradas anteriores nos resolvían esta situación perfectamente. Pero, ¡ay! Resulta que OpenSSH introduce una sobrecarga importante: Los nodos que mantienen la conexión SSH estarán permanentemente cifrando toda la comunicación, usarán más CPU y la conexión será menos ligera y fluida.

La alternativa, en la que usamos únicamente técnicas estándar del protocolo IP, sería usar NAT. La idea sería que el sistema Linux se comportara como un router ADSL o de cable como los que solemos tener en casa, que hacen NAT y que nos permiten abrir sólo unos pocos puertos para acceder a ciertos servicios de la red interna.

Así, consideremos el siguiente diagrama en el que vemos que el Linux tiene la IP 10.25.25.2 (eth0) en la intranet “oficial” y la IP 172.16.20.2 (eth1) en la red interna “oculta”:

Sigue leyendo »

06 oct

Recuperando los datos de los discos de un fakeRAID

Mi viejo ordenador de sobremesa que no me había fallado nunca desde el 2005 murió hace un par de días. Creo que es la fuente de alimentación, aunque al abrirlo también he descubierto que uno de los anclajes de plástico de la placa base en los que se ancla el ventilador también se había roto y el ventilador no estaba bien sujeto. Sea como sea, he decidido no intentar arreglarlo. Uno ya no tiene tiempo para según que cosas como antes…

Lo único que quedaba era recuperar los datos del sistema. Intentar recuperar los datos de unos discos duros sin daños no sería ningún notición (los conectas a otro ordenador o los pones en una carcasa de disco USB y ya está) si no fuera porque dos de los tres discos duros del sistema estaban en fakeRAID, con RAID 0, tal como conté en Instalar Ubuntu 8.04 Hardy Heron sobre un fakeRAID.

Cuando monté el ordenador y compré aquellos dos flamantes Maxtor SATA de 200GB ya con la idea de ponerlos en RAID 0, la idea parecía muy buena, sobre todo para alguien como yo que sólo tenía los benchmarks en mente. El rendimiento de los discos en RAID 0 era brutal. Pero claro, mantener un fakeRAID tiene muchas complicaciones: Cuesta más instalar Windows (Integrar drivers de SATA/RAID en un CD de instalación de Windows XP), cuesta más instalar Linux (Instalar Ubuntu 8.04 Hardy Heron sobre un fakeRAID), te toca andar personalizando los initrd (Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio.)… Y por supuesto, que estás corriendo muchos más riesgo de pérdida de datos.

Pero eso sí, el rendimiento era mucho mejor, así que valía la pena… ¿De verdad? Bueno, al principio sí era llamativo (recuerdo que en el SiSoft Sandra batía récords) pero unos pocos años más tarde añadí al sistema un Seagate de 750GB y bueno, resulta que él sólo ya tenía mejor tasa de transferencia que los dos Maxtor de 200GB en RAID 0.

En cualquier caso, estando obsesionado con que si algún día le pasaba algo a uno de los discos lo perdería todo, he sido muy formal haciendo mis backups semanales y aunque no hubiera intentado recuperar el contenido de los discos, los muy pocos cambios de los días previos no hubieran sido ninguna gran pérdida.

Pero bueno, había que intentarlo. Había llegado el momento: Tenía dos discos Maxtor de 200GB en las manos que habían estado en un fakeRAID de una controladora NVIDIA NForce 4 y el reto era ver si sería posible acceder a su contenido. Durante muchos años me había preguntado si se podría hacer. Mi duda principalmente era: ¿Es necesaria la controladora para que poniendo los discos en otro ordenador un Linux pueda entender a los datos del fakeRAID?

Y afortunadamente, la respuesta ha sido que no.

Puse los dos discos en sendas bases convertidoras de SATA a USB, una de ellas una Sharkoon como ésta (a la que se le rompió la tapa, los discos duros ya no se sujetaban bien, y tuve que retirarla y comprar la otra de marca Zaapa):

y tras conectar las bases a un portátil con Linux y al ejecutar el bendito dmraid, el resultado no pudo ser mejor:

# dmraid -ay -v -v -v 
WARN: locking /var/lock/dmraid/.lock
NOTICE: skipping removable device /dev/sdb
NOTICE: /dev/sdd: asr     discovering
NOTICE: /dev/sdd: ddf1    discovering
NOTICE: /dev/sdd: hpt37x  discovering
NOTICE: /dev/sdd: hpt45x  discovering
NOTICE: /dev/sdd: isw     discovering
NOTICE: /dev/sdd: jmicron discovering
NOTICE: /dev/sdd: lsi     discovering
NOTICE: /dev/sdd: nvidia  discovering
NOTICE: /dev/sdd: nvidia metadata discovered
NOTICE: /dev/sdd: pdc     discovering
NOTICE: /dev/sdd: sil     discovering
NOTICE: /dev/sdd: via     discovering
NOTICE: /dev/sdc: asr     discovering
NOTICE: /dev/sdc: ddf1    discovering
NOTICE: /dev/sdc: hpt37x  discovering
NOTICE: /dev/sdc: hpt45x  discovering
NOTICE: /dev/sdc: isw     discovering
NOTICE: /dev/sdc: jmicron discovering
NOTICE: /dev/sdc: lsi     discovering
NOTICE: /dev/sdc: nvidia  discovering
NOTICE: /dev/sdc: nvidia metadata discovered
NOTICE: /dev/sdc: pdc     discovering
NOTICE: /dev/sdc: sil     discovering
NOTICE: /dev/sdc: via     discovering
NOTICE: /dev/sda: asr     discovering
NOTICE: /dev/sda: ddf1    discovering
NOTICE: /dev/sda: hpt37x  discovering
NOTICE: /dev/sda: hpt45x  discovering
NOTICE: /dev/sda: isw     discovering
NOTICE: /dev/sda: jmicron discovering
NOTICE: /dev/sda: lsi     discovering
NOTICE: /dev/sda: nvidia  discovering
NOTICE: /dev/sda: pdc     discovering
NOTICE: /dev/sda: sil     discovering
NOTICE: /dev/sda: via     discovering
NOTICE: added /dev/sdd to RAID set "nvidia_bdehcbaa"
NOTICE: added /dev/sdc to RAID set "nvidia_bdehcbaa"
RAID set "nvidia_bdehcbaa" already active
INFO: Activating stripe raid set "nvidia_bdehcbaa"
NOTICE: discovering partitions on "nvidia_bdehcbaa"
NOTICE: /dev/mapper/nvidia_bdehcbaa: dos     discovering
NOTICE: /dev/mapper/nvidia_bdehcbaa: dos metadata discovered
NOTICE: created partitioned RAID set(s) for /dev/mapper/nvidia_bdehcbaa
RAID set "nvidia_bdehcbaa1" already active
INFO: Activating partition raid set "nvidia_bdehcbaa1"
RAID set "nvidia_bdehcbaa2" already active
INFO: Activating partition raid set "nvidia_bdehcbaa2"
RAID set "nvidia_bdehcbaa3" already active
INFO: Activating partition raid set "nvidia_bdehcbaa3"
RAID set "nvidia_bdehcbaa5" already active
INFO: Activating partition raid set "nvidia_bdehcbaa5"
RAID set "nvidia_bdehcbaa6" already active
INFO: Activating partition raid set "nvidia_bdehcbaa6"
WARN: unlocking /var/lock/dmraid/.lock

Vemos que el dmraid revisa todos los discos para ver si encuentra metadatos de una de las controladoras fakeRAID que soporta. En este caso, encuentra metadatos de una controladora NForce (“nvidia metadata discovered“) en los discos /dev/sdc y /dev/sdd y así, es capaz de descubrir las particiones que podemos montar sin problemas y recuperar los datos.

Por tanto, la lección que he aprendido esta semana es que la controladora fakeRAID realmente no aporta nada más que el soporte en la BIOS para poder arrancar de los discos en RAID, pero ciertamente, todo el resto del trabajo lo hace la CPU y el sistema operativo. Y de hecho, por eso es un fakeRAID, porque la controladora realmente no hace que la existencia de un RAID sea transparente para el sistema operativo. Como nota curiosa, en el sistema también tenía MS-DOS, y el MS-DOS no necesitaba un driver especial para poder estar instalado en un sistema con fakeRAID como sí necesitan Windows y Linux, por lo que parecería que el RAID sí era transparente para MS-DOS, pero porque en realidad MS-DOS usa llamadas a la BIOS para acceder al disco y era en este caso la BIOS la que hacía el trabajo extra.

:wq

05 nov

VPN con OpenSSH

Tras Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH y Reenvío dinámico de puertos / montar un servidor SOCKS con SSH, puede ser buena idea hablar de cómo crear una VPN improvisada entre dos redes cuyos nodos no pueden llegar de una red a la otra exceptuando un sistema de una de las redes que puede crear una conexión OpenSSH con otro sistema de la otra red.

OpenSSH permite esto desde su versión 4.3, y es tan sencillo que en la página man de ssh se describe en apenas 5 párrafos (sección SSH-BASED VIRTUAL PRIVATE NETWORKS). La parte no tan sencilla es la de gestionar las rutas.

Además, como digo, esta configuración es adecuada para una red improvisada y no como solución definitiva porque, como indica la propia página de manual, la sobrecarga por el protocolo SSH es muy alta:

     Since an SSH-based setup entails a fair amount of overhead, it may be
     more suited to temporary setups, such as for wireless VPNs.  More
     permanent VPNs are better provided by tools such as ipsecctl(8) and
     isakmpd(8).

Vamos a trabajar con el escenario mostrado en el siguiente esquema:

Tenemos dos oficinas de una misma empresa conectadas internamente y a Internet con el típico router/switch ADSL que tiene una única IP pública y que hace NAT para compartirla. Ahora queremos interconectarlas, de forma que todos los nodos de una oficina accedan a los de la otra y viceversa. En la primera de ellas se usa la subred 192.168.10.0/24 para la red local, y en la segunda, la subred 172.16.20.0/24. En la configuración del NAT del router ADSL de la segunda oficina abrimos el puerto 22 de SSH y lo redirigimos hacia el nodo servidorssh172 (172.16.20.2), que está ejecutando el sshd de OpenSSH. La IP pública de la segunda oficina debería ser fija o tal vez se podría usar un servicio de DNS dinámico. El nodo clientessh192 (192.168.10.2) de la primera red establecerá una conexión OpenSSH con el nodo servidorssh172 (172.16.20.2) de la segunda red usando la IP pública de la segunda oficina.

Sigue leyendo »

 1 2 3 4 5 6 7 8 ... 15 16 17 Siguiente
Tema LHYLE09, creado por Vicente Navarro