Enrutado e Xestión do ancho de banda baixo Linux

De Wiki do Ciclo ASIR do IES de Rodeira
Saltar á navegación Saltar á procura

Introducción a iproute2

Para poder utilizar as utilidades proporcionadas por iproute é necesario ter activas certas opcións no kernel, principalmente as caracteristicas de control de tráfico e o soporte de netlink. As operacións básicas son as seguintes:

  • Ver os enlaces de rede: ip link list
  • Ver as direccións IP: ip address show
  • Ver a táboa de rutas: ip route show
  • Ver a táboa arp: ip neigh show
  • Borrar unha entrada da táboa arp: ip neigh delete <IP> dev <Dispositivo>

Regras de Enrutado

Para poder utilizar estas características é necesario que o kernel teña compiladas as características "IP: advanced router" e "IP: policy routing". O router Linux ten tres táboas de enrutado que se consultan pra tomar decisións pra encamiñar os paquetes TCP/IP: main, local e default. A utilidade route modifica as táboas local e main.

Pra ver as regras por defecto escrbiremos ip rule list.

  [usuario@dominio]$ ip rule list
  0:    from all lookup local
  32766:    from all lookup main
  32767:    from all lookup default

CASO 1 - Elección de Ruta

Supoñamos que temos dúas saídas a Internet dende a máquina Linux que actúa coma router. A conexión 1 e polo interface con IP 212.64.94.251, que é unha conexión PPP con 212.64.94.1. A conexión 2 prodúceso polo interface de IP 212.64.78.148, que é unha conexión PPP con 195.96.98.253. Queremos dirixir un cliente concreto (por exemplo o 10.0.0.4) hacia unha das dúas conexións, por exemplo á conexión 212.64.78.148 (conexión 2).


Ficheiro:Figura1.png


O contido das tres táboas de rutado serán as seguintes:

  [usuario@dominio]$ ip route list table local
  broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
  local 10.0.0.1 dev eth0  proto kernel  scope host  src 10.0.0.1
  broadcast 10.0.0.0 dev eth0  proto kernel  scope link  src 10.0.0.1
  local 212.64.94.251 dev ppp0  proto kernel  scope host  src 212.64.94.251
  broadcast 10.255.255.255 dev eth0  proto kernel  scope link  src 10.0.0.1
  broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
  local 212.64.78.148 dev ppp1  proto kernel  scope host  src 212.64.78.148
  local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
  local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1
  [usuario@dominio]$ ip route list table main
  195.96.98.253 dev ppp1  proto kernel  scope link  src 212.64.78.148
  212.64.94.1 dev ppp0  proto kernel  scope link  src 212.64.94.251
  10.0.0.0/8 dev eth0  proto kernel  scope link  src 10.0.0.1
  127.0.0.0/8 dev lo  scope link
  default via 212.64.94.1 dev ppp0

A táboa default está valeira e como se ve a conexión por defecto é a través do enlace ppp0 e da conexión 1.

Pra solucionar o problema crearemos unha nova regla que chamaremos cliente, as reglas pódense crear con números pero son máis fáciles de manexar os nomes. Pra crear unha nova regra é necesario engadila ó ficheiro /etc/iproute2/rt_tables dándolle un número que non esté utilizado:

  [rooto@dominio]# echo 200 cliente >> /etc/iproute2/rt_tables
  [root@dominio]# ip rule add from 10.0.0.4 table cliente
  [root@dominio]# ip rule ls
  0:    from all lookup local
  32765:    from 10.0.0.4 lookup cliente
  32766:    from all lookup main
  32767:    from all lookup default

O único que queda por facer é engadir a nova ruta e borrar a caché de rutas pra que comence a funcionar.....

  [root@dominio]# ip route add default via 195.96.98.253 dev ppp1 table cliente
  [root@dominio]# ip route flush cache

CASO 2 - Balanceo de Carga

Agora o problema consiste en acceder a través de dous (ou máis) proveedores ó mesmo tempo, de xeito que poderemos balancear o tráfico entre ambos. Supoñamos a seguinte configuración:

Ficheiro:Figura2.png

O primeiro que debemos resolver é que a resposta ós paquetes que veñen dun proveedor volvan polo mesmo proveedor:

Creamos dúas táboas de rutado Taboa1 e Taboa2:

  [root@dominio]# echo 200 Taboa1 >> /etc/iproute2/rt_tables
  [root@dominio]# echo 201 Taboa2 >> /etc/iproute2/rt_tables

e lle engadimos as novas rutas:

  [root@dominio]#ip route add 172.1.0.0 dev eth1 src 172.1.1.10 table Taboa1
  [root@dominio]# ip route add default via 172.1.1.1 table Taboa1
  [root@dominio]#ip route add 172.2.0.0 dev eth2 src 172.2.1.10 table Taboa2
  [root@dominio]#ip route add default via 172.2.1.1 table Taboa2

O que fixemos foi construir as rutas en táboas separadas para as dúas conexións, agora falta engadir as rutas á taboa principal:

  [root@dominio]#ip route add 172.1.0.0 dev eth1 src 172.1.1.10
  [root@dominio]#ip route add 172.2.0.0 dev eth2 src 172.2.1.10
  [root@dominio]#ip route add default via 172.2.1.1

Como se ve eleximos como ruta por defecto unha das dúas conexións (normalmente a máis rápida). Agora engadimos as reglas de rutado pra asegurar que as respostas que saian por un interface vaian a táboa de rutas axeitada:

  [root@dominio]#ip rule add from 172.1.1.10 table Taboa1
  [root@dominio]#ip rule add from 172.2.1.10 table Taboa2

Son desexables tamén as regras seguintes pra completar as rutas posibles tanto na táboa 1 como na táboa 2:

  [root@dominio]#ip route add 10.0.0.0/255.0.0.0  dev eth0 table Taboa1
  [root@dominio]#ip route add 172.2.0.0/255.255.0.0 dev eth2 table Taboa1
  [root@dominio]#ip route add 127.0.0.0/8 dev lo   table Taboa1
  [root@dominio]#ip route add 10.0.0.0/255.0.0.0  dev eth0 table Taboa2
  [root@dominio]#ip route add 172.1.0.0/255.255.0.0 dev eth1 table Taboa2
  [root@dominio]#ip route add 127.0.0.0/8 dev lo   table Taboa2

Agora faremos un balanceo de carga entre as dúas conexións......

  [root@dominio]#ip route add default scope global nexthop via 172.1.1.1 dev eth1 \
  weight 1 nexthop via 172.2.1.1 dev eth2 weight 1

Esto balanceará a carga entre as dúas conexións. O parámetro weight permitirá favorecer a unha conexión sobre a outra (mayor número máis tráfico). Como as rutas se almacenan en cachés o sistema non é perfecto, xa que ó quedar almacenadas se repiten polo mesmo interface si se usan moito.

Tunneling (Encapsulado IP)

O tunneling engade unha serie de bytes extra ós paquetes TCP/IP, de xeito que a conexión será algo máis lenta (sobre uns 20 bytes). Linux ten 3 tipos de túneles túneles ip en ip, túneles GRE, e túneles externos como PPTP (point to point tunnel protocol).

Túneles IP en IP

Ficheiro:Figura3.png

Imos a configurar un túnel IP-IP entre os dous routers, de xeito que as redes se comuniquen transparentemente. Para este tipo de encapsulación son necesarios dous módulos:

  [root@dominio]# insmod ipip.o
  [root@dominio]# insmod new_tunnel.o

Agora configuramos o túnel:

Na máquina que fai de router da Rede 10.0.1.0

  [root@dominio]# ifconfig tunl0 10.0.1.1 pointopoint 217.128.210.139
  [root@dominio]# route add -net 10.0.2.0 netmask 255.255.255.0 dev tunl0

Na máquina que fai de router da Rede 10.0.2.0

  [root@dominio]# ifconfig tunl0 10.0.2.1 pointopoint 80.73.94.128
  [root@dominio]# route add -net 10.0.1.0 netmask 255.255.255.0 dev tunl0

Túneles GRE

Mediante túneles GRE é posible facer algunhas cousas máis que con túneles IP, como transportar tráfico multicast ou encapsular IPv6.

Ficheiro:Figura3.png

  [root@dominio]# ip tunnel add netb mode gre remote 217.128.210.139 local 80.73.94.128 ttl 225
  [root@dominio]# ip link set netb up
  [root@dominio]# ip addr add 10.0.1.1 dev netb
  [root@dominio]# ip route add 10.0.2.0/24 dev netb