Blog en espanol destinado a diferentes temas tecnicos principalmente en IT y Networking. Se desea cubrir Linux, DNS, DNSSEC, RPKI, BGP, Cisco, Programacion (Bash, Python, etc), Protocolos de Enrutamiento, Seguridad en Redes, VoIP.
miércoles, 6 de mayo de 2015
Demostracion de Secuestro de Prefijos - RPKI - BGP (parte 2/2)
En este segundo video se muestra como manipular Quagga para que tome decisiones en base al estado del prefijo RPKI. Continuacion de: https://blog.acostasite.com/2015/05/demostracion-de-secuestro-de-prefijos.html
martes, 5 de mayo de 2015
Demostracion de Secuestro de Prefijos - RPKI - BGP (parte 1/2)
El video muestra un ejemplo de como ocurre un secuestro de un prefijo de red en Internet y a su vez muestra como RPKI ayudaría a prevenir esta situación
lunes, 27 de abril de 2015
Construyendo una topología de red 464XLAT (mecanismo de transicion)
Introducción:
El siguiente post indica el procedimiento que puedes seguir para tener una topología de red con 464XLAT
Topología:
Que se necesita:
Del lado del cliente:
- Un cliente CLAT, en nuestro ejemplo utilizamos: https://github.com/toreanderson/clatd
- Tayga como NAT64 (http://www.litech.org/tayga/) En este post puedes conseguir el procedimiento de instalación (más abajo dejo todos los archivos de configuración)
y del lado del servidor:
- Tayga como NAT64 (http://www.litech.org/tayga/) En este post puedes conseguir el procedimiento de instalación (más abajo dejo todos los archivos de configuración)
- Para nuestro ejemplo un DNS Server pero si tienes otro puedes obviarlo. Es recomendable utilizar DNS64 para facilitar el reconocimiento de red cuando se ejecute el clatd.
- radvd (para hacer los anuncios RA y que el cliente se auto-configure), una vez puedes obviarlo y hacer tus configuraciones manuales
Configuraciones:
Del lado del cliente:
En lineas generales no es necesario configuar nada. El tayga utiliza un archivo de ejemplo construido en el momento y el clatd verifica todo lo necesario. Por favor asegura que el archivo /etc/resolv.conf contenga la línea;
nameserver 2001:13c7:100:f101::1
IMPORTANTE: Del lado del cliente lo unico que hay que hacer es ejecutar el cliente clatd. El procedimiento es el siguiente:
#unzip clatd-master
#cd clatd-master
#./clatd
Con este último comando el clatd será capaz de reconocer que NO hay direcciones IPv4 en el equipo donde se ejecuta y reconocer como es su conectividad hacia el exterior.
Del lado del servidor (6 pasos):
1) El radvd se configura en el archivo /etc/radvd.conf y debe quedar así:
interface eth0 {
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
prefix 2001:13c7:0100:f101::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};
2) Tayga: Del lado del servidor si es muy importante realizar una configuración de tayga. Para nuestro ejemplo:
En /usr/local/etc/tayga.conf:
tun-device nat64
ipv4-addr 192.168.64.1
prefix 64:ff9b::/96
dynamic-pool 192.168.64.0/24
data-dir /var/log/tayga
ipv6-addr 2001:13c7:100:f101::1
3) Las interfaces del lado del servidor deben quedar así:
/usr/local/sbin/tayga --mktun
/sbin/ip link set nat64 up
/sbin/ip addr add 10.0.3.15 dev nat64
/sbin/ip addr add 64:ff9b::1 dev nat64
/sbin/ip route add 192.168.64.0/24 dev nat64
/sbin/ip route add 64:ff9b::/96 dev nat64
4) Levantar tayga:
/usr/local/sbin/tayga -d &
5) Hacer NAT de la red IPv4:
/sbin/iptables -t nat -A POSTROUTING -s 192.168.64.0/24 -o eth10 -j MASQUERADE
Anexo:
a) ping a un destino IPv4 desde el cliente:
El siguiente post indica el procedimiento que puedes seguir para tener una topología de red con 464XLAT
Topología:
Que se necesita:
Del lado del cliente:
- Un cliente CLAT, en nuestro ejemplo utilizamos: https://github.com/toreanderson/clatd
- Tayga como NAT64 (http://www.litech.org/tayga/) En este post puedes conseguir el procedimiento de instalación (más abajo dejo todos los archivos de configuración)
y del lado del servidor:
- Tayga como NAT64 (http://www.litech.org/tayga/) En este post puedes conseguir el procedimiento de instalación (más abajo dejo todos los archivos de configuración)
- Para nuestro ejemplo un DNS Server pero si tienes otro puedes obviarlo. Es recomendable utilizar DNS64 para facilitar el reconocimiento de red cuando se ejecute el clatd.
- radvd (para hacer los anuncios RA y que el cliente se auto-configure), una vez puedes obviarlo y hacer tus configuraciones manuales
Configuraciones:
Del lado del cliente:
En lineas generales no es necesario configuar nada. El tayga utiliza un archivo de ejemplo construido en el momento y el clatd verifica todo lo necesario. Por favor asegura que el archivo /etc/resolv.conf contenga la línea;
nameserver 2001:13c7:100:f101::1
IMPORTANTE: Del lado del cliente lo unico que hay que hacer es ejecutar el cliente clatd. El procedimiento es el siguiente:
#unzip clatd-master
#cd clatd-master
#./clatd
Con este último comando el clatd será capaz de reconocer que NO hay direcciones IPv4 en el equipo donde se ejecuta y reconocer como es su conectividad hacia el exterior.
Del lado del servidor (6 pasos):
1) El radvd se configura en el archivo /etc/radvd.conf y debe quedar así:
interface eth0 {
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
prefix 2001:13c7:0100:f101::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};
2) Tayga: Del lado del servidor si es muy importante realizar una configuración de tayga. Para nuestro ejemplo:
En /usr/local/etc/tayga.conf:
tun-device nat64
ipv4-addr 192.168.64.1
prefix 64:ff9b::/96
dynamic-pool 192.168.64.0/24
data-dir /var/log/tayga
ipv6-addr 2001:13c7:100:f101::1
3) Las interfaces del lado del servidor deben quedar así:
/usr/local/sbin/tayga --mktun
/sbin/ip link set nat64 up
/sbin/ip addr add 10.0.3.15 dev nat64
/sbin/ip addr add 64:ff9b::1 dev nat64
/sbin/ip route add 192.168.64.0/24 dev nat64
/sbin/ip route add 64:ff9b::/96 dev nat64
4) Levantar tayga:
/usr/local/sbin/tayga -d &
5) Hacer NAT de la red IPv4:
/sbin/iptables -t nat -A POSTROUTING -s 192.168.64.0/24 -o eth10 -j MASQUERADE
6) El DNS Server debe quedar con la siguiente directiva dentro de /etc/bind/named.conf.options:
dns64 64:ff9b::/96 {
clients {
any; };
}; // End of DNS64 Section
Un poco mas de como quedas las interfaces. La salida de ifconfig del lado del servidor:
eth10 Link encap:Ethernet HWaddr 00:0c:29:06:e9:cc
inet addr:10.0.3.15 Bcast:10.0.3.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe06:e9cc/64 Scope:Link
inet6 addr: 2001:13c7:7001:500::21/64 Scope:Global ---> HACIA WAN
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:42282238 errors:0 dropped:307 overruns:0 frame:0
TX packets:11377224 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5706072894 (5.7 GB) TX bytes:2226397897 (2.2 GB)
eth9 Link encap:Ethernet HWaddr 00:0c:29:06:e9:d6
inet addr:10.64.0.1 Bcast:10.64.0.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe06:e9d6/64 Scope:Link
inet6 addr: 2001:13c7:100:f101::1/64 Scope:Global --- HACIA LAN
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:652093 errors:0 dropped:72 overruns:0 frame:0
TX packets:2662969 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:84197892 (84.1 MB) TX bytes:1461857730 (1.4 GB)
nat64 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.3.15 P-t-P:10.0.3.15 Mask:255.255.255.255
inet6 addr: 64:ff9b::1/128 Scope:Global
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:1135938 errors:0 dropped:0 overruns:0 frame:0
TX packets:1074859 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:939693414 (939.6 MB) TX bytes:931853538 (931.8 MB)
Explicando todo lo anterior:
1) Supongamos que el cliente quiere acceder una direcciones IPv6.., no pasa nada extraño :-). El routing es 100% IPv6, no hay NAT, todo normal.
2) En el supuesto que el cliente quiera acceder a una dirección IPv4:
a) El cliente clatd otorgará un socket IPv4 a la aplicación
b) El paquete que construya el cliente será 100% IPv6. Será su dirección IPv6 origen y el destino será 64:ff9b::/96 + 32 bits de la dirección IPv4 destino. Recordemos que no hay IPv4 en el core de la red.
c) El PLAT (Tayga del lado del servidor) al recibir un paquete con destino 64:ff9b::/96 lo enruta por la interfaz TUN NAT64 (interfaz lógica) donde tayga remueve los primeros 96 bits del destino dejando unicamente los 32 bits menos significativos (la dirección IPv4). Al origen (IPv6) se le hace una mapeo stateless con una direccion IPv4 (del pool en el archivo de configuración (192.168.64.0/24).
d) Cuando el paquete con el origen 192.168.64.0/24 del servidor desee salir del equipo será nateado con iptables al IPv4 que tenga eth10 (/sbin/iptables -t nat -A POSTROUTING -s 192.168.64.0/24 -o eth10 -j MASQUERADE)
Anexo:
a) ping a un destino IPv4 desde el cliente:
b) Clatd ejecutándose:
c) Captura en Wireshark de un ping desde el cliente (IPv6 only) a un destino IPv4:
martes, 17 de febrero de 2015
Solucion a: quagga vtysh " Exiting: failed to connect to any daemons."
Situacion:
Al ejecutar el comando vtysh en el shell de linux para conectarse a los demonios de quagga (bgpd, ospfd, etc) da el siguiente error "Exiting: failed to connect to any daemons"
alejandro@miserver:~$ vtysh -d bgpd
Exiting: failed to connect to any daemons.
alejandro@miserver:~$ vtysh
Exiting: failed to connect to any daemons.
Solucion:
La solución es agregar al usuario con el que ejecutas vtysh al grupo quagga, para ello edita el archivo /etc/group.
La linea en /etc/group debe quedar algo asi:
quagga:x:1003:alejandro
puedes especificar varios haciendo:
quagga:x:1003:alejandro, john
Lo anterior es necesario porque la conexión a los demonios de quagga los realiza con UNIX domain socket y no todos los usuarios tienen acceso a dichos sockets.
Otra solución:
Otra solución puede ser durante la compilación especificar el grupo para la creación de los sockets pasando lo siguiente durante el configure:
./configure --enable-vty-group=group
Suerte, espero haya sido útil,
lunes, 26 de enero de 2015
Tecno-cuento: La triste historia de un ISP sin IPv6
Erase una vez..... Erase una vez, en un tiempo no muy lejano, un ISP muy grande que dominaba las telecomunicaciones de un país, se sentía poderoso y sin competencia. Cuando alguien necesitaba conectarse a Internet siempre recurrian a ellos. Tenían una penetración en el mercado envidiable para todos. Sin embargo, este ISP tan grande no había querido implementar nunca IPv6, pensaba que tenía suficientes direcciones IP para abastecerse, no percibían indicador alguno que dijera: tengo que tener el nuevo protocolo. Durante esos años, otro pequeño ISP si implementó IPv6, comenzaron a crecer lentamente, se dieron cuenta que el protocolo si marcaba una diferencia en sus clientes, ganaban usuarios gracias a tener soporte de dicho protocolo. Su penetración en el mercado crecía, ganaban más dinero y más respeto. Siendo más grandes le era más fácil conseguir mejores precios de equipos, de tráfico, de interconexión. Todo funcionaba muy bien. El ISP pequeño sencillamente no lo podía creer, algo tan sencillo de implementar como IPv6 le rendía frutos inimaginables. Sus clientes le decian que tenian crear VPNs y conferencias contra otras partes del mundo, que sus subsidiarias, clientes y aliados de negocio en Europa y Asia si tenían IPv6, por ello IPv4 no les era importante. El ISP grande, a pesar de ser tan poderoso comenzó a tener problemas internos, no eran problemas de facturación o dinero. Eran quejas del personal de ventas que no podían cerrar las mismas porque los clientes empezaron a pedir IPv6 y ellos siendo tan grandes e importantes sencillamente no tenían!!. Clientes corporativos pedían IPv6, usuarios residenciales solicitaban lo mismo, incluso grandes licitaciones del estado. Cuando eso empezó a ocurrir el Gerente de Ventas tuvo quejas hacia los departamentos de Producto, IngenierÃa y Operaciones. Estos últimos se quedaron sin palabras y algunos empleados fueron removidos por los dueños de las empresas. Al final, a Ventas no les importaba donde estaba la culpa, sencillamente no podían obtener nuevos clientes. Posteriormente algunos vendedores al percatarse que estaban perdiendo clientes fueron contratados por el ISP pequeño que estaba buscando personal, total ahora sí podían pagar a importantes vendedores porque en realidad ya no eran tan chicos. Lo mismo ocurrió con el jefe de redes del ISP grande que sabía mucho de IPv6 pero la burocracia no le había permitido llevar a producción el novedoso protocolo. Luego el jefe de redes lógicamente trajo a su administrador de servidores de confianza y su persona de seguridad. El ISP grande no podía creer lo que estaba pasando. Los vendedores contratados por el ISP chico (provenientes del ISP grande) venían con su enorme cartera de clientes, todos potenciales para ser instalados. Se avecinaba una estampida de clientes del ISP grande. Pasaban los meses y el ISP chico ya no solo ofrecía Internet, su Data Center era mucho más grande, importantes empresas trajeron servidores nuevos, de cache y mucho más. Ahora ofrecían co-location, hosting, virtual hosting, voz, video y más. Cuando el proveedor grande quiso implementar IPv6, tuvo que hacer las cosas muy rápidas, les salian mal, varios errores, además consultores y empresas se aprovecharon de sus problemas y cobraban mucho más para hacer las tareas con la premura que solicitaban. Aumentó el downtime de red, las llamadas al call center y la prestigiosa reputación se venía abajo. Como es de esperar, al final de la historia todos en el cuento: clientes y proveedores terminaron implementando IPv6, unos más felices que otros pero todos con IPv6 en sus redes Espero lo hayan disfrutado, y Colorín Colorado este cuento se ha acabado Abrazos a todos, Alejandro,
Get ready for Black Friday deals in South Africa with bidorbuy. We at bidorbuy are as excited as you are! We are hard at work to find the best deals at the best price to bring you a whole week of awesome Black Friday deals!
Suscribirse a:
Entradas (Atom)
Una propuesta inesperada dentro de IETF – Ethernet sobre HTTPS
En el presente post quiero hablar mayormente sobre un documento con poco tiempo en IETF llamado “Ethernet sobre HTTPS”. Debo confesar que su...
-
Debido al crecimiento moderado que ha tenido el presente blog se me ocurrió añadir/integrar las estadisticas de google analytics a mi blog. ...
-
Introduccion: En algunas ocasiones es necesario "bajar" o deshabilitar iptables en nuestro Linux, el procedimiento depende de...
-
Saludos, Lo primero que debemos de hacer para quitar el stacking entre los switches es desconectar los cables Stack que los unen.... Es buen...