Saltar al contenido

Tecnología

Tecnología en General

VirtualBox – Red visible máquina virtual (Servidor único interface)

  • admin 

Al trabajar con Máquinas Virtuales será necesario añadir interfaces de red de varios tipos, según nuestras necesidades:

– Bridged : Comparte el rango de red de la máquina anfitrión (la máquina en la que está instalado virtualbox).

– Host-only (Sólo anfitrión) : Crea una red para compartir solamente con el anfitrión.

– Red Interna :Para comunicarse con otras máquinas virtuales que estén ejecutándose a la vez en la misma máquina y poseer una interfaz de red interna que nos facilitará la conexión con las máquinas virtuales cliente (situadas tambien en la red interna).

– NAT : Crea una interfaz en el rango 10.0.0.0 que crea una conexión NAT (traduce entre una dirección IP y la otra) con la red del anfitrión.


Cuando creas una máquina virtual con VirtualBox, con las opciones de red por defecto, esta  con conexión a cualquier recurso en la red al que tenga acceso la máquina anfitriona (conexión a Internet incluida) y puede compartir archivos con ella si configuramos la opción de “Directorios Compartidos”, pero entre máquina anfitriona y máquina virtual no existe ninguna otra posible conexión. La máquina virtual tampoco es accesible de ninguna forma desde otra máquina de nuestra red local y si abrimos dos máquinas virtuales en la misma máquina anfitriona tampoco pueden verse entre si. Esto puede cambiarse fácilmente para que cualquier máquina virtual que creemos sea totalmente visible, tanto por la máquina anfitriona, como por cualquier otra máquina  (o virtual, en esta u otra máquina anfitriona configurada por este mismo método) como si se tratase verdaderamente de una máquina real conectada de forma  a nuestra red. Nos ponemos a ello.

Partimos de una máquina anfitriona con Debian o una distribución derivada (Ubuntu, Kubuntu, etc.), que ya tiene Virtualbox instalado y cuenta con una única interfaz de red (eth0). Lo primero que tenemos que hacer es instalar el paquete bridge-utils.

pablo@pablo-U-100:~$ sudo apt-get install bridge-utils

Luego editamos la configuración de nuestro interface ethernet (/etc/network/interfaces) y lo dejamos de esta forma:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto br0
iface br0 inet dhcp
bridge_ports eth0 vbox0 vbox1

Las líneas en negritas son las que hemos añadido. En ellas estamos definiendo dos interfaces virtuales (vbox0 y vbox1) que están ligados a nuestro interfaz físico real (eth0) y que tomaran una IP de forma dinámica a través de un servicio DHCP que debemos de tener disponible en nuestra red. Esto no quiere decir que no podamos ponerles direcciones fijas a nuestras máquinas virtuales: Estas tendrán disponible este servicio, si existe, desde su arranque pero luego nosotros podremos configurarlas perfectamente mediante IP’s estáticas sin ningún problema, ya dentro del sistema operativo que hayamos elegido para ellas. Por cierto: hemos creado dos interfaces por que es lo que necesitamos (yo, en concreto, quiero hacer prácticas para los chicos con un windows 2003 server y un windows xp que deben de verse para que el segundo se conecte al dominio definido por el primero) pero, lógicamente, podríamos definir una sóla. O diez 🙂 .

Ahora editamos el archivo de configuración de interfaces de virtualbox (/etc/vbox/interfaces) y añadimos las siguientes líneas:

vbox0 pablo br0
vbox1 pablo br0

En ellas redefinimos los dos nuevos interfaces virtuales que hemos creado (vbox0 y vbox1) y declaramos el usuario de la máquina anfitriona que tiene permiso para usarlos.

Ya casi estamos. Ahora reiniciamos, por este orden, la interfaz de red física de nuesta máquina anfitriona y luego virtualbox:

pablo@pablo-U-100:~$ sudo /etc/init.d/networking restart
* Reconfiguring network interfaces…
(…)
bound to 192.168.1.10 — renewal in 39314 seconds.
[ OK ]

pablo@pablo-U-100:~$ sudo /etc/init.d/virtualbox-ose restart
* Shutting down VirtualBox host networking
* done.
* Starting VirtualBox host networking
* done.

Luego iniciamos Virtualbox y configuramos la red de las máquinas que queremos hacer accesibles de esta forma:

Y con esto ya si que hemos acabado. En el siguiente pantallazo (ampliable si hacéis click en él) podéis ver como mis dos máquinas virtuales se ven perfectamente (la XP tomando su IP mediante DHCP, el 2003 server con IP estática configurada manualmente), la autenticación de dominio entre ellos se ha hecho perfectamente y ambas son visibles también desde la máquina anfitriona.

Double Check: Whatsapp.

  • admin 

Curioso hasta que punto la tecnología puede desviarnos de la racionalidad. Parodia graciosa, pero no tan ireal.

httpvh://www.youtube.com/watch?v=_0MBys9pQ8w

TCPDump: Capture and Record Specific Protocols / Port

  • admin 

Q. How do I capture specific protocol or port such as 80 ( http ) using TCPDump tool under Linux / UNIX? How do I recording Traffic with TCPDump and find problems later on?

A. TCPDump is a tool for network monitoring and data acquisition. It can save lots of time and can be used for debugging network or server related problems. Tcpdump prints out a description of the contents of packets on a network interface that match the boolean expression.

Monitor all packets on eth1 interface

tcpdump -i eth1

Monitor all traffic on port 80 ( HTTP )

tcpdump -i eth1 ‘port 80’

Monitor all traffic on port 25 ( SMTP )

tcpdump -vv -x -X -s 1500 -i eth1 ‘port 25’

Where,

-vv : More verbose output
-x : When parsing and printing, in addition to printing the headers of each packet, print the data of each packet.
-X : hen parsing and printing, in addition to printing the headers of each packet, print the data of each packet (minus its link level header) in hex and ASCII. This is very handy for analysing new protocols.
-s 1500: Snarf snaplen bytes of data from each packet rather than the default of 68. This is useful to see lots of information.
-i eth1 : Monitor eth1 interface
Capturing traffic information using cronjobs

tcpdump can be used to find out about attacks and other problems. Let us say your webserver facing problem everday at midnight. Enter following command into cron. It will schedule capturing of 30,000 packets and writing raw data to a file called port.80.debug.txt:
@midnight /usr/sbin/tcpdump -n -c 30000 -w /root/port.80.debug.txt

Next day you can log into your box and read the /root/port.80.debug.txt file:
tcpdump -X -vv -r /root/port.80.debug.txt

This simple technique can be used record and debug problems.

Further readings:

man page tcpdump

TR-069

  • admin 

 

TR-069 (Technical Report 069) is a DSL Forum (which was later renamed as Broadband Forum) technical specification entitled CPE WAN Management Protocol (CWMP). It defines an application layer protocol for remote management of end-user devices. As a bidirectional SOAP/HTTP-based protocol, it provides the communication between customer-premises equipment (CPE) and Auto Configuration Servers (ACS). It includes both a safe auto configuration and the control of other CPE management functions within an integrated framework. The protocol addressed the growing number of different Internet access devices such as modems, routers, gateways, set-top boxes, and VoIP–phones for the end-users. The TR-069 standard was developed for automatic configuration of these devices with Auto Configuration Servers (ACS). The technical specifications are managed and published by the Broadband Forum. TR-069 was first published in May 2004, with amendments in 2006, 2007, 2010, and July 2011 to version 1.3.[1]

Other forums, such as the Home Gateway Initiative (HGI), Digital Video Broadcasting (DVB) and WiMAX Forum endorsed CWMP as the protocol for remote management of home network devices and terminals (such as the DVB IPTV set-top box). There is a growing trend to add TR-069 management functionality to home networking devices such as powerline adapters[2] used for distribution of IPTV content inside customer premises, as well as many other access devices like FTTH CPE/ONTs, WIMAX CPE[3] and other carrier access equipment.

http://en.wikipedia.org/wiki/TR-069