{"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\/da\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","title":{"rendered":"VXLAN i NSX-V - fejlfinding af underlay","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej, og f\u00f8rst lidt lyrik. Nogle gange misundrer jeg mine kolleger, der arbejder hjemmefra - det er fantastisk at have mulighed for at arbejde fra enhver del af den internetforbundne verden, ferie n\u00e5r som helst, ansvar for projekter og deadlines, i stedet for at sidde p\u00e5 kontoret fra 8 til 17. Min stilling og arbejdsopgaver udelukker praktisk talt muligheden for at v\u00e6re v\u00e6k fra datacenteret i l\u00e6ngere perioder. Men - der opst\u00e5r indimellem interessante tilf\u00e6lde som det, jeg beskriver nedenfor - og jeg forst\u00e5r, at der findes f\u00e5 stillinger, hvor der er s\u00e5 meget plads til det kreative udtryk fra en indre troubleshooter.
\n<\/a><\/noindex>
\nEn lille disclaimer - p\u00e5 tidspunktet for denne artikel er sagen ikke helt l\u00f8st, men i betragtning af hastigheden p\u00e5 leverand\u00f8rernes svar kan en fuld l\u00f8sning tage flere m\u00e5neder, og jeg vil gerne dele mine fund nu. Jeg h\u00e5ber, k\u00e6re l\u00e6sere, I tilgiver mig denne hast. <\/p>\n

F\u00f8rst en introduktion: Der er et firma (hvor jeg arbejder som netv\u00e6rksingeni\u00f8r), der hoster kundel\u00f8sninger i den private VMWare-cloud. De fleste nye l\u00f8sninger tilsluttes VXLAN-segmenter, der administreres af NSX-V - jeg vil ikke vurdere, hvor meget tid dette har givet mig, men kort sagt - meget. Jeg har endda form\u00e5et at uddanne kolleger i ops\u00e6tning af NSX ESG, og sm\u00e5 kundel\u00f8sninger implementeres uden min deltagelse. Vigtig bem\u00e6rkning - kontrolplanet har vi med unicast-replikation. Hypervisorerne er forbundet redundat med to interfaces til forskellige fysiske Juniper QFX5100-switches (samlet i Virtual Chassis) og politik for timingen baseret p\u00e5 den oprindelige virtuelle port - dette er for at give et klart billede.<\/p>\n

Kundel\u00f8sningerne er meget forskellige: fra Windows IIS, hvor alle komponenter i webserveren er installeret p\u00e5 \u00e9n maskine, til ret store - for eksempel load-balanced Apache web-frontend + LB MariaDB i Galera + delte servere synkroniseret med GlusterFS. Praktisk taget hver server skal overv\u00e5ges separat, og ikke alle komponenter har offentlige adresser - hvis du har st\u00f8dt p\u00e5 denne udfordring og har en mere elegant l\u00f8sning, ville jeg v\u00e6re glad for et r\u00e5d.
\nMin l\u00f8sning til overv\u00e5gning best\u00e5r i at \"tilslutte\" firewallen (Fortigate) til hvert internt kundenetv\u00e6rk (+SNAT og selvf\u00f8lgelig strenge begr\u00e6nsninger p\u00e5 typen af tilladt trafik) og overv\u00e5ge de interne adresser - p\u00e5 den m\u00e5de opn\u00e5s en form for ensartethed og forenkling af overv\u00e5gningen. Selve overv\u00e5gningen foreg\u00e5r fra et klyngeservermilj\u00f8 med PRTG. Overv\u00e5gningsskemaet er omtrent s\u00e5dan her:<\/p>\n

\"VXLAN
\n
\nIndtil vi kun arbejdede med VLAN, fungerede alt meget almindeligt og forudsigeligt, som en klokke. Efter implementeringen af NSX-V og VXLAN st\u00f8dte vi p\u00e5 sp\u00f8rgsm\u00e5let - kan vi forts\u00e6tte med at overv\u00e5ge p\u00e5 den gamle m\u00e5de? P\u00e5 tidspunktet for dette sp\u00f8rgsm\u00e5l var den \"hurtigste\" l\u00f8sning at implementere NSX ESG og tilslutte VXLAN trunk-interface til VTEP-netv\u00e6rket. Hurtig i citationstegn - da brugen af GUI til ops\u00e6tning af kundenet, SNAT og firewallregler muligvis ensarterer styringen i et enkelt interface i vSphere, men efter min mening er det ret besv\u00e6rligt og begr\u00e6nser desuden v\u00e6rkt\u00f8jss\u00e6ttet til fejlfinding. De, der har brugt NSX ESG som en erstatning for en \"rigtig\" firewall, vil nok v\u00e6re enige. Selvom dette valg sikkert ville have v\u00e6ret mere stabilt - for det hele foreg\u00e5r inden for en enkelt leverand\u00f8r.<\/p>\n

En anden l\u00f8sning er at bruge NSX DLR i brotilstand mellem VLAN og VXLAN. Her t\u00e6nker jeg, at alt er klart - man mister simpelthen fordelene ved at anvende VXLAN, da man alligevel skal tr\u00e6kke VLAN til overv\u00e5gningsinstallationen. For resten st\u00f8dte jeg i processen med at implementere denne l\u00f8sning p\u00e5 et problem, hvor DLR-broen ikke sendte pakker til den virtuelle maskine, den var p\u00e5 samme v\u00e6rt som. Jeg ved, jeg ved - i b\u00f8ger og guider om NSX-V st\u00e5r der klart, at der skal tildeles en separat klynge til NSX Edge, men det er i b\u00f8gerne... Under alle omst\u00e6ndigheder, efter et par m\u00e5neder med supporten fandt vi ikke en l\u00f8sning. I princippet forstod jeg logikken bag \u2013 kerne-modulet i hypervisoren, der er ansvarligt for VXLAN-enkapsulering, blev ikke aktiveret, hvis DLR og den overv\u00e5gede server var p\u00e5 samme v\u00e6rt, da trafikken ikke forlader v\u00e6rten og logisk set burde v\u00e6re tilsluttet til VXLAN-segmentet - enkapsulering er ikke n\u00f8dvendig. Med supporten stoppede vi ved den virtuelle interface vdrPort, som logisk forbinder uplinks, og som ogs\u00e5 udf\u00f8rer bro-enkapsuleringen - d\u00e9r blev der observeret en uoverensstemmelse i den indg\u00e5ende trafik, som jeg tog med i den nuv\u00e6rende sag. Men som n\u00e6vnt, f\u00e6rdiggjorde jeg ikke denne sag, da jeg blev omplaceret til et andet projekt, og den bane var oprindeligt en blind vej, s\u00e5 jeg havde ikke rigtig lyst til at udvikle den. Hvis jeg ikke tager fejl, blev problemet observeret i versionerne NSX 6.1.4 og 6.2. <\/p>\n

Og her - bingo! Fortinet annoncerer indf\u00f8relse af underst\u00f8ttelse af VXLAN<\/a><\/noindex>. Og ikke bare point-to-point eller VXLAN-over-IPSec, ikke softwarebro VPS-VXLAN - alt dette begyndte de at implementere allerede fra version 5.4 (og er ogs\u00e5 pr\u00e6senteret hos andre leverand\u00f8rer<\/a><\/noindex>), og den reelle st\u00f8tte til unicast control plane. Da jeg implementerede l\u00f8sningen, st\u00f8dte jeg p\u00e5 et yderligere problem - de servere, jeg overv\u00e5gede, forsvandt og dukkede op i monitoreringen, selvom den virtuelle maskine var liv. \u00c5rsagen viste sig at v\u00e6re, at jeg havde glemt at tillade Ping p\u00e5 VXLAN-interfacet. Under balanceringen af klyngerne blev de virtuelle maskiner flyttet, og Ping afsluttede vMotion for at angive den nye ESXI-v\u00e6rt, som maskinen var flyttet til. Det var min dumhed, men dette problem underminerede endnu engang tilliden til producentens support - i dette tilf\u00e6lde Fortinet. Jeg n\u00e6vner ikke engang, at hvert tilf\u00e6lde relateret til VXLAN starter med sp\u00f8rgsm\u00e5let 'hvor er jeres indstillinger for softswitch VLAN-VXLAN?' Denne gang blev jeg r\u00e5det til at \u00e6ndre MTU - det er til Ping, som er 32 bytes. Derefter 'leg lidt' med tcp-send-mss og tcp-receive-mss i politikken - for VXLAN, der indkapsles i UDP. Puha, undskyld - det er blevet for meget. Jeg l\u00f8ste i bund og grund dette problem selv. <\/p>\n

Efter at have k\u00f8rt testtrafik med succes, blev det besluttet at implementere denne l\u00f8sning. Og i produktionen fandt vi ud af, at efter et par dage begyndte alt overv\u00e5get over VXLAN gradvist at falde ud. Deaktivering\/aktivering af interfacet hjalp, men kun midlertidigt. I lyset af producentens langsommelige support begyndte jeg at fejls\u00f8ge p\u00e5 min side - trods alt er mit netv\u00e6rk og min virksomhed mit ansvar. <\/p>\n

Under spoileren er min fejls\u00f8gningsproces. Hvis du er tr\u00e6t af bogstaver og praleri - spring over og g\u00e5 videre til efteranalysen.<\/p>\n

Forl\u00f8b af fejls\u00f8gning<\/b>Tak fordi du fortsatte med at l\u00e6se - lad os forts\u00e6tte!<\/p>\n

S\u00e5, overv\u00e5gningen fungerer et stykke tid, s\u00e5 falder den ud af sig selv. Det betyder, at der sandsynligvis ikke er nogen problemer i firewall-politikkerne. Men da jeg har st\u00f8dt p\u00e5 problemer med h\u00e6ngende systemprocesser i Fortigate versioner 5.6+, skal vi f\u00f8rst kigge p\u00e5 \"diagnose debug flow\" - som forventet tillades trafikken og forlader interfacet, og som forventet kommer der intet svar. S\u00e5 vi graver videre i stakken. Jeg bliver desv\u00e6rre n\u00f8dt til at skjule adresser, selvom de er RFC1918, men jeg h\u00e5ber at give processen en tilstr\u00e6kkelig beskrivelse til forst\u00e5else. Serveren inde i VXLAN har adressen x.x.x.15, Fortigate-interfacet har adressen x.x.x.254, og alle andre adresser tilh\u00f8rer VTEP-netv\u00e6rket.<\/p>\n

For successful transmission of VXLAN encapsulated packets, correct information is required in several tables. For overlay, this is ARP and OVSDB; for underlay, it's ARP and CAM. In the case of Fortigate, VXLAN FDB is the OVSDB. Let's start there:<\/p>\n

 fortigate (root) #diag sys vxlan fdb list vxlan-LS\nmac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=\u0443.\u0443.\u0443.47 port=4789 vni=5008 ifindex=7\n<\/code><\/pre>\n
\nEverything here is quite simple \u2014 the MAC address of the virtual machine must be located on the VTEP with the address \u0443.\u0443.\u0443.47. Looking at the contents and settings of the ESXi cluster, I find that the MAC of the virtual machine is correct, and so is the VTEP address. I check the CAM\/ARP table on the Fortigate \u2014 again, everything matches the settings of the ESXi host:<\/p>\n
fortigate (root) #get sys arp | grep \u0443.\u0443.\u0443.47\n\u0443.\u0443.\u0443.47 0 00:50:56:65:f6:2c dmz\n<\/code><\/pre>\n
\nTabellerne er korrekte, og trafikken g\u00e5r ud - m\u00e5ske er problemet ikke p\u00e5 Fortigate? Jeg sprang bevidst over analysen af trafikkommunikationen p\u00e5 Juniper - logisk set skal n\u00e6ste skridt i fejlfindingen udf\u00f8res der, men mit netv\u00e6rk er simpelt - kun \u00e9n VLAN til VTEP, og alle komponenter er tilsluttet direkte. Plus jeg husker et tilf\u00e6lde med DLR-broen, VDR og forsvindende trafik - jeg g\u00e5r ind for at sniffe p\u00e5 ESXI-v\u00e6rten og opretter samtidig en sag til VMware. Nedenfor tilh\u00f8rer MAC '97:6e' Fortigate, vmnic1 - det er det interface, der har VTEP med adressen u.u.u.47, vi sniffer i begge retninger \"\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
\nProgress \u2014 in the sniff, I see an ARP request and the incoming response. I only show the ARP response, and everything there is correct. I didn't mention, but all this time, the monitoring server is pinging the address \u0445.\u0445.\u0445.15 \u2014 where is the ICMP traffic? I recall that I have two uplinks. One might argue that the source virtual port is the same (my teaming policy), meaning that for the same vNIC, one and the same uplink should be selected, but since I'm at the host, checking the other uplink is no problem:<\/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
\nForesp\u00f8rgsler kommer fra Fortigate, men der er ingen svar. Det vil sige, problemet ligger ikke hos Fortigate. N\u00e5, t\u00e6nker jeg, igen det samme problem med forsvindende trafik p\u00e5 VDR, igen et par m\u00e5neder for at f\u00e5 sagen i den rette retning. Efter et par dage, efter at jeg k\u00f8let ned, og ikke ville acceptere d\u00f8dtid, besluttede jeg mig for at finde nogle flere sniffere til supporten for at fremskynde processen. Og her falder mit blik \"tilf\u00e6ldigvis\" p\u00e5 Ethernet-inkapslingen underlay. Kongen er ikke \u00e6gte, og MAC-adressen for VTEP stemmer ikke overens med dens IP. Jeg nulstiller, sniffer, graver \u2013 korrekt, hvad der ikke er korrekt. Jeg vil f\u00f8re ARP-tabellen ved siden af, s\u00e5 det er nemmere at sammenligne. Bem\u00e6rk den f\u00f8rste Ethernet-inkapsling p\u00e5 billedet ovenfor:<\/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
\nS\u00e5 hvad har vi i sidste ende \u2013 efter migreringen af den virtuelle maskine, fors\u00f8ger Fortigate at sende trafik til VTEP fra (korrekt) VXLAN FDB, men bruger den forkerte DST MAC, og trafikken bliver selvf\u00f8lgelig afvist af den interface, der modtager den. I \u00e9n ud af fire tilf\u00e6lde tilh\u00f8rte denne MAC den oprindelige hypervisor, som vi startede migreringen af maskinen fra.<\/p>\n
I g\u00e5r modtog jeg en e-mail fra Fortinets support \u2013 der blev \u00e5bnet en fejl 615586 i min sag. Jeg ved ikke helt, om jeg skal v\u00e6re glad eller trist: p\u00e5 den ene side er problemet ikke i indstillingerne, p\u00e5 den anden side kommer fixet kun med en firmwareopdatering, i bedste fald i den n\u00e6ste. Mine fornemmelser forst\u00e6rkes ogs\u00e5 af en anden fejl, som jeg opdagede i sidste m\u00e5ned, dog denne gang i HTML5 GUI vSphere. Det f\u00f8les som et lokalt QA-team for leverand\u00f8rer...<\/p>\n
Jeg tager chancen for at antage f\u00f8lgende:<\/p>\n
1 \u2014 multicast kontrolplanen vil sandsynligvis ikke v\u00e6re udsat for det beskrevne problem \u2014 for MAC-adresserne for VTEP udledes fra IP-adressen for den gruppe, som interfacet abonnerer p\u00e5. <\/p>\n
2 \u2014 problemet med Fortigate ligger sandsynligvis i offloadingen af sessioner til Network Processor (tiln\u00e6rmelsesvis svarende til CEF) \u2014 hvis hver pakke sendes gennem CPU'en, vil der blive brugt tabeller med de korrekte \u2014 i det mindste visuelt \u2014 oplysninger. Til st\u00f8tte for denne antagelse g\u00e5r der, at det hj\u00e6lper at lukke\/\u00e5bne interfacet eller vente et stykke tid \u2014 mere end 5 minutter. <\/p>\n
3 \u2014 \u00e6ndring af teaming-politik, for eksempel til explicit failover, eller implementering af LAG vil ikke l\u00f8se problemet, da der er observeret \"fastl\u00e5sning\" af MAC-adressen for den oprindelige hypervisor i inkapslede pakker.<\/p>\n
I lyset af dette kan jeg dele, at jeg for nylig har opdaget blog<\/a><\/noindex>, hvor det i en af artiklerne blev h\u00e6vdet, at stateful firewalls og cachebare metoder til dataoverf\u00f8rsel er n\u00f8dforanstaltninger. N\u00e5, jeg er ikke s\u00e5 erfaren inden for IT til at p\u00e5st\u00e5 s\u00e5danne ting, og jeg er heller ikke altid enig med alle udsagn i blogartikler. Men noget fort\u00e6ller mig, at der er en del sandhed i Ivans ord.<\/p>\n
Tak for din opm\u00e6rksomhed! Jeg vil v\u00e6re glad for at besvare sp\u00f8rgsm\u00e5l og h\u00f8re konstruktiv kritik.
\n
Kilde: 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\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 i NSX-V \u2014 fejls\u00f8ger underlay | ProHoster","description":"Velkommen, og f\u00f8rst lidt lyrik.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/73232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=73232"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/73232\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/73233"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=73232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=73232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=73232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}