VPSs y mas.

Mostrando entradas con la etiqueta NAT. Mostrar todas las entradas
Mostrando entradas con la etiqueta NAT. Mostrar todas las entradas

lunes, 25 de mayo de 2015

Animacion: La triste historia de un ISP sin IPv6

`




La triste historia de un ISP sin IPv6. Guion: Alejandro Acosta, Producido en: Universidad de Guadalajara - Coordinacion General de Tecnologia de Informacion, Animacion y Diseno: Marco Sierra, Voz: Dolores Hernandez - Red Radio Universidad de Guadalajara, Grabacion: Mauricio Urbina - Red Radio Universidad de Guadalajara, Edicion: de Sonido Marco Sierra, Tema Musical: "Children" Matti Paalanen.

Historia original en: https://blog.acostasite.com/2015/01/tecno-cuento-la-triste-historia-de-un.html

miércoles, 23 de julio de 2014

NAT66 en Linux

Hola,
  El dia de hoy voy a hacer un post el cual no deseo que sea tomado de mala manera. Indiscutiblemente no estoy a favor del NAT pero aun asi pienso que es un mecanismo que no desaparecera en IPv6 (se reducira drasticamente) pero siempre existira. En lo posible recomiendo evitar hacer NAT cuando exista la posibilidad.
  Pueden haber muchas razones para implementar NAT66, a) seguramente los clientes acostumbrados a hacer NAT querran hacerlo en IPv6 (suene feo o bonito), b) personas que quieran ocultar su topologia a Internet, c) empresas que consideren NAT como mecanismo para cambiar los IPs de sus redes, d) la tendencia mundial de no permitir tethering en los celulares, e) querer ofrecer IPv6 detras de un dispositivo y mi proveedor no tenga DHCPv6-PD o solo me entregue una red /64, f) alguien que piense que NAT sirve de mecanismo de seguridad, etc, etc, etc, etc.

  En base a lo anterior la intencion de este post no es estar a favor o en contra de NAT, solo deseo indicar que esta disponible en el mundo de IPv6 y ofrecer un sencillo ejemplo. Para bien o para mal puede ser utilizado en algunos escenarios.

Requerimientos:
  El equipo a realizar el NAT66 debe tener:
  - Kernel > 3.9 
  - iptables > 1.4.18

  Ubuntu 14.04 cubre ambos requerimientos "out-of-the-box" y por ello es muy sencillo hacerlo.

  Existen patch para hacer NAT66 en versiones previas pero no lo indicare en este momento.

Escenario:
  Esta es la topologia en la que estoy trabajando. Deseo que "Device 2"  traduzca la direccion IPv6 origen de "Device 1" con la direccion IPv6 de la interfaz saliente (eth2). Con el comando NAT implementado estoy realmente haciendo NAT de toda la subred 2001:db8:12::/48




Configuraciones:

En DEVICE 1:
#ifconfig eth0 inet6 add 2001:db8:12::2/48
#route -A inet6 add default gw 2001:db8:12::1

En DEVICE 2:

Configurar las direcciones IPv6 en el equipo
#ifconfig eth1 inet6 add 2001:db8:12::1/48
#ifconfig eth2 inet6 add 2001:db8:23::1/48

Habilitar enrutamient o IPv6 entre las interfaces:
#sysctl -w net.ipv6.conf.all.forwarding=1

Configurar el NAT66:
#ip6tables -t nat -A POSTROUTING -o eth2 -s 2001:db8:12::/48 -j MASQUERADE

(es de notar que existen muchas otras maneras de hacer NAT con ip6tables)

En DEVICE 3:
#ifconfig eth1 inet6 add 2001:db8:23::2/48
#route -A inet6 add default gw 2001:db8:23::1


  Del lado de Device 3 pueden verificar de muchas maneras que todo funcione, incluso sin ruta por default en Device 3, DEVICE 1 puede llegarle. De igual manera tcpdump, wireshark o una sencilla revision de los logs puedes verificar que efecticamente el NAT esta llevandose a cabo.

  Espero sea de tu utilidad


jueves, 6 de septiembre de 2012

Tunel GRE entre Cisco y Linux + NAT

Introducción:
  En el siguiente escenario se plantean dos oficinas conectadas mediante un tunel GRE. En la oficina "A" existe un router Cisco y en la oficina "B" un servidor Linux.

Objetivo:
  Que la oficina "A" (la red con el router Cisco) salga a Internet (nateada) con el IP de la red de la oficina "B" (red con el servidor Linux)


Topologia:
 
Lado Cisco (Oficina A):
   LAN: 192.168.56.6
   WAN: 98.76.54.32
   TUNNEL 0: 192.168.56.6

Lado Linux (Oficina B):

   LAN: 192.168.1.200/24  (gre_if0)
   WAN: 123.45.67.89 (Interfaz: venet0:0)

Pasos (lado equipo Linux):
1) Levantar el modulo GRE
  #modprobe ip_gre

2) Crear la interfaz del tunel (llamada gre_if0). Puede tener cualquier nombre:
   #ip tunnel add gre_if0 mode gre remote 98.76.54.32 local 123.45.67.89 ttl 255

3) Asignarle un IP a la interfaz recien creada (gre_if0)
   #ip addr add 192.168.1.200/24 dev gre_if0

4) Levantar la interfaz del tunel (por defecto viene shutdown)
   #ip link set gre_if0 up (Levantar la interfaz gre_if0)

5) Enrutar por el tunel aquellas rutas que sean necesarias, por ejemplo: 
   #route add -net 192.168.56.6 netmask 255.255.255.255 dev gre_if0

Pasos (lado Cisco)



!Creación de la interfaz tunel
interface Tunnel0
 ip unnumbered FastEthernet0/0
 tunnel source Vlan1
 tunnel destination 123.45.67.89
 

!Configuración de la interfaz LAN
interface FastEthernet0/0
 description **Conexion LAN**
 ip address 192.168.56.6 255.255.255.252
 duplex auto
 speed auto
 

!La interfaz VLAN1 es la interfaz WAN
interface Vlan1
 description **Conexion WAN**
 ip address 98.76.54.32 255.255.255.248
 

!Hacer las rutas necesarias en el router
!para alcanzar la LAN de la oficina B
ip route 192.168.1.200 255.255.255.255 Tunnel0


PARA EL NAT (LADO LINUX):

1) Permitir routing en el equipo
  # echo 1 > /proc/sys/net/ipv4/ip_forward

2) Que el servidor Linux sepa alcanzar la LAN de Oficina A
   #route add -net 192.168.56.0 netmask 255.255.255.0 dev gre_if0


3) Realizar el NAT
   # iptables -A POSTROUTING -t nat -s 192.168.56.0/24 -j SNAT --to 123.45.67.89





  Notese que hubo que hacer Source NAT (SNAT). La explicación del motivo está indicada en el post: "Linux iptables, solucion al error: Warning: wierd character in interface"

 
Espero te sea útil,

lunes, 13 de agosto de 2012

Entrevista en la radio sobre IPv6



http://tecnologiahechapalabra.com/archivo/media.asp?i=858

Gustavo Terrero, Presidente de CAVEDATOS; Ricardo Holmquist, Presidente de ISOC Venezuela; y Alejandro Acosta, director del Foro Latinoamericano de IPv6; conversan con Peter Cernik en la oportunidad de explicar la necesidad de migrar toda la estructura de direcciones de internet al Protocolo de Internet version 6, que debe sustituir al IPv4, ya que este último ha agotado su capacidad de manejar identificaciones únicas para cada dispositivo conectado y por conectarse en la red de redes.

Click Aqui

- - - 

Duración = 00:24:38. 


Tomado de/Información original en:
http://tecnologiahechapalabra.com/archivo/media.asp?i=858

lunes, 27 de septiembre de 2010

Ejemplos de manipulacion de port forwarding utilizando NAT en routers Cisco

Situacion:
Tengo una granja de servidores (ejemplo Web, Mail y SSH) y tengo solo una direccion publica en mi router de borde.

Escenario:
{Internet} --- {RTR con IP publica} ------- {Granja de Servidores}

IP Publica: 11.12.13.14
Mail Server: 192.168.1.5
Web Server: 192.168.1.4
SSH: 192.168.1.6

IP WAN: 11.12.13.14/30
IP LAN: 192.168.1.1/24

Solucion:
La solucion es configurar en el router Cisco NAT de tal manera de que al momento de recibir un paquete TCP al puerto destino correspondiente sepa a donde enviarlo.
En este sentido, es necesario que el router re-envie los paquetes (port forwarding) de la siguiente manera:

Paquetes destinados al IP 11.12.13.14 al puerto destino 25 lo envie al Mail Server (192.168.1.5)
Paquetes destinados al IP 11.12.13.14 al puerto destino 80 lo envie al Web Server (192.168.1.4)
Paquetes destinados al IP 11.12.13.14 al puerto destino 22 lo envie al SSH Server (192.168.1.6)

Procedimiento:
La configuracion del router seria la siguiente:

! ESTA ES LA INTERFAZ QUE DA HACIA LA GRANJA DE SERVIDORES
interface FastEthernet0
description Mi granja de servidores
ip address 192.168.1.1 255.255.255.0
ip nat inside
!
! ESTA ES LA INTERFAZ QUE DA HACIA INTERNET
interface Serial0
description Hacia Internet
ip address 11.12.13.14 255.255.255.252
ip nat outside
!
!En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 80 lo envie al !servidor web
ip nat inside source static tcp 192.168.1.4 80 11.12.13.14 80 extendable

!En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 25 lo envie al !servidor mail
ip nat inside source static tcp 192.168.1.5 25 11.12.13.14 25 extendable

!En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 22 lo envie al !servidor ssh
ip nat inside source static tcp 192.168.1.4 22 11.12.13.14 22 extendable

Tips
Un dato muy interesante que es que se puede manipular el puerto. Por ejemplo, supongamos que tenemos un servidor web "escondido" podemos manejarlo con un puerto diferente al 80. Digamos que queremos que la gente desde Internet acceda a nuestro servidor Web utilizando el puerto 61234 podemos hacer lo siguiente:

!El usuario desde Internet debe acceder a http://11.12.13.14:61234
ip nat inside source static tcp 192.168.1.4 80 11.12.13.14 61234 extendable

Lo anterior es muy util para escoder servicios, ahorrar direcciones IP y darle seguridad a la red.


Espero haya sido de tu utilidad,

Suerte!

miércoles, 4 de agosto de 2010

Guardar los registros del nat translation en un servidor Linux

Situación:
Deseo guardar en un servidor Linux las entradas de NAT en un router Cisco de tal manera de conocer siempre que dirección IP y puerto tenian asignado en un moment especifico.


Solución:

Salvar cada uno de los registros NAT creado por el Router Cisco en un servidor Linux (Debian) usando rsyslog...

Procedimiento:
Comencemos con el servidor Linux...

Para lograr esto, empezamos creando el archivo que vamos a utilizar para guardar todo los registros que nos va a enviar el router.

#touch /var/log/cisco-nat.log
#chmod 640 /var/log/cisco-nat.log

Una vez hecho esto, procedemos a editar el siguiente archivo "/etc/rsyslog.conf" y tenemos que quitarle el símbolo de "#" (usados para documentar) a las siguientes entradas:


# provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

Quedando de la siguiente manera,

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

Adicionalmente, agregamos las siguientes entradas

$UDPServerAddress 0.0.0.0
$AllowedSender UDP, 3.3.3.3

La primera usada para decirle que use toda las interfaces que tenga disponible, y la segunda, "3.3.3.3" la usamos para permitirle a la dirección 3.3.3.3 enviar los registros.

Luego, procedemos a colocar la siguiente linea

local7.* /var/log/cisco-nat.log

(Opcional)

Una vez que hayamos colocado las entradas mencionadas anteriormente, es posible que estas se empiecen a duplicar en los archivos "syslog" o "messages", etc...

Para evitar que esto ocurra y tengamos las entradas duplicadas en los archivos, podemos editar las entradas que mencionan "syslog" y "messages"

Por ejemplo,

Esta linea:
*.* -/var/log/syslog
La modificamos para que quede de la siguiente manera

*.*;local7.* -/var/log/syslog

De esta manera evitamos que los registros se dupliquen...

Una vez hecho esto, reiniciamos el servicio de la siguiente manera:

/etc/init.d/rsyslog restart


Luego, en el equipo cisco, es bastante sencillo lo que tenemos que hacer...

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# no logging console
Router(config)# no logging monitor
Router(config)# ip nat log trans sys
Router(config)# logging host 1.1.1.1


Listo!!!!!

Ya deberíamos de comenzar a ver los registros de nuestro Router en el archivo cisco-nat.log


Revisión:
A continuación, una muestra de como quedaría


2010-08-04T16:52:23.759260-04:18 3.3.3.3 2178773: 14w1d: %IPNAT-6-NAT_CREATED: Created tcp 10.58.50.50:64807 11.11.11.11:30079 192.69.239.224:445 192.69.239.224:445
2010-08-04T16:52:23.764009-04:18 3.3.3.3 2178774: 14w1d: %IPNAT-6-NAT_CREATED: Created tcp 10.58.51.2:3019 11.11.11.11:30167 69.63.190.18:80 69.63.190.18:80

Cualquier comentario se agradece.

Suerte!

viernes, 12 de junio de 2009

NAT en Cisco. 2 ISPs diferentes

Necesidad:
Tener un enlace primario y un enlace secundario en un mismo router con dos proveedores a Internet diferentes.

Escenario(abajo la configuracion detallada y explicada):
Router Cisco 1760 donde:
Interfaz Fastethernet0/0 LAN (IP 172.20.0.1)
Internaz Serial1/0.1 ISP Primario (IP 10.0.0.58)
Internaz Serial0/0.1 ISP Secundario (IP 10.1.1.58)

Diagrama:








Procedimiento:

Primero es necesario configurar unas rutinas en el router que se van a encargar de monitorear las interfaces WAN.

ip sla monitor 1 (deseo monitorar el next-hop del enlace del ISP primario)
type echo protocol ipIcmpEcho 10.0.0.57 source-interface Serial1/0.1
timeout 1000
threshold 400
frequency 3
ip sla monitor schedule 1 life forever start-time now (esta linea es para activar realmente el monitoreo)
ip sla monitor 2 (deseo monitorar el next-hop del enlace del ISP secundario)
type echo protocol ipIcmpEcho 10.1.1.57 source-interface Serial0/1.1
timeout 2000
threshold 1000
frequency 3
ip sla monitor schedule 2 life forever start-time now (esta linea es para activar realmente el monitoreo)
!

Con las lineas arribas indicadas lo que se hace es monitorear si el next hop en el enlace WAN esta levantado. Por ejemplo en el primer caso se hace ping (ipIcmpEcho) al IP 10.0.0.57, con un timeout de 2000 ms, un umbral de 1000 ms cada 3 segundos.


Posteriormente es necesario habilitar los comandos track en Cisco. Estos son muy utiles para conocer luego el estado de los SLA previamente configurados. Los comandos son:

track 123 rtr 1 reachability
delay down 15 up 10
!
track 345 rtr 2 reachability
delay down 15 up 10
!

El truco se encuentra en el NAT (tanto asi que lo anterior se puede hacer con rutas flotantes, sin embargo de la manera implementada es la mejor practica). El NAT debe ser realizado en base a route-maps (no lo intentes de otra manera). Las lineas que personalmente utilice fueron:

ip nat pool POOL-MINAT 200.30.30.30 200.30.30.30 prefix-length 29
ip nat inside source route-map ISP-1 pool POOL-MINAT overload
ip nat inside source route-map ISP-2 interface Serial0/1.1 overload

access-list 150 remark PARA-NAT
access-list 150 permit ip 172.20.0.0 0.0.0.255 any

route-map ISP-1 permit 5
match ip address 150
match interface Serial1/0.1
!
route-map ISP-2 permit 5
match ip address 150
match interface Serial0/1.1


En el ejemplo anterior vemos que el NAT es en base a los route-maps ISP-1 e ISP-2, el ACL a utilizar es el 150 extendido donde estamos nateando toda la red 172.20.0.0/24

Cuando los paquetes salgan por el ISP-1 saldran nateados con el IP 200.30.30.30 y cuando salgan con el ISP-2 saldran con el IP de la interfaz WAN. Logicamente puedes ajustar esto a tu necesidad.

Ahora bien, la ruta de los paquetes de salida son definidas con la siguiente configuracion:

ip route 0.0.0.0 0.0.0.0 Serial1/0.1 track 123
ip route 0.0.0.0 0.0.0.0 Serial0/1.1 track 345

La ruta por default es la interfaz s1/0.1 cuando el IP 10.0.0.57 se encuentre UP, en caso de que se caiga la interfaz y/o el ping al IP 10.0.0.57 NO sea satisfactorio se utilizara la ruta por la interfaz S0/1.1 (enlace secundario)


Verificacion:

1760-WAN#sh track 123
Track 123
Response Time Reporter 1 reachability
Reachability is Up
33 changes, last change 08:27:17
Delay up 10 secs, down 15 secs
Latest operation return code: OK
Latest RTT (millisecs) 11



1760-WAN#sh track 345
Track 345
Response Time Reporter 2 reachability
Reachability is Up
36 changes, last change 3d01h
Delay up 10 secs, down 15 secs
Latest operation return code: OK
Latest RTT (millisecs) 8



1760-WAN#sh ip nat t
[OUTPUT SUPRESSED]




Links de informacion:

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_example09186a0080950834.shtml
y
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_example09186a00808d2b72.shtml



Espero haya sido de tu ayuda,

Suerte!,