{"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\/it\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","title":{"rendered":"VXLAN in NSX-V \u2014 risolviamo i problemi dell'underlay","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, innanzitutto un po' di lirica. A volte invidio i miei colleghi che lavorano da remoto: \u00e8 fantastico poter lavorare da qualsiasi parte del mondo connesso a Internet, avere vacanze in qualsiasi momento, responsabilit\u00e0 sui progetti e sulle scadenze, senza dover stare in ufficio dalle 8 alle 17. La mia posizione e le mie responsabilit\u00e0 lavorative escludono praticamente la possibilit\u00e0 di un'assenza prolungata nel data center. Tuttavia, periodicamente si verificano casi interessanti, simili a quello descritto qui di seguito, e capisco che ci sono poche posizioni dove c'\u00e8 cos\u00ec tanto spazio per l'espressione creativa di un troubleshooter interno.
\n<\/a><\/noindex>
\nUn piccolo disclaimer: al momento della scrittura dell'articolo, il caso non \u00e8 ancora completamente risolto, ma considerando la rapidit\u00e0 di risposta dei fornitori, la soluzione completa potrebbe richiedere ancora mesi e voglio condividere le mie scoperte gi\u00e0 ora. Spero, cari lettori, che mi perdoniate questa fretta. Ma basta con le chiacchiere: com'\u00e8 la situazione con il caso? <\/p>\n

Prima di tutto, un'introduzione: c'\u00e8 un'azienda (dove lavoro come ingegnere di rete) che ospita soluzioni client nel cloud privato VMWare. La maggior parte delle nuove soluzioni si connette a segmenti VXLAN gestiti da NSX-V: non valuter\u00f2 quanto tempo mi ha regalato questa soluzione, per dirla brevemente, tanto. Sono riuscito persino a formare i colleghi sulla configurazione di NSX ESG e piccole soluzioni client vengono implementate senza il mio intervento. Importante notare: il control plane \u00e8 con replica unicast. Gli hypervisor sono collegati in modo ridondante con due interfacce a diversi switch fisici Juniper QFX5100 (racchiusi in Virtual Chassis) e con la politica di timing route based on originating virtual port: questo per completezza.<\/p>\n

Le soluzioni client sono molto eterogenee: da Windows IIS, dove tutti i componenti del server web sono installati su una sola macchina, a soluzioni piuttosto grandi \u2014 ad esempio, front-end Apache bilanciati con load balancing + LB MariaDB in Galera + server condivisi, sincronizzati tramite GlusterFS. Praticamente ogni server deve essere monitorato separatamente, e non tutti i componenti hanno indirizzi pubblici: se ti sei trovato di fronte a questa sfida e hai una soluzione pi\u00f9 elegante, sarei felice di ricevere consigli.
\nLa mia soluzione di monitoraggio consiste nel \u00abcollegare\u00bb il firewall (Fortigate) a ogni rete clienti interna (+SNAT e, naturalmente, severe restrizioni sul tipo di traffico consentito) e monitorare gli indirizzi interni: in questo modo si raggiunge una certa unificazione e semplificazione del monitoraggio. Il monitoraggio avviene da un cluster di server PRTG. Lo schema di monitoraggio \u00e8 all'incirca il seguente:<\/p>\n

\"VXLAN
\n
\nFinch\u00e9 abbiamo operato solo con VLAN, tutto era piuttosto normale e funzionava come un orologio. Dopo l'implementazione di NSX-V e VXLAN, ci siamo trovati di fronte alla questione: \u00e8 ancora possibile continuare a monitorare come prima? Al momento di questa domanda, la soluzione pi\u00f9 \u00abrapida\u00bb era distribuire NSX ESG e collegare l'interfaccia trunk VXLAN nella rete VTEP. Rapida tra virgolette: poich\u00e9 utilizzare la GUI per configurare le reti clienti, SNAT e le regole del firewall pu\u00f2 anche unificare la gestione in un'unica interfaccia vSphere, ma secondo me \u00e8 piuttosto ingombrante e, tra l'altro, limita l'insieme di strumenti per il troubleshooting. Chi ha utilizzato NSX ESG come sostituto di un \u00abvero\u00bb firewall, credo convenir\u00e0. Tuttavia, probabilmente, una tale soluzione sarebbe stata pi\u00f9 stabile: poich\u00e9 tutto avviene nell'ambito di un unico fornitore.<\/p>\n

Un'altra soluzione \u00e8 utilizzare NSX DLR in modalit\u00e0 bridge tra VLAN e VXLAN. Qui penso sia tutto chiaro: si perde banalmente il vantaggio dell'applicazione di VXLAN, poich\u00e9 in questo caso si deve comunque estendere la VLAN all'installazione di monitoraggio. A proposito, durante l'elaborazione di questa soluzione, ho incontrato un problema quando il bridge DLR non inviava pacchetti alla macchina virtuale con cui era sullo stesso host. Lo so, lo so: nei libri e nelle guide su NSX-V si afferma esplicitamente che per NSX Edge deve essere dedicato un cluster separato, ma questo \u00e8 nei libri... In ogni caso, dopo un paio di mesi con il supporto non siamo riusciti a risolvere il problema. Fondamentalmente ho capito la logica in atto: il modulo del kernel dell'hypervisor, responsabile per l'incapsulamento di VXLAN, non veniva utilizzato se DLR e il server monitorato si trovavano sullo stesso host, poich\u00e9 il traffico non lascia l'host e logicamente dovrebbe essere connesso al segmento VXLAN: l'incapsulamento non \u00e8 necessario. Con il supporto ci siamo concentrati sull'interfaccia virtuale vdrPort, che unisce logicamente gli uplink e svolge anche il bridging\/incapsulamento: l\u00ec \u00e8 stata notata una discrepanza nel traffico in entrata, che ho preso in carico per l'elaborazione nel caso attuale. Ma come \u00e8 stato detto, non ho portato a termine questo caso, poich\u00e9 sono stato trasferito su un altro progetto e la branca inizialmente era senza uscita, quindi non avevo molta voglia di svilupparla. Se non erro, il problema si \u00e8 verificato nelle versioni NSX 6.1.4 e 6.2. <\/p>\n

E qui - bingo! Fortinet annuncia il supporto nativo di VXLAN<\/a><\/noindex>. E non solo point-to-point o VXLAN-over-IPSec, n\u00e9 bridging software VLAN-VXLAN: tutto questo \u00e8 stato iniziato a essere implementato gi\u00e0 dalla versione 5.4 (ed \u00e8 presentato anche da altri vendor<\/a><\/noindex>), e il supporto reale del piano di controllo unicast. Durante l'implementazione della soluzione, ho riscontrato un'altra problematica: i server monitorati a volte \u00abscomparivano\u00bb e poi riapparivano nel monitoraggio, anche se la macchina virtuale era attiva. La causa, si \u00e8 rivelato, era che avevo dimenticato di abilitare il Ping sull'interfaccia VXLAN. Durante il processo di bilanciamento dei cluster, le macchine virtuali si spostavano, e il vMotion veniva completato tramite Ping per indicare il nuovo host ESXI su cui era stata trasferita la macchina. Una mia sciocchezza, ma questo problema ha ulteriormente minato la fiducia nel supporto del produttore \u2014 in questo caso Fortinet. Non parlo nemmeno del fatto che ogni caso legato a VXLAN inizia con la domanda \u00abdove avete nelle impostazioni il software switch VLAN-VXLAN?\u00bb Questa volta mi hanno consigliato di modificare il MTU \u2014 \u00e8 per il Ping, che \u00e8 di 32 byte. Poi \u00abgiocati\u00bb con tcp-send-mss e tcp-receive-mss nelle politiche \u2014 per il VXLAN, che \u00e8 incapsulato in UDP. Uff, scusate \u2014 sono stato sopraffatto. In generale, ho risolto questa problematica da solo. <\/p>\n

Dopo aver testato con successo il traffico, \u00e8 stato deciso di implementare questa soluzione. E in produzione si \u00e8 scoperto che dopo un giorno o due tutto ci\u00f2 che veniva monitorato tramite VXLAN smetteva gradualmente di funzionare. La disattivazione\/riattivazione dell'interfaccia aiutava, ma solo per un breve periodo. Ricordando la lentezza del supporto del produttore, ho iniziato a fare troubleshooting da parte mia \u2014 in fin dei conti, la mia azienda, la mia rete \u2014 la mia responsabilit\u00e0. <\/p>\n

Sotto spoiler il corso del troubleshooting. Chi \u00e8 stanco di lettere e vanterie \u2014 salti e passi all'analisi finale.<\/p>\n

Corso del troubleshooting<\/b>Grazie per aver continuato a leggere \u2014 procediamo!<\/p>\n

Quindi, il monitoraggio funziona per un certo periodo, poi smette di funzionare da solo. Questo significa che nelle politiche del firewall probabilmente non ci sono problemi. Tuttavia, poich\u00e9 ho gi\u00e0 affrontato problemi con processi di sistema bloccati in Fortigate versioni 5.6+, iniziamo con \u00abdiagnose debug flow\u00bb \u2014 come previsto il traffico viene autorizzato e parte dall'interfaccia e, come previsto, non arriva nulla in risposta. Quindi continuiamo ad esaminare il stack. Sfortunatamente, dovr\u00f2 nascondere gli indirizzi, anche se RFC1918, ma spero di fornire al processo una descrizione sufficiente per comprenderlo. Il server all'interno del VXLAN ha l'indirizzo x.x.x.15, l'interfaccia di Fortigate x.x.x.254, tutti gli altri indirizzi appartengono alla rete VTEP.<\/p>\n

Per una corretta trasmissione dei pacchetti incapsulati in VXLAN, \u00e8 necessaria la presenza di informazioni corrette in diverse tabelle. Per l'overlay sono ARP e OVSDB, per l'underlay sono ARP e CAM. Nel caso di Fortigate, VXLAN FDB \u00e8 OVSDB. Cominciamo da l\u00ec:<\/p>\n

 fortigate (root) #diag sys vxlan fdb list vxlan-LS\nmac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=u.u.u.47 port=4789 vni=5008 ifindex=7\n<\/code><\/pre>\n
\nQui tutto \u00e8 abbastanza semplice: l'indirizzo MAC della macchina virtuale deve trovarsi sul VTEP con indirizzo u.u.u.47. Controllando il contenuto e le impostazioni del cluster ESXI, scopro che l'indirizzo MAC della macchina virtuale \u00e8 corretto e anche l'indirizzo del VTEP. Controllo la tabella CAM\/ARP sul fortigate: anche qui tutto corrisponde alle impostazioni dell'host ESXI:<\/p>\n
fortigate (root) #get sys arp | grep u.u.u.47\nu.u.u.47 0 00:50:56:65:f6:2c dmz\n<\/code><\/pre>\n
\nLe tabelle sono corrette e il traffico viene inviato: forse il problema non \u00e8 sul fortigate? Ho deliberatamente saltato l'analisi del traffico di switching su Juniper \u2014 logicamente il passo successivo della risoluzione dei problemi dovrebbe avvenire l\u00ec, ma la mia rete \u00e8 semplice \u2014 solo un VLAN per VTEP e tutti i componenti sono collegati direttamente. Inoltre, ricordo un caso con un bridge DLR, VDR e traffico mancante: vado a sniffare sulla host ESXI, mentre creo un caso gi\u00e0 per VMWare. Qui sotto, l'indirizzo MAC \u00ab97:6e\u00bb appartiene al fortigate, vmnic1 \u2014 \u00e8 l'interfaccia che ha il VTEP con indirizzo u.u.u.47, sniffiamo in entrambe le direzioni \"--dir 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
\nProgresso: nello sniffing vedo la richiesta ARP e la risposta in arrivo. Riporto solo la risposta ARP e l\u00ec tutto \u00e8 corretto. Non ho menzionato che per tutto questo tempo il server di monitoraggio sta pingando l'indirizzo x.x.x.15: dove \u00e8 finito il traffico ICMP? Ricordo che ho due uplink. Qui si potrebbe discutere e dire che la porta virtuale di origine \u00e8 la stessa (la mia policy di teaming), cio\u00e8 per la stessa vNIC deve essere selezionato lo stesso uplink, ma visto che sono sull'host, controllare un altro uplink non \u00e8 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
\nRiceviamo richieste dal fortigate, ma non ci sono risposte. Quindi il problema non \u00e8 nel fortigate. Beh, penso, \u00e8 di nuovo lo stesso problema del traffico che scompare su VDR, di nuovo un paio di mesi per orientare il caso nel modo giusto. Dopo un paio di giorni, raffreddandomi e non volendo accettare la situazione, ho deciso di raccogliere ancora pi\u00f9 sniffer per il supporto, per accelerare il processo. E qui il mio sguardo \"casualmente\" cade sull'incapsulamento Ethernet underlay. Il re non \u00e8 reale e l'indirizzo MAC del VTEP non corrisponde al suo IP. Ripristino a zero, sniffo, scavo - \u00e8 vero che non \u00e8 vero. Riporter\u00f2 la tabella ARP accanto per facilitare il confronto. Fate attenzione al primo incapsulamento Ethernet nell'immagine sopra:<\/p>\n
fortigate (root) #get sys arp | grep u.u.u.47\nu.u.u.47 0 00:50:56:65:f6:2c dmz\nfortigate (root) #get sys arp | grep u.u.u.42\nu.u.u.42 0 00:50:56:6a:78:86 dmz\n<\/code><\/pre>\n
\nQuindi, cosa abbiamo alla fine - dopo la migrazione della macchina virtuale, il fortigate cerca di inviare traffico al VTEP dalla (corretta) VXLAN FDB, ma utilizza un DST MAC errato e il traffico viene naturalmente scartato dall'interfaccia ricevente del hypervisor. In un caso su quattro, questo MAC apparteneva all'originario hypervisor da cui \u00e8 iniziata la migrazione della macchina.<\/p>\n
Ieri ho ricevuto una mail dal supporto Fortinet - hanno aperto il bug 615586 per il mio caso. Non so se essere felice o triste: da un lato, il problema non \u00e8 nelle impostazioni, dall'altro, la realt\u00e0 \u00e8 che la correzione arriver\u00e0 solo con l'aggiornamento del firmware, al meglio nel prossimo. La mia autostima \u00e8 alimentata anche da un altro bug, che ho scoperto il mese scorso, anche se in quel caso nell'HTML5 GUI di vSphere. Insomma, sembra un dipartimento QA locale dei fornitori...<\/p>\n
Oserei fare la seguente ipotesi:<\/p>\n
1 - \u00e8 probabile che il piano di controllo multicast non sar\u00e0 soggetto al problema descritto - poich\u00e9 gli indirizzi MAC del VTEP vengono derivati dall'indirizzo IP del gruppo a cui \u00e8 iscritto l'interfaccia. <\/p>\n
2 - il problema del fortigate potrebbe risiedere nel caricamento delle sessioni sul Network Processor (approssimativamente analogo al CEF) - se si fa passare ogni pacchetto attraverso la CPU, verranno utilizzate tabelle contenenti informazioni corrette - almeno visivamente. A supporto di questa ipotesi, va detto che \u00e8 utile chiudere\/aprire l'interfaccia o aspettare un certo tempo - pi\u00f9 di 5 minuti. <\/p>\n
3 - modificare la policy di teaming, ad esempio su failover esplicito, o implementare LAG non risolver\u00e0 il problema, poich\u00e9 si \u00e8 riscontrato un \"blocco\" del MAC dell'originario hypervisor nei pacchetti incapsulati.<\/p>\n
In considerazione di ci\u00f2, posso condividere che di recente ho scoperto blog<\/a><\/noindex>, dove in uno degli articoli si affermava che i firewall stateful e i metodi di trasferimento dati memorizzabili sono dei palliativi. Beh, non sono cos\u00ec esperto in IT da poter affermare una cosa del genere, inoltre non concordo subito con tutte le affermazioni degli articoli del blog. Tuttavia, qualcosa mi dice che c'\u00e8 un fondo di verit\u00e0 nelle parole di Ivan.<\/p>\n
Grazie per l'attenzione! Sar\u00f2 felice di rispondere alle domande e di ascoltare critiche costruttive.
\n
Fonte: 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 in NSX-V \u2014 risolviamo i problemi di underlay | ProHoster","description":"Salve, e per prima cosa un po' di poesia.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/73232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=73232"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/73232\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/73233"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=73232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=73232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=73232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}