DevOps, Virtualizacion, Linux, Seguridad y un poco mas..
De camino a que todo este Dual-Stack (DS) en la red local y asignado una dirección IPv6 a vCenter (Appliance), todo tal como se esperaba excepto por la parte de configuración para el servidor DNS. Explícitamente no indica si es IPv4 o IPv6 pero por lo que pude ver solo acepta direcciones v4, el error es bastante genérico.
Aquí se puede ver una captura de toda la configuración:
Desde hace tiempo quería crear una entrada con este tipo de información. recuerdo mi primer encuentro con IPv6 (2004? Recuerdo tener un tunnel y conectar a freenode IRC!!) quede fascinado con la idea del punto-a-punto entre clientes y servidores (clientes a clientes!). Últimamente me he querido enfocar en la parte de redes de VMware, esto quiere decir que mi enfoque será NSX y la micro-segmentación.
Seria genial que NSX soportara IPv6 que tanto me gusta y que he estado desplegando en mi red local de maneras que no tienen sentido en la red del hogar de una persona. Virtualización + Redes es la combinación por la cual estoy apostando últimamente y esto quiere decir que estaré trabajando en recertificar VCP subiéndolo a versión 6 y prepararme para VCP6-NV.
Siguiendo en el tema, aquí les dejo una tabla del soporte actual de IPv6 en NSX y la cual estaré usando para validar su nivel de funcionalidad.
Detailed NSX IPv6 Support
| Component | Feature | Support1 | Notes |
| VM Addressing | |||
| Guest VM Addressing | IPv4, IPv6, DS | VXLAN encap packets are capable of carrying IPv6 payload. VMs can have only IPv6 static addresses. SLAAC (RA) and DHCPv6 (relay and server) are not supported | |
| VXLAN Transport | IPv4 | ||
| NSX Manager | |||
| NSX Manager IP | IPv4, IPv6, DS | ||
| NSX Controller | |||
| Management IP | IPv4 | ||
| NSX Edge | |||
| Management IP | IPv4, IPv6 | No DHCPv6 support | |
| Syslog | IPv4, IPv6 | Export to IPv4 and IPv6 Syslog servers | |
| Interface IP | IPv4, IPv6, DS | No DHCPv6 support | |
| DNS | IPv4 | ||
| DHCP | IPv4 | ||
| Static Routing | IPv4, IPv6 | ||
| Dynamic Routing | IPv4 | No OSPFv3 or MP-BGP support | |
| Firewall | IPv4, IPv6 | ||
| Load Balancer | IPv4, IPv6 | Transparent Mode IPv4 VIP w/ IPv4 Pool (L4 & L7) IPv6 VIP w/ IPv6 Pool (L4 & L7) SNAT Mode |
|
| NAT | IPv4 | NAT64, NAT 46 and NAT66 are not supported | |
| IPSEC | IPv4, IPv6 | No IPv4 Peers with IPv6 internal subnet support | |
| SSL VPN | IPv4, IPv6 | IPv4 and IPv6 can be used for outer packet (tunnel level) but IPv4 only for inner packet | |
| L2VPN | IPv4, IPv6 | IPv4 and IPv6 can be used for outer packet (tunnel level) but IPv4 only for inner packet | |
| NSX DLR | |||
| Management IP | IPv4 | ||
| Interface IP | IPv4 | ||
| Distributed Routing | IPv4 | ||
| NSX DFW | |||
| Distributed Firewall | IPv4, IPv6 | ||
| Virtual Distributed Switch | |||
| SNMP | IPv4, IPv6, DS | ||
| LRO | IPv4, IPv6 | ||
| RSS | IPv4, IPv6 | ||
| DV Filters | IPv4, IPv6 | ||
| TSO | IPv4, IPv6 | ||
| SPAN | IPv4, IPv6 | ||
| RSPAN | IPv4, IPv6 | ||
| CDP & LLDP | IPv4, IPv6 | ||
| Statistics | IPv4, IPv6 | ||
| LACP | IPv4, IPv6 | ||
| IPFIX | IPv4, IPv6 | ||
| Traffic Filters | IPv4, IPv6 | No IPv6 Netflow collector can be configured | |
Esta información fue copiada de: https://www.vmbaggum.nl/2017/01/nsx-ipv6-support/
La información en la tabla proviene de la documentación oficial de NSX 6.2, la idea es actualizar la tabla usando NSX 6.3 y crear una nueva con los componentes que recibieron cambios.
Un artículo interesante que encontré mientras investigaba el soporte de IPv6 en NSX fue el uso de NSX Edge para transportar un /57 de direcciones IPv6 a una red local, comparando con la configuración actual que tengo en casa es el mismo resultado pero con implementación de software diferentes, si solo tuviera equipos en un datacenter donde pudiera correr NSX!!
https://www.vmguru.com/2016/12/using-nsx-for-ipv6-home/
El día de hoy desplegué el NSX Manager y asignado tanto dirección IPv4 como IPv6 en las opciones del OVF Template.
Más adelante posteare las actualizaciones relacionadas a las configuraciones realizadas que tengan IPv6.
Cuanto tiempo! Algunos me han preguntado que si ya no planeaba escribir más en el blog (no muchos, pero si me han preguntado.).
Por cuestiones de trabajo, poco a poco fui descuidando el blog a un punto que ahora veo que se han perdido imágenes de algunas entradas, eso me pasa por usar Dropbox como proveedor de contenidos. Eso es algo que puedo arreglar más adelante, ahora al tema de la entrada.
A mediados de 2016 pude notar que viarios participantes de dn42 estaban usando ASN públicos asignados por ARIN, que chulo no? así que comencé a investigar y termine adquiriendo un Numero Autónomo público. Para que se preguntaran algunos, la respuesta es que desde hace mucho tiempo tengo una adicción al routing a un nivel que en mi pequeña red de la casa estoy corriendo BGP + OSPF para distribuir las rutas internamente.
Después de varios meses de jugar con el ASN y cambiar todos los Debian + Quagga que tenían ASN privado (64635 – 64714) al nuevo y reluciente ASN público (207036), comenzar a anunciar asignaciones de IPv6 (ya casi todo esta dual-stack, yija!!!!), termine con una asignación /22 de IPv4.
Entonces, como esta aaNetworks al día de hoy con relación a networking?
Se puede conseguir más información en BGP.he.net
pfSense es el firewall OpenSource favorito para mí, desde mucho tiempo lo he usado dentro de mi red casera y de tal manera lo he usado en lugares donde he trabajado.
Una de las ventajas de este firewall son sus plugins que nos ayudan a adicionar funcionalidades, pfBlockerNG es uno de ellos y este nos trae funcionalidades de bloqueo de direcciones IP de países y la creación de Alias basados en listas públicas o listas creadas por uno mismo, en mi caso he creado una lista personalizada con todas las direcciones asignadas por LACNIC a República Dominicana.
Para entender cómo funciona pfBlockerNG he usado una guía publicada en Security Artwork (Bloqueando tráfico con pfBlockerNG). Luego utilizando un poco de bash scripting he creado un pequeño script que descarga la lista oficial de LACNIC, la filtra buscando .DO y luego crea un archivo de TXT con el formato necesario para que pfBlockerNG pueda hacer uso de él.
Este alias lo uso para varias configuraciones en mi red local, como por ejemplo no hacer uso de la VPN creada usando PIA y que todo tráfico “local” sea enviado sin encriptar.
Posiblemente para otros esto no tengan ninguna utilidad pero a mí me pareció bien poder tener una excepción y no enviar ese tráfico vía VPN.
KEMP es un proveedor de soluciones para alta disponibilidad y balanceo de carga (LoadMaster), mi primer contacto con el producto fue buscando una solución tipo empresarial para reemplazar Ngnix y/o Apache (mod_proxy). Uno de los primeros escenarios donde leí sobre el despliegue de las soluciones de LoadMaster (LVM100 para ser exacto) fue con vSphere Web Client y Exchange Server.
Cuando fue mi turno de desplegar LoadMaster lo hice usando ESXi como plataforma y en ese momento use dos servidores físicos cada uno con una VM de LoadMaster.
Para ese momento KEMP no tenía una versión gratuita como lo hace ahora y por esta razón no podía jugar con la solución en el homelab, ahora todo cambia, hace varios días KEMP anuncio la versión gratuita que tanto he esperado e inmediatamente un VLM y estoy probando como configurar la plataforma y reemplazar un ZenLoadBalancer que tengo corriendo desde hace un tiempo y es el usado para publicar muchos de los servicios que uso de prueba o uso personal.
La configuración tradicional de un LoadMaster es para tener alta disponibilidad de un aplicativo web, digamos un Lync, Exchange o VMware Horizon View. En mi caso la idea de usar LoadMaster (como lo ha sido con ZenLoadBalancer) es poder publicar todo lo que necesite ya sea HTTP(80) o HTTPS(443) usando una única dirección IP (o varias si es necesario). Me gustaría aclarar que la solución ZenLoadBalancer no me ha fallado y ha cubierto la necesidad que tenía, entonces porque cambiarlo?
La decisión podría decirse que es personal ya que pienso, es más probable que termine administrando un LoadMaster a que me encuentre o que decida instalar ZenLoadBalancer en un ambiente empresarial.
Las funcionalidades, si miramos en http://freeloadbalancer.com. Podemos ver que la versión gratuita nos trae Layer4-7 Load Balancer, Reverse Proxy, Edge Security, WAF (Web Application Firewall) y GSLB (Global Server Load Balanceing), para ser versión gratuita tiene buena pinta, la única funcionalidad que podría hacer falta es HA pero como esto esta apuntado a pequeñas empresas o homelab como es mi caso puede que sea la razón de que no esté disponible HA.
Para más información de las diferencias se puede ver directamente en http://freeloadbalancer.com
La razón de este post es tratar de documentar los pasos y configuraciones que necesite para poder usar LoadMaster como un Reverse Proxy que es actualmente como uso ZenLoadMaster en mi homelab, una diferencia que aplica en mi homelab es que dos de los host ESXi están en un datacenter a unas cuantas miles de millas de mi localidad y me conecto con ellos a través de una VPN tipo mesh (Tinc VPN). Para LoadMaster los Real Servers no están en la misma subred e inicialmente falla al ser agregados en los Virtual Servers si no hacemos los cambios necesarios, esto podría aplicar si los VirtualServers están en 192.168.100.0/24, los RealServers están en 192.168.200.0/24 y el LoadMaster está en modo One-ARM.
Aquí un pequeño diagrama de red donde se ve un VLM en un lado de la red:
Lo primero que debemos hacer es definir algunos Content Rules.
En mi caso quedo algo asi:
Aquí se puede ver mientras modifico una regla llamada guacamole:
Procedemos a agregar un Virtual Server, en mi configuración inicialmente tendré un Virtual Server para el puerto 80 y otro para el puerto 443.
En Advanced Properties habilitamos Content Switching.
Ahora toca crear los SubVS que queramos o necesitemos. Actualmente solo tengo 2 en la parte de HTTP:
Como se puede ver en la imagen anterior, ya estos 2 SubVS tienen Content Rules habilitadas y seleccionadas, si hacemos click en el numero podremos remover o agregar otro Content Rule.
Con relación a los Real Servers, estos serán agregados en cada SubVSs, cuando usamos Content Rule los Real Servers podrían ser el mismo ya que el Content Rule se encargaría de definir el Host Header y re-direccionar el tráfico a donde sea necesario.
Lo importante es tener en cuenta los Content Rule, allí es donde decidiremos cuales dominios serían los aceptados, esto es parecido a los Virtual Name de Apache.
Otra configuración que tuve que aplicar en mi caso fue habilitar fue la de Eable Non-Local Real Servers que se encuentra en System Configuration > Miscellaneous Options > Network Options., además de esto los Virtual Servers no pueden tener habilitado Transparency.
Aquí la documentación oficial -> https://support.kemptechnologies.com/hc/en-us/articles/201849033-How-do-I-add-remote-Real-Servers