Archivos por Etiqueta: tcp

Network: Latency benchmark

Las pruebas han sido muy basicas (pero dan una idea/orden de magnitud), las maquinas dst tienen un Servidor ECHO-TCP y las maquinas src tiene un Cliente ECHO-TCP. El cliente se conecta al servidor, envia un byte, lee el byte de vuelta, asi una y otra vez en un bucle de 10mil iteraciones, calcula la latencia minima, maxima y la media de las 10mil iteraciones.

Los resultados:

+--------+--------+------------+-------------+------------+----------+
| src    | dst    |    min     |     max     |    avg     | medium   |
+--------+--------+------------+-------------+------------+----------+
| linux1 | win7   | 2137.421µs | 24779.393µs | 3471.736µs | plc      |
| linux2 | win7   | 2035.887µs | 36111.414µs | 3040.004µs | plc      |
| linux3 | win7   | 1889.267µs | 10737.868µs | 2689.145µs | plc      |
| linux1 | win7   | 1031.974µs |  6943.338µs | 1371.043µs | wifi-11n |
| linux2 | win7   |  786.553µs |  4445.808µs | 1153.319µs | wifi-11n |
| linux3 | win7   |  621.457µs | 40078.223µs |  964.037µs | wifi-11n |
| linux1 | win7   |  380.495µs | 69546.800µs |  732.009µs | gbe      |
| linux1 | linux3 |  101.130µs | 10486.523µs |  314.863µs | vm       |
| linux2 | linux1 |  159.140µs |  9334.732µs |  308.808µs | vm       |
| linux2 | win7   |  165.534µs | 11921.050µs |  307.096µs | gbe      |
| linux3 | win7   |   79.133µs |  2289.499µs |  150.973µs | gbe      |
| linux2 | linux3 |   54.764µs |  5447.378µs |   86.460µs | vm       |
| linux1 | linux1 |   54.197µs |   299.199µs |   85.713µs | loopback |
| linux2 | linux2 |   41.505µs |   372.127µs |   72.765µs | loopback |
| linux3 | linux3 |   15.805µs |   500.069µs |   48.219µs | loopback |
| win7   | win7   |   17.675µs |    76.399µs |   22.927µs | loopback |
+--------+--------+------------+-------------+------------+----------+

Las maquinas son:

  • linux1: Ubuntu 14.04 32bits (virtual)
  • linux2: Ubuntu 14.04 64bits (virtual)
  • linux3: Ubuntu 12.04 64bits (fisica)
  • win7: Windows 7 Pro 64bits (fisica)

Los medios de transmision son:

  • plc: enlace PLC HomePlug-AV (aunque el PLC se conecta a la red por Ethernet a 100Mb)
  • wifi: enlace wifi 802.11n (aunque el AP-Wifi se conecta a la red por Ethernet a 100Mb)
  • vm: comunicacion entre dos maquinas dentro de un mismo hypervisor/host (linux3)
  • gbe: enlace Ethernet a 1Gb
  • loopback: comunicacion dentro de la misma maquina (127.0.0.1)

Sourcecode on GitHub:
EchoServer.java
EchoClient.java

OpenVPN: tun y tap

Despues de haber usado VPNs IPSec, L2TP, PPTP y PPP/SSH… sin duda me quedo con OpenVPN.

Aqui pongo varios ejemplos de configuraciones (para un “TUN” -Routing IP- y un “TAP” -Bridge Ethernet-) (Edit [2017.04.25] la configuracion y las pruebas han sido sobre Ubuntu 16.04 en el server y Windows 7 en el cliente, el articulo inicial fue para Ubuntu 12.04 -cambian pocas cosas-), si no funciona el “redirect-gateway def1” (para que todo el trafico salga a traves de la vpn) o alguna otra opcion es posible que debas arrancar el openvpn-gui con privilegios administrativos:

# Primero generamos el Diffie-Hellman (en el server)
openssl gendh -out dh-2048.pem 2048
# Generamos Shared-Secret (en el Server)
# Este fichero es compartido en server y clientes
openvpn --genkey --secret secret.key

Aunque la parte de la creacion de los certificados X.509 no la explico aqui (server.{crt,key} & client.{crt,key}); a modo de resumen (usando solo certificados auto-firmados):

  • dh-2048.pem: es privado, estará solo en el servidor (owner{root:root} perm{600})
  • server.crt: es publico, compartido entre todos -servidor y clientes-
  • server.key: es privado, estará solo en el servidor (owner{root:root} perm{600})
  • client.crt: es publico, generado para cada cliente
  • client.key: es privado, estará solo en el cliente
  • ca.crt: es publico, estará solo en el servidor con permisos restringidos (owner{root:root} perm{644}), todos los client.crt se meten dentro de este fichero de modo concatenado, es la lista de clientes permitidos

Para poder dar soporte a clientes UDP/1194 (standard) y TCP/443 (firewall-friendly) hay que crear 2 ficheros diferentes en el server y asignar 2 rangos de IPs separados (para que no haya problemas con las las rutas).

Leer más de esta entrada

Windows: Dynamic Port Range

Si tienes que hacer pruebas de carga (Windows Vista, 7 y Server 2008) esto puede serte de utilidad para aumentar el numero de puertos dinamicos disponibles:

netsh int ipv4 set dynamicport tcp start=10000 num=50000
netsh int ipv4 set dynamicport udp start=10000 num=50000
netsh int ipv6 set dynamicport tcp start=10000 num=50000
netsh int ipv6 set dynamicport udp start=10000 num=50000

* Con esto tendras disponibles los puertos entre el 10000 y el 60000

Normally, short-lived ports are allocated in the range from 1025 through 65535. The port range is now truly a range with a starting point and with an endpoint. The new default start port is 49152, and the default end port is 65535. This range is in addition to well-known ports that are used by services and by applications.

# The port range that is used by the server:

netsh int <ipv4|ipv6> show dynamicport <tcp|udp>

# You can adjust this range by using the netsh command as follows:

netsh int <ipv4|ipv6> set dynamicport <tcp|udp> start=number num=range

# The start port is number, and the total number of ports in range.

Si tienes un XP (el rango por defecto es 1025-5000), para cambiarlo (a 1025-19999) tendras que tocarlo en el registro:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
“MaxUserPort”=dword:00004e1f

Referencias:
KB-929851: Dynamic port range for TCP/IP (Windows Vista, 7, Server 2008)

Java: Simple Bouncer

forward

Si alguna vez has tenido un servidor en una DMZ seguramente habras usado rinetd o stunnel, esta aplicacion es una version simplificada de stunnel para tuneles SSL o una version del rinetd con algunas funcionalidades extra (loadbalancing o failover de conexiones) en menos de 550 lineas de codigo (Java).

El codigo fuente en GitHub: SimpleBouncer

A %d blogueros les gusta esto: