{"id":73232,"date":"2020-03-08T08:42:18","date_gmt":"2020-03-08T05:42:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay"},"modified":"2020-03-08T08:42:18","modified_gmt":"2020-03-08T05:42:18","slug":"vxlan-v-nsx-v-trablshutim-underlay","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","title":{"rendered":"VXLAN en NSX-V: solucionando problemas de underlay","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Saludos, y primero un poco de l\u00edrica. A veces envidio a mis colegas que trabajan de forma remota; es maravilloso poder trabajar desde cualquier rinc\u00f3n del mundo conectado a Internet, tener vacaciones en cualquier momento, y ser responsable de proyectos y plazos, en lugar de estar en una oficina de 8 a 17. Mi posici\u00f3n y responsabilidades laborales pr\u00e1cticamente excluyen la posibilidad de estar ausente durante mucho tiempo en el centro de datos. Sin embargo, de vez en cuando surgen casos interesantes, como el descrito a continuaci\u00f3n, y entiendo que hay pocas posiciones donde hay tanto espacio para la expresi\u00f3n creativa del solucionador de problemas interno.
\n<\/a><\/noindex>
\nUn peque\u00f1o descargo de responsabilidad: en el momento de escribir este art\u00edculo, el caso no est\u00e1 completamente resuelto, pero dado el ritmo de respuesta de los proveedores, la soluci\u00f3n completa puede tardar meses, y quiero compartir mis hallazgos ahora. Espero, estimados lectores, que me perdonen por esta premura. Pero suficiente de pre\u00e1mbulos, \u00bfqu\u00e9 pasa con el caso? <\/p>\n

Primero, una introducci\u00f3n: hay una empresa (donde trabajo como ingeniero de redes) que aloja soluciones para clientes en una nube privada de VMWare. La mayor\u00eda de las nuevas soluciones se conectan a segmentos VXLAN, que son gestionados por NSX-V. No voy a evaluar cu\u00e1nto tiempo me ha dado esta soluci\u00f3n, en breve, ha sido mucho. Incluso logr\u00e9 capacitar a mis colegas en la configuraci\u00f3n de NSX ESG y peque\u00f1as soluciones para clientes se despliegan sin mi participaci\u00f3n. Un apunte importante: el plano de control tiene replicaci\u00f3n unicast. Los hipervisores est\u00e1n conectados de manera redundante con dos interfaces a diferentes conmutadores f\u00edsicos Juniper QFX5100 (construidos en un Virtual Chassis) y una pol\u00edtica de temporizaci\u00f3n basada en el puerto virtual de origen, para completar el panorama.<\/p>\n

Las soluciones para clientes son muy diversas: desde Windows IIS, donde todos los componentes del servidor web est\u00e1n instalados en una sola m\u00e1quina, hasta configuraciones bastante grandes, como los frentes web de Apache balanceados por carga + LB MariaDB en Galera + servidores compartidos sincronizados mediante GlusterFS. Pr\u00e1cticamente cada servidor debe ser monitoreado por separado, y no todos los componentes tienen direcciones p\u00fablicas. Si te has encontrado con esta tarea y tienes una soluci\u00f3n m\u00e1s elegante, estar\u00e9 encantado de recibir tus consejos.
\nMi soluci\u00f3n de monitoreo consiste en \u00abconectar\u00bb un firewall (Fortigate) a cada red interna de clientes (+SNAT y, por supuesto, estrictas restricciones sobre el tipo de tr\u00e1fico permitido) y observar las direcciones internas; de esta manera se logra una cierta unificaci\u00f3n y simplificaci\u00f3n del monitoreo. El monitoreo se realiza desde un cl\u00faster de servidores PRTG. El esquema de monitoreo es aproximadamente el siguiente:<\/p>\n

\"VXLAN
\n
\nMientras operamos solo con VLAN, todo funcionaba de manera bastante normal y predecible, como un reloj. Despu\u00e9s de implementar NSX-V y VXLAN, nos encontramos con la pregunta: \u00bfse puede seguir monitoreando de la forma antigua? En el momento de esta pregunta, la soluci\u00f3n \u00abm\u00e1s r\u00e1pida\u00bb fue desplegar NSX ESG y conectar la interfaz trunk VXLAN en la red VTEP. R\u00e1pido entre comillas, ya que usar la GUI para configurar redes de clientes, SNAT y reglas del firewall puede unificar la gesti\u00f3n en una \u00fanica interfaz de vSphere, pero en mi opini\u00f3n es bastante engorroso y, adem\u00e1s, limita el conjunto de herramientas para solucionar problemas. Aquellos que han utilizado NSX ESG como reemplazo de un firewall \u00abreal\u00bb, creo que estar\u00e1n de acuerdo. Aunque, probablemente, tal soluci\u00f3n ser\u00eda m\u00e1s estable, ya que todo ocurre dentro de un \u00fanico vendedor.<\/p>\n

Otra soluci\u00f3n es utilizar NSX DLR en modo puente entre VLAN y VXLAN. Aqu\u00ed creo que todo est\u00e1 claro: se pierde la ventaja de aplicar VXLAN, ya que en este caso a\u00fan es necesario extender VLAN a la instalaci\u00f3n de monitoreo. Por cierto, durante el desarrollo de esta soluci\u00f3n me encontr\u00e9 con un problema cuando el puente DLR no enviaba paquetes a la m\u00e1quina virtual con la que estaba en el mismo host. Lo s\u00e9, lo s\u00e9: en los libros y gu\u00edas sobre NSX-V se dice que NSX Edge debe tener un cl\u00faster separado, pero eso est\u00e1 en los libros... De una forma u otra, despu\u00e9s de un par de meses con soporte, no resolvimos el problema. En esencia, entend\u00ed la l\u00f3gica de funcionamiento: el m\u00f3dulo del n\u00facleo del hipervisor responsable de la encapsulaci\u00f3n de VXLAN no se activ\u00f3 si el DLR y el servidor observado estaban en el mismo host, ya que el tr\u00e1fico no sale del host y, l\u00f3gicamente, deber\u00eda estar conectado al segmento VXLAN: la encapsulaci\u00f3n no es necesaria. Con el soporte nos detuvimos en la interfaz virtual vdrPort, que l\u00f3gicamente combina los uplinks y tambi\u00e9n realiza el puenteo\/encapsulaci\u00f3n: ah\u00ed se observ\u00f3 una discrepancia en el tr\u00e1fico entrante, que tom\u00e9 para trabajar en el caso actual. Pero como se dijo, no termin\u00e9 este caso porque fui transferido a otro proyecto y adem\u00e1s la rama era originalmente un callej\u00f3n sin salida y no hab\u00eda mucho deseo de desarrollarla. Si no me equivoco, el problema se observ\u00f3 en las versiones NSX 6.1.4 y 6.2. <\/p>\n

Y aqu\u00ed, \u00a1bingo! Fortinet anuncia el soporte nativo de VXLAN<\/a><\/noindex>. Y no solo point-to-point o VXLAN-over-IPSec, no es un puente de software VLAN-VXLAN: todo esto comenz\u00f3 a implementarse desde la versi\u00f3n 5.4 (y se presenta en otros vendedores<\/a><\/noindex>), y el apoyo real al plano de control unicast. Al implementar la soluci\u00f3n, me encontr\u00e9 con otro problema: los servidores monitoreados a veces \"desaparec\u00edan\" y aparec\u00edan en la monitorizaci\u00f3n, aunque la m\u00e1quina virtual estaba activa. La raz\u00f3n, como result\u00f3, fue que olvid\u00e9 permitir Ping en la interfaz VXLAN. Durante el proceso de reequilibrio de los cl\u00fasteres, las m\u00e1quinas virtuales se mov\u00edan, y el vMotion se completaba con Ping, para se\u00f1alar el nuevo host ESXI al que se hab\u00eda trasladado la m\u00e1quina. Mi torpeza, pero este problema socav\u00f3 una vez m\u00e1s la confianza en el soporte del fabricante, en este caso Fortinet. No menciono que cada caso relacionado con VXLAN comienza con la pregunta \"\u00bfd\u00f3nde tiene usted configurada la VLAN-VXLAN en el softswitch?\" Esta vez me aconsejaron cambiar el MTU; esto es para Ping, que es de 32 bytes. Luego, \"juega\" con tcp-send-mss y tcp-receive-mss en la pol\u00edtica, para VXLAN, que se encapsula en UDP. Uf, disculpen, se me subieron los \u00e1nimos. En fin, resolv\u00ed este problema por mi cuenta. <\/p>\n

Despu\u00e9s de probar el tr\u00e1fico de prueba, se decidi\u00f3 implementar esta soluci\u00f3n. Y en producci\u00f3n, result\u00f3 que despu\u00e9s de uno o dos d\u00edas, todo lo que estaba monitorizado a trav\u00e9s de VXLAN se desconectaba gradualmente. La desactivaci\u00f3n\/activaci\u00f3n de la interfaz ayudaba, pero solo temporalmente. Recordando la lentitud del soporte del fabricante, me ocup\u00e9 de la soluci\u00f3n de problemas por mi cuenta \u2014 despu\u00e9s de todo, mi empresa, mi red \u2014 mi responsabilidad. <\/p>\n

Bajo el spoiler est\u00e1 el progreso de la soluci\u00f3n de problemas. Quien est\u00e9 cansado de letras y jactancias \u2014 salte y pase al an\u00e1lisis posterior.<\/p>\n

Progreso de la soluci\u00f3n de problemas<\/b>Gracias por continuar leyendo \u2014 \u00a1sigamos!<\/p>\n

As\u00ed que, la supervisi\u00f3n funciona un tiempo, luego se desconecta sola. Esto significa que probablemente no hay problemas en las pol\u00edticas del firewall. Sin embargo, dado que me he encontrado con el problema de procesos del sistema que se quedan colgados en Fortigate versiones 5.6+, primero miramos \u00abdiagnose debug flow\u00bb \u2014 como era de esperar, el tr\u00e1fico se permite y se env\u00eda desde la interfaz y, como era de esperar, no llega nada en respuesta. As\u00ed que seguimos profundizando en la pila. Lamentablemente, tendr\u00e9 que ocultar las direcciones, aunque sean RFC1918, pero espero proporcionar suficiente descripci\u00f3n del proceso para la comprensi\u00f3n. El servidor dentro de VXLAN tiene la direcci\u00f3n x.x.x.15, la interfaz de Fortigate x.x.x.254, todas las dem\u00e1s direcciones pertenecen a la red VTEP.<\/p>\n

Para la transmisi\u00f3n exitosa de paquetes encapsulados en VXLAN, es necesario contar con informaci\u00f3n correcta en varias tablas. Para el overlay, esto implica ARP y OVSDB; para el underlay, ARP y CAM. En el caso de Fortigate, VXLAN FDB es OVSDB. Empezaremos por ah\u00ed:<\/p>\n

 fortigate (root) #diag sys vxlan fdb list vxlan-LS\nmac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=\u00fa.\u00fa.\u00fa.47 port=4789 vni=5008 ifindex=7\n<\/code><\/pre>\n
\nAqu\u00ed todo es bastante simple: la direcci\u00f3n MAC de la m\u00e1quina virtual debe estar en el VTEP con la direcci\u00f3n \u00fa.\u00fa.\u00fa.47. Al revisar el contenido y la configuraci\u00f3n del cl\u00faster ESXI, encuentro que la MAC de la m\u00e1quina virtual es correcta, y tambi\u00e9n lo es la direcci\u00f3n del VTEP. Verifico la tabla CAM\/ARP en el Fortigate, y de nuevo todo coincide con la configuraci\u00f3n del host ESXI:<\/p>\n
fortigate (root) #get sys arp | grep \u00fa.\u00fa.\u00fa.47\n\u00fa.\u00fa.\u00fa.47 0 00:50:56:65:f6:2c dmz\n<\/code><\/pre>\n
\nLas tablas son correctas y el tr\u00e1fico se va; \u00bfpuede que el problema no est\u00e9 en el FortiGate? Intencionalmente pas\u00e9 por alto el an\u00e1lisis de conmutaci\u00f3n de tr\u00e1fico en Juniper; l\u00f3gicamente, este deber\u00eda ser el siguiente paso en la soluci\u00f3n de problemas, pero mi red es simple: solo tengo un VLAN para VTEP y todos los componentes est\u00e1n conectados directamente. Adem\u00e1s, recuerdo un caso con el puente DLR, VDR y el tr\u00e1fico que desaparece; voy a realizar un sniffing en el host ESXI, mientras creo un caso ya a VMWare. A continuaci\u00f3n, el MAC \"97:6e\" pertenece al Forti, vmnic1 es la interfaz que tiene VTEP con la direcci\u00f3n u.u.u.47, sniffeo en ambas direcciones \"\u2014dir 2\":<\/p>\n
pktcap-uw --uplink vmnic1 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o \/tmp\/monitor.pcap\n<\/code><\/pre>\n
\n\"VXLAN
\n
\nProgreso: en el sniff veo una solicitud ARP y la respuesta que llega. Solo presento la respuesta ARP y ah\u00ed todo es correcto. No mencion\u00e9 que durante todo este tiempo el servidor de monitoreo est\u00e1 haciendo ping a la direcci\u00f3n x.x.x.15 \u2014 \u00bfd\u00f3nde est\u00e1 el tr\u00e1fico ICMP? Recuerdo que tengo dos uplinks. Aqu\u00ed se puede debatir y decir que el puerto virtual de origen es el mismo (mi pol\u00edtica de teaming), es decir, para un mismo vNIC se debe seleccionar el mismo uplink, pero ya que estoy en el host, verificar el otro uplink no es un problema:<\/p>\n
pktcap-uw --uplink vmnic4 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o \/tmp\/monitor.pcap\n<\/code><\/pre>\n
\n\"VXLAN
\n
\nRecibo solicitudes del Fortigate, pero no hay respuesta. Es decir, el problema no est\u00e1 en el Fortigate. Bueno, eso creo, otra vez el mismo problema de la p\u00e9rdida de tr\u00e1fico en el VDR, de nuevo unos meses dirigiendo el caso en la direcci\u00f3n correcta. Despu\u00e9s de un par de d\u00edas, calm\u00e1ndome y sin querer aceptar el estancamiento, decid\u00ed recopilar m\u00e1s sniffs para el soporte y as\u00ed acelerar el proceso. Y aqu\u00ed, 'accidentalmente', mi mirada cae en la encapsulaci\u00f3n de Ethernet underlay. El rey no es real y la direcci\u00f3n MAC del VTEP no coincide con su IP. Restablezco a cero, hago sniffs, investigo\u2014resulta que no es correcto. Colocar\u00e9 la tabla ARP al lado para que sea m\u00e1s f\u00e1cil comparar. Preste atenci\u00f3n a la primera encapsulaci\u00f3n de Ethernet en la imagen de arriba:<\/p>\n
fortigate (root) #get sys arp | grep x.x.x.47\nx.x.x.47 0 00:50:56:65:f6:2c dmz\nfortigate (root) #get sys arp | grep x.x.x.42\nx.x.x.42 0 00:50:56:6a:78:86 dmz\n<\/code><\/pre>\n
\nEntonces, \u00bfqu\u00e9 tenemos en total? \u2014 Despu\u00e9s de la migraci\u00f3n de la m\u00e1quina virtual, el Fortigate intenta enviar tr\u00e1fico al VTEP desde (correcta) VXLAN FDB, pero usa una MAC DST incorrecta y el tr\u00e1fico se descarta, como era de esperar, por el interfaz receptor del hipervisor. De hecho, en uno de cada cuatro casos esta MAC pertenec\u00eda al hipervisor original desde el que comenzamos la migraci\u00f3n de la m\u00e1quina.<\/p>\n
Ayer recib\u00ed un correo del soporte t\u00e9cnico de Fortinet \u2014 han abierto un bug 615586 para mi caso. No s\u00e9 si sentirme feliz o triste: por un lado, el problema no est\u00e1 en la configuraci\u00f3n, por el otro, la soluci\u00f3n llegar\u00e1 solo con la actualizaci\u00f3n del firmware, en el mejor de los casos, en la pr\u00f3xima. Mi ego tambi\u00e9n se alimenta de otro bug que descubr\u00ed el mes pasado, aunque esta vez en el GUI HTML5 de vSphere. Es como tener un departamento local de QA en los proveedores...<\/p>\n
Me arriesgo a suponer lo siguiente:<\/p>\n
1 \u2014 es probable que el plano de control multicast no est\u00e9 sujeto al problema descrito \u2014 ya que las direcciones MAC del VTEP se obtienen de la direcci\u00f3n IP del grupo al que est\u00e1 suscrito el interfaz. <\/p>\n
2 \u2014 probablemente el problema de Fortigate est\u00e9 en la descarga de sesiones en el Procesador de Red (aproximadamente an\u00e1logo al CEF) \u2014 si cada paquete pasa por la CPU, se utilizar\u00e1n las tablas que contienen la informaci\u00f3n correcta, al menos visualmente. A favor de esta suposici\u00f3n est\u00e1 el hecho de que ayuda cerrar\/abrir el interfaz o esperar un tiempo \u2014 m\u00e1s de 5 minutos. <\/p>\n
3 \u2014 cambiar la pol\u00edtica de equipo, por ejemplo, a failover expl\u00edcito, o implementar LAG no resolver\u00e1 el problema, ya que se observ\u00f3 un 'atasco' de la MAC del hipervisor original en los paquetes encapsulados.<\/p>\n
A la luz de esto, puedo compartir que recientemente descubr\u00ed blog<\/a><\/noindex>, donde en uno de los art\u00edculos se afirmaba que los firewalls stateful y los m\u00e9todos de transmisi\u00f3n de datos en cach\u00e9 son parches. Bueno, no tengo suficiente experiencia en TI para afirmar lo contrario, adem\u00e1s no estoy de acuerdo de inmediato con todas las afirmaciones de los art\u00edculos del blog. Sin embargo, algo me dice que hay algo de verdad en las palabras de Iv\u00e1n.<\/p>\n
\u00a1Gracias por su atenci\u00f3n! Estar\u00e9 encantado de responder a preguntas y escuchar cr\u00edticas constructivas.
\n
Fuente: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0440\u0438\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e, \u0438 \u0441\u043f\u0435\u0440\u0432\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043b\u0438\u0440\u0438\u043a\u0438. \u042f \u0438\u043d\u043e\u0433\u0434\u0430 \u0437\u0430\u0432\u0438\u0434\u0443\u044e \u043a\u043e\u043b\u043b\u0435\u0433\u0430\u043c, \u0440\u0430\u0431\u043e\u0442\u0430\u044e\u0449\u0438\u043c \u0443\u0434\u0430\u043b\u0451\u043d\u043d\u043e \u2014 \u0432\u0435\u0434\u044c \u044d\u0442\u043e \u043f\u0440\u0435\u043a\u0440\u0430\u0441\u043d\u043e \u0438\u043c\u0435\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0438\u0437 \u043b\u044e\u0431\u043e\u0433\u043e \u043a\u043e\u043d\u0446\u0430 \u043f\u043e\u0434\u043a\u043b\u044e\u0447\u0451\u043d\u043d\u043e\u0433\u043e \u043a Internet \u043c\u0438\u0440\u0430, \u043a\u0430\u043d\u0438\u043a\u0443\u043b\u044b \u0432 \u043b\u044e\u0431\u043e\u0435 \u0432\u0440\u0435\u043c\u044f, \u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0441\u0442\u044c \u0437\u0430 \u043f\u0440\u043e\u0435\u043a\u0442\u044b \u0438 \u0434\u0435\u0434\u043b\u0430\u0439\u043d\u044b, \u0430 \u043d\u0435 \u043d\u0430\u0445\u043e\u0436\u0434\u0435\u043d\u0438\u0435 \u0432 \u043e\u0444\u0438\u0441\u0435 \u0441 8 \u0434\u043e 17. \u041c\u043e\u044f \u043f\u043e\u0437\u0438\u0446\u0438\u044f \u0438 \u0440\u0430\u0431\u043e\u0447\u0438\u0435 \u043e\u0431\u044f\u0437\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438 \u0438\u0441\u043a\u043b\u044e\u0447\u0430\u044e\u0442 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0434\u043e\u043b\u0433\u043e\u0433\u043e \u043e\u0442\u0441\u0443\u0442\u0441\u0442\u0432\u0438\u044f \u0432 \u0434\u0430\u0442\u0430\u0446\u0435\u043d\u0442\u0440\u0435. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":73233,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-73232","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47VXLAN en NSX-V \u2014 resolviendo problemas de underlay | ProHoster","description":"Saludos, y primero un poco de l\u00edrica.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47VXLAN \u0432 NSX-V \u2014 \u0442\u0440\u0430\u0431\u043b\u0448\u0443\u0442\u0438\u043c underlay | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e, \u0438 \u0441\u043f\u0435\u0440\u0432\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043b\u0438\u0440\u0438\u043a\u0438.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-08T05:42:18+00:00","article:modified_time":"2020-03-08T05:42:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"73232","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:36:23","updated":"2022-09-27 15:26:08","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/73232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=73232"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/73232\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/73233"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=73232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=73232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=73232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}