info_i_25x25.png Due to unforeseen weather conditions we are experiencing higher chat wait times. Remember you can also submit a ticket and one of our support representatives will get back to you as soon as possible. We apologize for the inconvenience.

EdgeMAX - política dirección basada en enrutamiento (fuente base)

Resumen


Los lectores aprenderán a configurar enrutamiento basado en políticas basado en la dirección de la fuente. 

Este artículo es un ejemplo de cómo configurar el PBR (enrutamiento basado en políticas) en EdgeOS a ruta basado en una dirección de origen en lugar de destino.

En el siguiente diagrama, tenemos 2 conexiones de Internet, ISP-1 y 2 de ISP:

  1. ISP-1 eth0 192.0.2.0/24
  2. ISP-2 203.0.113.0/24 eth1


En el lado LAN usaremos vlans:

  1. eth2.100 192.168.0.0/24
  2. eth2.200 172.16.0.0/24


En este ejemplo queremos que el tráfico de vlan 100 usar ISP-1 y el tráfico de vlan 200 usar ISP-2. 

Diagrama de red

 

Enrutamiento basado en políticas

Hay 3 partes configuración PBR en EdgeOS:

  1. Definir una nueva tabla de enrutamiento con rutas estáticas para cada destino.
  2. Definir un cortafuegos modificar la política para seleccionar una tabla de enrutamiento diferente.
  3. Aplicar el cortafuegos modificar política a una interfaz.

Definir nuevas tablas de enrutamiento

Para vlan 100, definimos tabla 1, con una ruta por defecto al ISP-1 dirección de salto siguiente (192.0.2.1).

[email protected]# set protocols static table 1 route 0.0.0.0/0 next-hop 192.0.2.1
[edit]

Para vlan 200, definimos tabla 2 con una ruta por defecto a la dirección de salto siguiente ISP-2 (203.0.113.1).

[email protected]# set protocols static table 2 route 0.0.0.0/0 next-hop 203.0.113.1
[edit]

Definir política de modificar

A modificar política nos permite modificar varios artículos cuando coincide con la regla. Así que si la dirección origen provino de 192.168.0.0, entonces queremos usar enrutamiento tabla 1:

[email protected]# set firewall modify SOURCE_ROUTE rule 10 description 'traffic from eth2.100 to ISP1'
[email protected]# set firewall modify SOURCE_ROUTE rule 10 source address 192.168.0.0/24
[email protected]# set firewall modify SOURCE_ROUTE rule 10 modify table 1

Del mismo modo vamos a crear una regla de 20 para fuente dirección 172.16.0.0/24 utilizar tabla 2.

[email protected]# set firewall modify SOURCE_ROUTE rule 20 description 'traffic from eth2.200 to ISP2'
[email protected]# set firewall modify SOURCE_ROUTE rule 20 source address 172.16.0.0/24
[email protected]# set firewall modify SOURCE_ROUTE rule 20 modify table 2

Aplicar la Directiva a la interfaz

Cuando se trata de aplicar una política a una interface, debe hacerse en la interfaz de entrada antes de que la búsqueda de enrutamiento lleva a cabo.

[email protected]# set interfaces ethernet eth2 vif 100 firewall in modify SOURCE_ROUTE
[edit]
[email protected]# set interfaces ethernet eth2 vif 200 firewall in modify SOURCE_ROUTE
[edit]

Prueba

Este momento debería ser suficiente para verificar que los hosts en las diferentes 2 VLAN se enrutan basándose en su dirección de origen.

Realizar un traceroute desde un host en 192.168.0.0/24 y vemos que el router 2 es 192.0.2.1:

[email protected]:~$ traceroute google.com
Resolving Address: google.com
traceroute to google.com (74.125.224.110), 30 hops max, 60 byte packets
 1 192.168.0.1 (192.168.0.1) 0.448 ms 0.603 ms 0.704 ms
 2 192.0.2.1 (192.0.2.1) 1.354 ms 1.397 ms 1.444 ms
 <snip>

Realizar un traceroute desde un host en 172.168.0.0/24 y vemos que el router 2 es 203.0.113.1:

[email protected]:~$ traceroute google.com
traceroute to google.com (74.125.224.110), 30 hops max, 38 byte packets
 1 172.16.0.1 (172.16.0.1) 0.331 ms 0.275 ms 0.264 ms
 2 203.0.113.1 (203.0.113.1) 0.545 ms 0.406 ms 0.357 ms
 <snip> 

Comando show

El siguiente comando se utiliza para mostrar la tabla de enrutamiento principal:

[email protected]:~$ show ip route
 Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
 I - ISIS, B - BGP, > - selected route, * - FIB route
 C>* 127.0.0.0/8 is directly connected, lo
 C>* 192.0.2.0/24 is directly connected, eth0
 C>* 203.0.113.0/24 is directly connected, eth1
 C>* 172.16.0.0/24 is directly connected, eth2.200
 C>* 192.168.0.0/24 is directly connected, eth2.100


Para ver una de las tablas de encaminamiento adicionales:

[email protected]:~$ show ip route table 1
 table 1:
 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 192.0.2.1, eth0
[email protected]:~$ show ip route table 2
 table 2:
 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 203.0.113.1, eth1 

FAIL sobre

Dado que tenemos 2 ISPs, sería bueno que si 1 link fallado, entonces todo el tráfico que podría utilizar el buen enlace. Por ejemplo, si el enlace ISP-2 está abajo, en la tabla de enrutamiento verás la ruta es inactivos .

[email protected]:~$ show ip route table 2
 table 2:
 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 203.0.113.1 inactive

Si no hay ninguna ruta en la tabla 2, entonces lo probaré la mesa principal, pero actualmente no hay ninguna ruta por defecto en la mesa principal. Utilice los siguientes comandos para agregar una ruta predeterminada para cada ISP.

[email protected]:~$ configure
[edit]
[email protected]# set protocols static route 0.0.0.0/0 next-hop 192.0.2.1
[edit]
[email protected]# set protocols static route 0.0.0.0/0 next-hop 203.0.113.1
[edit]
[email protected]# commit
[edit]
[email protected]# save; exit
Saving configuration to '/config/config.boot'...
Done
exit

Ahora si nos fijamos en la tabla de ruta #2, vemos que usará en su lugar la otra ruta de acceso:

[email protected]:~$ show ip route table 2
 table 2:
 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 203.0.113.1 (recursive via 192.0.2.1)

Un traceroute muestra que ahora está tomando el camino alternativo:

[email protected]:~$ traceroute google.com
traceroute to google.com (74.125.224.137), 30 hops max, 38 byte packets
 1 172.16.0.1 (172.16.0.1) 0.327 ms 0.281 ms 0.255 ms
 2 192.0.2.1 (192.0.2.1) 0.551 ms 0.390 ms 0.357 ms
 <snip>

Tráfico de LAN a LAN

En el ejemplo anterior, la vlan no será capaces de hablar entre sí ya que sus tablas de enrutamiento sólo tienen una ruta por defecto. Puede que sea lo que quiera, pero si no, podemos añadir una regla delante de la normativa de la PBR para utilizar la tabla de encaminamiento principal si la red de destino es una de las redes LAN.

Primero vamos a crear un grupo de cortafuegos con nuestras redes LAN:

[email protected]# set firewall group network-group LAN_NETS network 192.168.0.0/24
[edit]
[email protected]# set firewall group network-group LAN_NETS network 172.16.0.0/24
[edit]

A continuación vamos a crear una regla 5, que utiliza el grupo LAN_NETS y selecciona el principal tabla de enrutamiento.

[email protected]# set firewall modify SOURCE_ROUTE rule 5 description "LAN to LAN skip PBR"
[edit]
[email protected]# set firewall modify SOURCE_ROUTE rule 5 destination group network-group LAN_NETS
[edit]
[email protected]# set firewall modify SOURCE_ROUTE rule 5 modify table main
[edit]

Después de esto, nuestras reglas SOURCE_ROUTE aspecto:

[email protected]# show firewall modify SOURCE_ROUTE
enable-default-log
rule 5 {
 description "LAN to LAN skip PBR"
 destination {
 group {
 network-group LAN_NETS
 }
 }
 modify {
 table main
 }
}
rule 10 {
 action modify
 description "traffic from eth2.100 to ISP1"
 modify {
 table 1
 }
 source {
 address 192.168.0.0/24
 }
}
rule 20 {
 action modify
 description "traffic from eth2.200 to ISP2"
 modify {
 table 2
 }
 source {
 address 172.16.0.0/24
 }
}
[edit]


Nota : las reglas que utilizan un modificar tabla comandos son "terminal" en que una vez que se encuentra una coincidencia, se detiene. Así en el ejemplo anterior, si regla 5 es un partido, entonces no se verá en la regla 10 o 20. Sin embargo, esto puede ser algo malo si también usas el modificar comandos para cambiar los otros elementos (marca, dscp, mss de tcp). En esos casos, esas otras reglas de modificar deben venir antes de las reglas PBR.

Ejemplo de configuración

[email protected]:~$ cat /config/config.boot
firewall {
 all-ping enable
 broadcast-ping disable
 conntrack-expect-table-size 4096
 conntrack-hash-size 4096
 conntrack-table-size 32768
 conntrack-tcp-loose enable
 group {
 network-group LAN_NETS {
 network 192.168.0.0/24
 network 172.16.0.0/24
 network 10.0.0.0/24
 }
 }
 ipv6-receive-redirects disable
 ipv6-src-route disable
 ip-src-route disable
 log-martians enable
 modify SOURCE_ROUTE {
 enable-default-log
 rule 5 {
 action modify
 description "LAN to LAN skip PBR"
 destination {
 group {
 network-group LAN_NETS
 }
 }
 modify {
 table main
 }
 }
 rule 10 {
 action modify
 description "traffic from eth2.100 to ISP1"
 modify {
 table 1
 }
 source {
 address 192.168.0.0/24
 }
 }
 rule 20 {
 action modify
 description "traffic from eth2.200 to ISP2"
 modify {
 table 2
 }
 source {
 address 172.16.0.0/24
 }
 }
 }
 receive-redirects disable
 send-redirects enable
 source-validation disable
 syn-cookies enable
}
interfaces {
 ethernet eth0 {
 address 192.0.2.2/24
 }
 ethernet eth1 {
 address 203.0.113.2/24
 }
 ethernet eth2 {
 address 10.0.0.1/24
 firewall {
 in {
 modify SOURCE_ROUTE
 }
 }
 vif 100 {
 address 192.168.0.1/24
 firewall {
 in {
 modify SOURCE_ROUTE
 }
 }
 }
 vif 200 {
 address 172.16.0.1/24
 firewall {
 in {
 modify SOURCE_ROUTE
 }
 }
 }
 }
 loopback lo {
 }
}
protocols {
 static {
 route 0.0.0.0/0 {
 next-hop 192.0.2.1 {
 }
 next-hop 203.0.113.1 {
 }
 }
 table 1 {
 route 0.0.0.0/0 {
 next-hop 192.0.2.1 {
 }
 }
 }
 table 2 {
 route 0.0.0.0/0 {
 next-hop 203.0.113.1 {
 }
 }
 }
 }
}
service {
 dhcp-server {
 disabled false
 shared-network-name LAN {
 authoritative disable
 subnet 10.0.0/24 {
 default-router 10.0.0.1
 dns-server 10.0.0.1
 lease 86400
 start 10.0.0.10 {
 stop 10.0.0.100
 }
 }
 }
 shared-network-name LAN1 {
 authoritative disable
 subnet 192.168.0.0/24 {
 default-router 192.168.0.1
 dns-server 192.168.0.1
 lease 86400
 start 192.168.0.10 {
 stop 192.168.0.100
 }
 }
 }
 shared-network-name LAN2 {
 authoritative disable
 subnet 172.16.0.0/24 {
 default-router 172.16.0.1
 dns-server 172.16.0.1
 lease 86400
 start 172.16.0.10 {
 stop 172.16.0.100
 }
 }
 }
 }
 dns {
 forwarding {
 cache-size 150
 listen-on eth2
 listen-on eth2.100
 listen-on eth2.200
 }
 }
 gui {
 https-port 443
 }
 nat {
 rule 5000 {
 outbound-interface eth0
 type masquerade
 }
 rule 5010 {
 outbound-interface eth1
 type masquerade
 }
 rule 5011 {
 outbound-interface eth0
 type masquerade
 }
 }
 snmp {
 community public {
 authorization ro
 }
 }
 ssh {
 port 22
 protocol-version v2
 }
 telnet {
 port 23
 }
}
system {
 host-name RTR
 login {
 user ubnt {
 authentication {
 encrypted-password $1$zKNoUbAo$gomzUbYvgyUMcD436Wo66.
 }
 level admin
 }
 }
 name-server 8.8.8.8
 ntp {
 server 0.ubnt.pool.ntp.org {
 }
 server 1.ubnt.pool.ntp.org {
 }
 server 2.ubnt.pool.ntp.org {
 }
 server 3.ubnt.pool.ntp.org {
 }
 }
 syslog {
 global {
 facility all {
 level notice
 }
 facility protocols {
 level debug
 }
 }
 }
 time-zone US/Pacific
}
/* Warning: Do not remove the following line. */
/* === vyatta-config-version: "[email protected]:[email protected]:[email protected]:dhcp-rela[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:ubn[email protected]:[email protected]:[email protected]:[email protected]:[email protected]" === */
/* Release version: v1.0.3dev.4530060.130124.0102 */