VYATTA Manual Total

Parametros Basico vyatta

openredes@openredesR1# set system gateway-address 192.0.2.1 [edit] openredes@openredesR1# set system name-server 8.8.8.8 [edit] openredes@openredesR1# set system name-server 8.8.4.4 [edit] openredes@openredesR1# delete system login user vyatta [edit] openredes@openredesR1# set system login user yo authentication plaintext-password mipassword [edit] openredes@openredesR1# set system host-name openredesR1 [edit] openredes@openredesR1# set system domain-name labopenredes.es [edit] openredes@openredesR1# set system time-zone Europe/Madrid [edit] openredes@openredesR1# set system ntp server hora.roa.es [edit] openredes@openredesR1# set system ntp server es.pool.ntp.org [edit] openredes@openredesR1# commit [edit] openredes@openredesR1# show system config-management { commit-revisions 20 } console { device ttyS0 {

speed 9600 } } domain-name labopenredes.es gateway-address 192.0.2.1 host-name openredesR1 login { user openredes { authentication { encrypted-password *** } level admin } user yo { authentication { encrypted-password *** } level admin } } name-server 8.8.4.4 name-server 8.8.8.8 ntp { server es.pool.ntp.org { } server hora.roa.es { } } package { auto-sync 1 repository community { components main distribution stable

url http://packages.vyatta.com/vy http://packages.vyatta.com/vyatta atta } } syslog { global { facility all { level notice } facility protocols { level debug } } } time-zone Europe/Madrid [edit] openredes@openredesR1# save Saving configuration to '/opt/vyatta/etc/config/co '/opt/vyatta/etc/config/config.boot'... nfig.boot'... Done [edit] openredes@openredesR1#

Después configuramos la máquina Vyatta openredesR2 de la misma forma (con la puerta de enlace correspondiente): openredes@openredesR2# set system gateway-address 192.0.2.2 [edit] openredes@openredesR2# set system name-server 8.8.8.8 [edit] openredes@openredesR2# set system name-server 8.8.4.4 [edit] openredes@openredesR2# delete system login user vyatta [edit]

openredes@openredesR2# set system login user yo authentication plaintext-password mipassword [edit] openredes@openredesR2# set system host-name openredesR2 [edit] openredes@openredesR2# set system domain-name labopenredes.es [edit] openredes@openredesR2# set system time-zone Europe/Madrid [edit] openredes@openredesR2# set system ntp server hora.roa.es [edit] openredes@openredesR2# set system ntp server es.pool.ntp.org [edit] openredes@openredesR2# commit [edit] openredes@openredesR2# show system config-management { commit-revisions 20 } console { device ttyS0 { speed 9600 } } domain-name labopenredes.es gateway-address 192.0.2.2 host-name openredesR2 login { user openredes { authentication { encrypted-password *** } level admin }

user yo { authentication { encrypted-password *** } level admin } } name-server 8.8.4.4 name-server 8.8.8.8 ntp { server es.pool.ntp.org { } server hora.roa.es { } } package { auto-sync 1 repository community { components main distribution stable url http://packages.vyatta.com/vyatta } } syslog { global { facility all { level notice } facility protocols { level debug } } }

time-zone Europe/Madrid [edit] openredes@openredesR2# save Saving configuration to '/opt/vyatta/etc/config/config.boot'... Done [edit] openredes@openredesR2#

CONFIGURACION DE INTERFACES , VLANS, BRIDGES Seguimos con los tutoriales de ejemplo para mostrar la forma de configurar los módulos de Vyatta. En este paso a paso de configuración de Vyatta nos centramos en la topología o esquema base que hemos creado para explicar la forma de configurar nuestra máquina Vyatta comorouter open source de la red, configuraremos interfaces, VLANs (vif) y enlaces agregados de red (bonding) para conseguir el primer paso y que actúe como router open source de la red interna y la mantenga segmentada según la topología propuesta .

Configuration de openredesR1 openredesR1 tiene 3 interfaces de red, dos de ellas (eth0 y eth1) estarán configuradas como 1 Link Aggregation (LACP, IEEE 802.3ad, NIC bo nding, NIC teaming) formando bond0 y la otra, eth2 está conectada al router ADSL. A su vez para posteriormente poder aplicar diferentes políticas de seguridad a los distintos departamentos de la empresa se ha decidido 2 crear diferentes VLANs que dividen la red LAN en subredes más pequeñas y homogéneas en cuanto a forma de trabajo y tipo de tráfico generado en la red se refiere. Para esto es necesario dividir bond0 en 5 subredes exactamente y configurar en openredesR1 una IP dentro del rango establecido para cada una de las subredes o VLAN que vamos a crear.

Entonces para configurar las 3 interfaces que tiene openredesR1 en la forma especificada y tener conectividad a Internet desde openredesR1 y las subredes creadas seguimos los siguientes pasos: 

Creamos y editamos la interfaz bond0:



openredes@openredesR1# edit interfaces bonding bond0



[edit interfaces bonding bond0]

3



openredes@openredesR1# set description LANTRUNK1A






openredes@openredesR1# set mode 802.3ad






openredes@openredesR1# commit






openredes@openredesR1# top

4

5

[edit]



Añadimos las interfaces esclavas que van a formar parte de bond0:



openredes@openredesR1# set interfaces ethernet eth0 bond-group bond0



[edit]






[edit]




[edit]



Creamos las interfaces virtuales (VLANs) en bond0 asignándoles por ahora a cada una su IP (utilizaremos la última de cada rango) y una descripción:









openredes@openredesR1# set vif 10 address 192.168.0.126/25






openredes@openredesR1# set vif 10 description Ventas












openredes@openredesR1# set vif 20 description Marketing












openredes@openredesR1# set vif 30 description Admon












openredes@openredesR1# set vif 40 description Gerencia












openredes@openredesR1# set vif 50 description DMZ













[edit]



Después configuramos la interfaz conectada al router ADS L (en este caso suponemos que el router esta configurado en monopuesto o bridge con lo que tenemos la IP pública en la interfaz eth2 de Vyatta y tenemos que gestionar los parámetros de conexión con el 6 ISP, que suponemos usa encapsulación PPPoE , en el ejemplo, usaremos también 7 direcciones IP “TEST- NET” ), todos estos datos necesitaremos obtenerlos de nuestro ISP:



openredes@openredesR1# set interfaces ethernet eth2 pppoe 0 local-address 192.0.2.10



[edit]



openredes@openredesR1# set interfaces ethernet eth2 pppoe 0 user-id usuario@adsl



[edit]



openredes@openredesR1# set interfaces ethernet eth2 pppoe 0 password password



[edit]



openredes@openredesR1# set interfaces ethernet eth2 remote-address 192.0.2.1



[edit]




[edit]







Vemos a modo de resumen la configuración que acabamos de dar a las interfaces para comprobar posibles errores: openredes@openredesR1# run show interfaces bonding bond0 {



description LANTRUNK1A



mode 802.3ad



vif 10 {



address 192.168.0.126/25



description Ventas



}



vif 20 {



address 192.168.0.190/26



description Marketing



}



vif 30 {



address 192.168.0.206/28



description Admon



}



vif 40 {



address 192.168.0.222/28



description Gerencia



}



vif 50 {



address 192.168.0.238/28



description DMZ }





}



ethernet eth0 {



bond-group bond0



duplex auto



hw-id aa:bb:cc:dd:ee:ff



smp_affinity auto



speed auto



}



ethernet eth1 {



bond-group bond0



duplex auto



hw-id ff:ee:dd:cc:bb:aa



smp_affinity auto



speed auto



}



ethernet eth2 {



description Publica



duplex auto



hw-id a1:b2:c3:d4:e5:f6



pppoe 0 {



local-address 192.0.2.10



password password



remote-address 192.0.2.1



user-id usuario@adsl }





smp_affinity auto



speed auto



}



loopback lo {



}



También desde el modo de operación podemos ver la configuración que acabamos de hacer y el estado de las interfaces:



openredes@openredesR1# run show interfaces



Interface



bond0



bond0.10

192.168.0.126/25

up

up

Ventas



bond0.20

192.168.0.190/26

up

up

Marketing



bond0.30

192.168.0.206/28

up

up

Administracion



bond0.40

192.168.0.222/28

up

up

Gerencia



bond0.50

192.168.0.238/28

up

up

DMZ



eth0

-

up

up



eth1

-

up

up



eth2



lo

127.0.0.1/8



lo

::1/128



[edit]

IP Address

State

-

192.0.2.10/24

openredes@openredesR1#

Link up

up

Description up

up up up

up up

LANTRUNK1A

Con esto ya tenemos en openredesR1 todas las subredes creadas (habiendo configurado previamente el switch para gestionar dichas VLANs y para soportar LACP en los puertos especificados), las interfaces operativas para actuar como router en todas las subredes y con acceso internet sin limitaciones. 

El último paso una vez terminado de configurar openredesR1 como router para la primera sede ejemplo es guardar la configuración para que sea persistente ante cualquier reinicio:



openredes@openredesR1# save



Saving configuration to '/opt/vyatta/etc/config/config.boot'...



Done

[edit]

Configuración de openredesR2 De la misma forma pasamos a la configuración básica de openredesR2, al igual que openredesR1 también tiene 3 interfaces de red, dos de ellas (eth0 y eth1) estarán configuradas como Link Aggregation (LACP, IEEE 802 .3ad, NIC bonding, NIC 1 teaming) formando bond0 y la otra, eth2 está conectada al router ADSL. A su vez para posteriormente poder aplicar diferentes políticas de seguridad a los distintos departamentos 2 de la empresa se ha decidido crear diferentes VLANs que dividen la red LAN en subredes más pequeñas y homogéneas en cuanto a forma de trabajo y tipo de tráfico generado en la red se refiere. Para esto, en este caso, es necesario dividir bond0 en 3 subredes exactamente y configurar en openredesR2 una IP dentro del rango establecido para cada una de las subredes o VLAN que vamos a crear.

Entonces para configurar las 3 interfaces que tiene openredesR2 en la forma especificada y tener conectividad a Internet desde openredesR2 y las subredes creadas seguimos los siguientes pasos: 

Creamos y editamos la interfaz bond0:









openredes@openredesR2# set description LANTRUNK1B




3



openredes@openredesR2# set mode 802.3ad













4

5

[edit]



Añadimos las interfaces esclavas que van a formar parte de bond0:






[edit]






[edit]




[edit]



Creamos las interfaces virtuales (VLANs) en bond0 asignándoles por ahora a cada una su IP (utilizaremos la última de cada rango) y una descripción:















openredes@openredesR2# set vif 60 description I+D












openredes@openredesR2# set vif 70 description Desarrollo












openredes@openredesR2# set vif 80 description Servers













[edit]



Después configuramos la interfaz conectada al router ADS L (en este caso suponemos que el router está configurado en monopuesto o bridge con lo que tenemos la IP pública en la interfaz eth2 de Vyatta y tenemos que gestionar los parámetros de conexión con el 6 ISP, que suponemos usa encapsulación PPPoE , en el ejemplo, usaremos también 7 direcciones IP del bloque “TEST- NET” ), todos estos datos necesitaremos obtenerlos de nuestro ISP:



openredes@openredesR2# set interfaces ethernet eth2 pppoe 0 local-address 192.0.2.20



[edit]



openredes@openredesR2# set interfaces ethernet eth2 pppoe 0 user-id usuario@adsl



[edit]



openredes@openredesR2# set interfaces ethernet eth2 pppoe 0 password password



[edit]



openredes@openredesR2# set interfaces ethernet eth2 remote-address 192.0.2.1



[edit]




[edit]



Comprobamos la configuración de interfaces que acabamos de hacer:



openredes@openredesR2# run show interfaces



bonding bond0 {



description LANTRUNK1B



mode 802.3ad



vif 60 {



address 192.168.1.126/25



description I+D



}



vif 70 {



address 192.168.1.190/26



description Desarrollo



}



vif 80 {



address 192.168.1.254/26



description Servers }





}



ethernet eth0 {



bond-group bond0



duplex auto



hw-id 00:11:22:33:44:55



smp_affinity auto



speed auto



}



ethernet eth1 {



bond-group bond0



duplex auto



hw-id 01:23:45:67:89:ab



smp_affinity auto



speed auto



}



ethernet eth2 {



description Publica



duplex auto



hw-id 55:44:33:22:11:00 pppoe 0 {





local-address 192.0.2.20



password password



remote-address 192.0.2.1



user-id usuario@adsl }





smp_affinity auto



speed auto



}



loopback lo {

}

Con esto ya tenemos en openredesR2 todas las subredes creadas (habiendo configurado previamente el switch para gestionar dichas VLANs y para soportar LACP en los puertos especificados), las interfaces operativas para actuar como router en todas las subredes y con acceso internet sin limitaciones. 

El último paso una vez terminado de configurar openredesR2 como router para la segunda sede ejemplo es guardar la configuración para que sea persistente ante cualquier reinicio:



openredes@openredesR2# save



Saving configuration to '/opt/vyatta/etc/config/config.boot'...



Done

[edit]

1. ^ Para por llevar a cabo la configuración citada de agregación de enlaces es necesario que el switch al que conectemos los enlaces soporte y tenga los puertos a los que conectamos dichos enlaces configurados según el protocolo LACP.

2. ^ Para el funcionamiento de las subredes hemos de configurar el switch para que refleje las VLANs etiquetadas de la misma forma que lo hemos hecho en nuestro router Vyatta.

3. ^ Recordemos que con el comando “edit” nos posicionamos directamente en la rama del nodo que especifiquemos a continuación. Recordemos también que el tabulador es nuestro amigo :)

4. ^ Usamos el ejemplo el modo 802.3ad o Dynamic link aggregation, que permite crear grupos de enlaces en agregación que compartan las mismas configuraciones de velocidad y duplex. Permite “sumar” las capacidades de todos los enlaces del grupo y ofrecer tolerancia a fallos ante la caída de puertos o de enlaces.

5. ^ Recordemos que con el comando “top” salimos de la rama en la que estamos y volvemos a la raíz del sistema de configuración.

^ La encapsulación PPPoE (Point-to-Point Protocol over Ethernet) se usa crear un PVC en líneas ADSL tal y como define el RFC 2516. Podemos configurar para este fin tanto una interfaz ADSL como una interfaz Ethernet (no será así¬ para el resto de encapsulaciones ADSL).

ACCESOS REMOTOS A NUESTRAS MAQUINAS Para poder acceder remotamente de forma segura a una máquina Vyatta lo primero es configurar el servicio SSH, el servicio Web GUI access (https) o tambien el acceso remoto por Telnet, de esta forma podremos administrar y configurar de forma remota los sistemas Vyatta. Como recomendación lo mejor, más seguro y potente es la configuración y administración remota

por SSH, recordemos que las conexiones Telnet no están encriptadas:

vyatta@vyatta:~$ configure [edit] vyatta@vyatta# set service ssh port 2022 vyatta@vyatta# set service ssh allow-root vyatta@vyatta# set service telnet port 2023 vyatta@vyatta# set service https vyatta@vyatta# commit vyatta@vyatta# save

CONFIGURACION DE LA VPN

Seguimos con la sección de tutoriales / manuales de configuración de Vyatta, en esta publicación tenemos un paso a paso para llevar a cabo laconfiguración de túneles o VPNs punto a punto o site-to-site (STS) en Vyatta mediante la integración que Vyatta ofrece con OpenVPN, con lo que generaremos nuevas interfaces virtuales (llamadas vtun) en nuestras máquinas Vyatta sobre las que se levantará nuestro túnel y por el que seencriptará todo el tráfico que circule por él. Nos basaremos una vez más en la topología de ejemplo de configuración de Vyatta y antes de crear la VPN site-to-site o punto a punto tenemos que generar los certificados y gestionarlos correctamente.

Y tras la ardua tarea de creación y colocación de certificados podemos llevar a cabo la configuración de las VPNs que necesita nuestra empresa ficticia. Empezamos con openredesR1 y vamos a configurar la VPN STS para la que actuara como servidor, como su nombre indica (extremo a extremo), en este tipo de VPN solo van a intervenir dos equipos y será una conexión punto a punto, uno de ellos será el servidor o extremo pasivo (recibe las peticiones) y el otro extremo será el cliente o extremo activo (enviara peticiones de conexión). En este caso vamos a usar interfaz conectada a la red pública para configurar la VPN que se levantará sobre la nueva interfaz virtual vtun10 y estará en la subred 192.168.2.32/30: openredes@openredesR1:# edit interfaces openvpn vtun10 [edit] openredes@openredesR1:# set description VPN-Inter-Sede [edit interfaces openvpn vtun10] openredes@openredesR1:# set local-address 192.168.2.33 [edit interfaces openvpn vtun10] openredes@openredesR1:# set local-host 192.0.2.10

[edit interfaces openvpn vtun10] openredes@openredesR1:# set local-port 1194 [edit interfaces openvpn vtun10] openredes@openredesR1:# set mode site-to-site [edit interfaces openvpn vtun10] openredes@openredesR1:# set openvpn-option "--comp-lzo --push keepalive 10 120 -persist-tun --persist-key --persist-local-ip --persist-remote-ip --reneg-sec 86400 --remote-cert-tls client --script-security 2" [edit interfaces openvpn vtun10] openredes@openredesR1:# set remote-address 192.168.2.34 [edit interfaces openvpn vtun10] openredes@openredesR1:# set remote-host 192.0.2.20 [edit interfaces openvpn vtun10] openredes@openredesR1:# set remote-port 1194 [edit interfaces openvpn vtun10] openredes@openredesR1:# set tls ca-cert-file /openvpn/keys/sts/ca.crt [edit interfaces openvpn vtun10] openredes@openredesR1:# set tls cert-file /openvpn/keys/sts/empresaR1.crt [edit interfaces openvpn vtun10] openredes@openredesR1:# set tls dh-file /openvpn/keys/sts/dh1024.pem [edit interfaces openvpn vtun10] openredes@openredesR1:# set tls key-file /openvpn/keys/sts/empresaR1.key [edit interfaces openvpn vtun10] openredes@openredesR1:# set tls role pasive [edit interfaces openvpn vtun10] openredes@openredesR1:# commit [edit interfaces openvpn vtun10] openredes@openredesR1:# show description VPN-Inter-Sede encryption bf128 hash sha1 local-address 192.168.2.33 local-host 192.0.2.10 local-port 1194

mode site-to-site openvpn-option "--comp-lzo --push keepalive 10 120 --persist-tun --persist-key --persist-local-ip --persist-remote-ip --reneg-sec 86400 --remote-cert-tls client --script-security 2" remote-address 192.168.2.34 remote-host 192.0.2.20 remote-port 1194 tls { ca-cert-file /openvpn/keys/sts/ca.crt cert-file /openvpn/keys/sts/empresaR1.crt dh-file /openvpn/keys/sts/dh1024.pem key-file /openvpn/keys/sts/empresaR1.key role pasive } [edit interfaces openvpn vtun10] openredes@openredesR1:# top [edit] openredes@openredesR1:# save Saving configuration to '/opt/vyatta/etc/config/config.boot'... Done [edit] openredes@openredesR1:#

Con esto terminamos la configuración de openredesR1 y ya está preparado para dar de alta en la red una máquina configurada como extremo activo que será openredesR2, pasamos ahora a configurar el otro extremo de la conexión STS que nos habilitará la interconexión entre ambas sedes remotas como si trabajasen físicamente juntas, lo haremos creando en openredesR2 una interfaz virtual llamada vtun10 (no tiene que llamarse igual que el extremo opuesto) que haga peticiones al puerto 1194 de la máquina servidor: openredes@openredesR2:# edit interfaces openvpn vtun10 [edit] openredes@openredesR2:# set description VPN-Inter-Sede [edit interfaces openvpn vtun10] openredes@openredesR2:# set local-address 192.168.2.34

[edit interfaces openvpn vtun10] openredes@openredesR2:# set local-host 192.0.2.20 [edit interfaces openvpn vtun10] openredes@openredesR2:# set local-port 1194 [edit interfaces openvpn vtun10] openredes@openredesR2:# set mode site-to-site [edit interfaces openvpn vtun10] openredes@openredesR2:# set openvpn-option "--comp-lzo --push keepalive 10 120 -persist-tun --persist-key --persist-local-ip --persist-remote-ip --reneg-sec 0 -explicit-exit-notify 2 --remote-cert-tls client --script-security 2" [edit interfaces openvpn vtun10] openredes@openredesR2:# set remote-address 192.168.2.33 [edit interfaces openvpn vtun10] openredes@openredesR2:# set remote-host 192.0.2.10 [edit interfaces openvpn vtun10] openredes@openredesR2:# set remote-port 1194 [edit interfaces openvpn vtun10] openredes@openredesR2:# set tls ca-cert-file /openvpn/keys/sts/ca.crt [edit interfaces openvpn vtun10] openredes@openredesR2:# set tls cert-file /openvpn/keys/sts/stsempresaR2.crt [edit interfaces openvpn vtun10] openredes@openredesR2:# set tls key-file /openvpn/keys/sts/stsempresaR2.key [edit interfaces openvpn vtun10] openredes@openredesR2:# set tls role active [edit interfaces openvpn vtun10] openredes@openredesR2:# commit [edit interfaces openvpn vtun10] openredes@openredesR2:# show description VPN-Inter-Sede encryption bf128 hash sha1 local-address 192.168.2.34 local-host 192.0.2.20 local-port 1194

mode site-to-site openvpn-option "--comp-lzo --push keepalive 10 120 --persist-tun --persist-key --persist-local-ip --persist-remote-ip --reneg-sec 0 --explicit-exit-notify 2 -remote-cert-tls client --script-security 2" remote-address 192.168.2.33 remote-host 192.0.2.10 remote-port 1194 tls { ca-cert-file /openvpn/keys/sts/ca.crt cert-file /openvpn/keys/sts/stsempresaR2.crt key-file /openvpn/keys/sts/stsempresaR2.key role active } [edit interfaces openvpn vtun10] openredes@openredesR2:# top [edit] openredes@openredesR2:# save Saving configuration to '/opt/vyatta/etc/config/config.boot'... Done [edit] openredes@openredesR2:# ping 192.168.2.33 PING 192.168.2.33 (192.168.2.33) 56(84) bytes of data. 64 bytes from 192.168.2.33: icmp_req=1 ttl=64 time=0.817 ms 64 bytes from 192.168.2.33: icmp_req=2 ttl=64 time=0.579 ms 64 bytes from 192.168.2.33: icmp_req=3 ttl=64 time=0.455 ms 64 bytes from 192.168.2.33: icmp_req=4 ttl=64 time=0.342 ms ^C --- 192.168.2.33 ping statistics --4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 0.342/0.548/0.817/0.177 ms [edit] openredes@openredesR2:#

Y ya tenemos nuestras dos sedes remotas conectadas de forma totalmente segura, pero… si tr atas de hacer ping desde una máquina de la subred DMZ hacia una máquina que está en la VLAN de desarrollo (en la otra sede) o incluso desde openredesR1 a cualquiera de las otras interfaces de

openredesR2… no funciona, que pasa? no está bien configurada la VPN? si si, tranquilo, no es eso, el problema es que nuestras máquinas Vyatta aún no conocen de la existencia de otras redes o subredes distintas a las que tienen conectadas directamente y el tráfico se escapa por la ruta por defecto (192.0.2.1 en este caso). Como lo solucionamos? bueno, tenemos varias posibilidades, añadir rutas persistentes a todos los equipos de la empresa (bufff, quita quita), añadir rutas estáticas a nuestras dos máquinas Vyatta para que sepan las subredes que hay en el extremo opuesto o incluso configurar algún protocolo

de routing (rip, ospf…)

Rutas estáticas En este tutorial vamos a explicar como configurar las rutas estáticas en Vyatta . Como ya dijimos en el tutorial de configuración de las VPNs en Vyatta según la topología ejemplo, aun no tenemos conectividad total entre las dos redes internas de las dos sucursales de la empresa ejemplo y esto es debido a que ninguna de las dos máquinas Vyatta conoce las subredes que hay conectadas a la máquina del otro extremo. Acabamos de hablar de rutas estáticas, pero también tenemos la versatilidad de los protocolos de routing dinámico, de cualquier forma podemos conseguir que cada una de las máquinas Vyatta conozca las subredes de la máquina del otro extremo y sepa como enrutar los paquetes destinados a ella correctamente, bien con routing estático o bien con routing dinámico (RIP, OSPF). En este caso son pocas rutas y la configuración es muy sencilla escogiendo cualquiera de las dos formas, pero para configuraciones en las que se interconectan numerosos routers entre si el usar una configuración basada en un protocolo de routing dinámico nos puede simplificar mucho las cosas.

Si vamos a la topología ejemplo veremos que según la configuración básica de sistema, teniendo también hecha la configuración de interfaces físicas, enlaces agregados y VLANs y las VPNs también configuradas en nuestras máquinas Vyatta de ejemplo openredesR1 y openredesR2 cualquier tráfico de red con destino a una red que no sea alguna de las subredes internas locales a la sede en concreto, será enviada a la puerta de enlace como ruta por defecto para redes no conocidas. Podemos verlo en la tabla de rutas de openredesR1 con el comando del modo de operación (recordemos que cuando estamos en modo configuración o edición, con “run” podemos ejecutar comandos del modo operación): openredes@openredesR1# run show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] via 10.0.0.20, eth2 C>* 127.0.0.0/8 is directly connected, lo

C>* 192.0.2.0/24 is directly connected, eth2 C>* 192.168.0.0/25 is directly connected, bond0.10 C>* 192.168.0.128/26 is directly connected, bond0.20 C>* 192.168.0.192/28 is directly connected, bond0.30 C>* 192.168.0.208/28 is directly connected, bond0.40 C>* 192.168.0.224/28 is directly connected, bond0.50 C>* 192.168.2.0/29 is directly connected, vtun0 C>* 192.168.2.8/29 is directly connected, vtun1 C>* 192.168.2.34/32 is directly connected, vtun10 [edit] openredes@openredesR1#

Aquí podemos comprobar que cualquier paquete con destino a una red que no sea una de las conectadas a openredesR1 se enviará a la puerta de enlace configurada en el sistema (192.0.2.1). Por lo que si queremos hacer un ping a una máquina de la red privada de la otra sede conectada a openredesR2 será enviado erróneamente por la puerta de enlace del ISP (192.0.2.1) y nunca llegara a su destino. Probamos a hacer ping a la IP 192.168.1.126, que es la IP de la interfaz bond0.60, desde openredesR1: openredes@openredesR1# ping 192.168.1.126 PING 192.168.1.126 (192.168.1.126) 56(84) bytes of data. ^C --- 192.168.1.126 ping statistics --4 packets transmitted, 0 received, 100% packet loss, time 3028ms

Y no responde, y si intentamos trazar la ruta: openredes@openredesR1# traceroute 192.168.1.126 traceroute to 192.168.1.126 (192.168.1.126), 30 hops max, 60 byte packets 1

192.0.2.1 (192.0.2.1)

2

* * *

3

* * *

7.067 ms

6.979 ms

6.968 ms

4

* * *

5

* * *

6

* * *

7

* * *

8

*^C

[edit] openredes@openredesR1#

Se nos va por los cerros de Úbeda… (por la puerta de enlace por defecto). Claramente el problema es que openredesR1 no sabe que el tráfico destinado a la red 192.168.1.0/24 ha de enviarlo a openredesR2 y al contrario ocurre lo mismo.

Vamos entonces a solucionar este problema fácilmente:

Le diremos a openredesR1, mediante rutas estáticas, que todo el tráfico destinado a la red 192.168.1.0/24 lo envíe a openredesR2 por la VPN, la interfaz vtun10 de openredesR2 tiene IP 192.168.2.34: openredes@openredesR1# set protocols static route 192.168.1.0/24 next-hop 192.168.2.34 [edit] openredes@openredesR1# commit [edit] openredes@openredesR1# ping 192.168.1.126 PING 192.168.1.126 (192.168.1.126) 56(84) bytes of data. 64 bytes from 192.168.1.126: icmp_req=1 ttl=64 time=0.626 ms 64 bytes from 192.168.1.126: icmp_req=2 ttl=64 time=0.599 ms ^C --- 192.168.1.126 ping statistics --2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.599/0.612/0.626/0.028 ms [edit] openredes@openredesR1# ping 192.168.1.190

PING 192.168.1.190 (192.168.1.190) 56(84) bytes of data. 64 bytes from 192.168.1.190: icmp_req=1 ttl=64 time=0.807 ms 64 bytes from 192.168.1.190: icmp_req=2 ttl=64 time=0.725 ms 64 bytes from 192.168.1.190: icmp_req=3 ttl=64 time=0.684 ms ^C --- 192.168.1.190 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.684/0.738/0.807/0.060 ms [edit] openredes@openredesR1# ping 192.168.1.254 PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data. 64 bytes from 192.168.1.254: icmp_req=1 ttl=64 time=0.876 ms 64 bytes from 192.168.1.254: icmp_req=2 ttl=64 time=0.722 ms 64 bytes from 192.168.1.254: icmp_req=3 ttl=64 time=0.677 ms ^C --- 192.168.1.254 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.677/0.758/0.876/0.088 ms [edit] openredes@openredesR1# save Saving configuration to '/opt/vyatta/etc/config/config.boot'... Done [edit] openredes@openredesR1#

Ahora podemos hacer ping a cualquiera de las interfaces internas de openredesR2 desde openredesR1 y a cualquier máquina que hubiese conectada en cualquiera de las VLANs de operedesR2. Con lo que ya podemos acceder desde la red de la sede principal a la red de la sede secundaria por medio de una VPN segura creando nuestra propia Intranet.

Para terminar habría que decirle también a openredesR2 que todo el tráfico con destino a la red 192.168.0.0/24 ha de enrutarlo por la VPN hacia openredesR1. También tenemos que decirle a

openredesR2 que existen más subredes en openredesR1, las creadas con la VPN de acceso remoto, así si alguien se conecta por la VPN de acceso remoto a openredesR1 y quiere llegar a alguna máquina que está en la otra sede, openredeR2 tiene que conocer también esas subredes para poder devolver los paquetes correctamente: openredes@openredesR2# set protocols static route 192.168.0.0/24 next-hop 192.168.2.33 [edit] openredes@openredesR2# set protocols static route 192.168.2.0/29 next-hop 192.168.2.33 [edit] openredes@openredesR2# set protocols static route 192.168.2.8/29 next-hop 192.168.2.33 [edit] openredes@openredesR2# commit [edit] openredes@openredesR2# ping 192.168.0.126 PING 192.168.0.126 (192.168.0.126) 56(84) bytes of data. 64 bytes from 192.168.0.126: icmp_req=1 ttl=64 time=1.17 ms 64 bytes from 192.168.0.126: icmp_req=2 ttl=64 time=0.635 ms 64 bytes from 192.168.0.126: icmp_req=3 ttl=64 time=0.784 ms ^C --- 192.168.0.126 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.635/0.863/1.171/0.227 ms [edit] openredes@openredesR2# ping 192.168.0.190 PING 192.168.0.190 (192.168.0.190) 56(84) bytes of data. 64 bytes from 192.168.0.190: icmp_req=1 ttl=64 time=0.725 ms 64 bytes from 192.168.0.190: icmp_req=2 ttl=64 time=0.675 ms 64 bytes from 192.168.0.190: icmp_req=3 ttl=64 time=0.622 ms ^C --- 192.168.0.190 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.622/0.674/0.725/0.042 ms [edit]

openredes@openredesR2# ping 192.168.0.206 PING 192.168.0.206 (192.168.0.206) 56(84) bytes of data. 64 bytes from 192.168.0.206: icmp_req=1 ttl=64 time=0.733 ms 64 bytes from 192.168.0.206: icmp_req=2 ttl=64 time=0.658 ms 64 bytes from 192.168.0.206: icmp_req=3 ttl=64 time=0.636 ms ^C --- 192.168.0.206 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.636/0.675/0.733/0.051 ms [edit] openredes@openredesR2# ping 192.168.0.222 PING 192.168.0.222 (192.168.0.222) 56(84) bytes of data. 64 bytes from 192.168.0.222: icmp_req=1 ttl=64 time=0.560 ms 64 bytes from 192.168.0.222: icmp_req=2 ttl=64 time=0.769 ms 64 bytes from 192.168.0.222: icmp_req=3 ttl=64 time=0.650 ms ^C --- 192.168.0.222 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.560/0.659/0.769/0.090 ms [edit] openredes@openredesR2# ping 192.168.0.238 PING 192.168.0.238 (192.168.0.238) 56(84) bytes of data. 64 bytes from 192.168.0.238: icmp_req=1 ttl=64 time=0.776 ms 64 bytes from 192.168.0.238: icmp_req=2 ttl=64 time=0.555 ms 64 bytes from 192.168.0.238: icmp_req=3 ttl=64 time=0.699 ms ^C --- 192.168.0.238 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.555/0.676/0.776/0.096 ms [edit] openredes@openredesR2# ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. 64 bytes from 192.168.2.1: icmp_req=1 ttl=64 time=0.651 ms

64 bytes from 192.168.2.1: icmp_req=2 ttl=64 time=0.636 ms 64 bytes from 192.168.2.1: icmp_req=3 ttl=64 time=0.642 ms ^C --- 192.168.2.1 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.636/0.643/0.651/0.006 ms [edit] openredes@openredesR2# ping 192.168.2.9 PING 192.168.2.9 (192.168.2.9) 56(84) bytes of data. 64 bytes from 192.168.2.9: icmp_req=1 ttl=64 time=0.556 ms 64 bytes from 192.168.2.9: icmp_req=2 ttl=64 time=0.664 ms 64 bytes from 192.168.2.9: icmp_req=3 ttl=64 time=0.534 ms ^C --- 192.168.2.9 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.534/0.584/0.664/0.063 ms [edit] openredes@openredesR2# save Saving configuration to '/opt/vyatta/etc/config/config.boot'... Done [edit] openredes@openredesR2#

Con esto, a nivel de rutas, lo tenemos todo resuelto. Aunque si nos apetece, nos gusta más, queremos aprender más o sabemos perfectamente lo que buscamos podemos resolver este mismo problema de rutas con ruting dinámico, bien OSPF o bien RIP.

Cconfigurando NAT

Configuración de NAT en openredesR1: 

La primera regla que vamos a crear es para la salida a Internet de los equipos de la LAN con lo que a todo el tráfico que salga por la interfaz eth2 se le hará una traducción de la dirección IP de origen para que refleje nuestra IP pública que en este caso será 192.0.2.10 (dirección TEST-NET) Creamos la regla 10 con los siguientes comandos: vyatta@openredesR1:~$ configure vyatta@openredesR1# set service nat rule 10 outbound-interface eth2 vyatta@openredesR1# set service nat rule 10 type masquerade



La siguiente regla a crear será para que las peticiones que se hagan desde internet al puerto 80 de nuestra IP pública se traduzcan y se envíen a la IP del servidor web. Creamos la regla 20 con los siguientes comandos:



vyatta@openredesR1# set service nat rule 20 destination port 80



vyatta@openredesR1# set service nat rule 20 inbound-interface eth2



vyatta@openredesR1# set service nat rule 20 inside-address address 192.168.0.225



vyatta@openredesR1# set service nat rule 20 protocol tcp

vyatta@openredesR1# set service nat rule 20 type destination



De la misma forma que en la regla anterior creamos la regla 30 que traducirá las peticiones al puerto 443 (https) de la IP pública a la IP del servidor web. Creamos la regla 30 con los siguiente comandos:
















Al igual que pasamos a nuestro servidor web mediante DNAT las peticiones http y https (80 y 443) que recibamos vamos a pasar tambien al servidor de email las peticiones que recibamos a los puertos 25, 110, 465 y 995 (smtp, pop3, ssmtp y pop3s) en la IP pública. Para lo que creamos las reglas 40, 50, 60 y 70 con los siguientes comandos:































































vyatta@openredesR1# commit

vyatta@openredesR1# save

Con esto ya tenemos el servicio NAT configurado y funcionando para openredesR1 según las necesidades que reflejadas en la topología ejemplo.

Para ver como ha quedado la configuración: vyatta@openredesR1# show service nat rule 10 { outbound-interface eth2 type masquerade } rule 20 { destination { port 80 } inbound-interface eth2 inside-address { address 192.168.0.225 } protocol tcp type destination } rule 30 { destination { port 443 } inbound-interface eth2 inside-address { address 192.168.0.225 } protocol tcp type destination

} rule 40 { destination { port 25 } inbound-interface eth2 inside-address { address 192.168.0.226 } protocol tcp type destination } rule 50 { destination { port 110 } inbound-interface eth2 inside-address { address 192.168.0.226 } protocol tcp type destination } rule 60 { destination { port 465 } inbound-interface eth2 inside-address { address 192.168.0.226 } protocol tcp type destination

} rule 70 { destination { port 995 } inbound-interface eth2 inside-address { address 192.168.0.226 } protocol tcp type destination } [edit]

Configuramos ahora el servicio de NAT en openredesR2: En este caso no tenemos ningún servicio al que se pueda acceder públicamente y todas las direcciones privadas son conocidas en la red por lo que únicamente necesitamos una regla que traduzca la IP origen de las peticiones que salgan a internet por la IP pública de nuestra línea ADSL. Creamos la regla 10 con los siguientes comandos: vyatta@openredesR2# set service nat rule 10 outbound-interface eth2 vyatta@openredesR2# set service nat rule 10 type masquerade

Para ver como ha quedado la configuración: vyatta@openredesR2# show service nat rule 10 { outbound-interface eth2 type masquerade } [edit]

VYATTA Manual Total

Recommend Documents