{"id":91646,"date":"2020-08-16T07:42:09","date_gmt":"2020-08-16T05:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-trablshutit-otechestvennyj-ipsec-vpn-chast-1"},"modified":"2020-08-16T07:42:09","modified_gmt":"2020-08-16T05:42:09","slug":"kak-trablshutit-otechestvennyj-ipsec-vpn-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-trablshutit-otechestvennyj-ipsec-vpn-chast-1","title":{"rendered":"C\u00f3mo solucionar problemas de un VPN IPsec nacional. Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"C\u00f3mo
\n<\/p>\n

Situaci\u00f3n<\/h3>\n

\nEs fin de semana. Estoy tomando caf\u00e9. El estudiante configur\u00f3 una conexi\u00f3n VPN entre dos puntos y desapareci\u00f3. Verifico: el t\u00fanel realmente existe, pero no hay tr\u00e1fico en el t\u00fanel. No responde a las llamadas.<\/p>\n

Pongo a calentar agua y me sumerjo en la soluci\u00f3n de problemas del Gateway de C-Terra. Comparto mi experiencia y metodolog\u00eda.
\n<\/a><\/noindex><\/p>\n

Datos de entrada<\/h3>\n

\nDos ubicaciones geogr\u00e1ficamente separadas est\u00e1n conectadas por un t\u00fanel GRE. Necesitamos cifrar GRE:<\/p>\n

\"C\u00f3mo
\n
\nVerifico el funcionamiento del t\u00fanel GRE. Para ello, ejecuta un ping desde el dispositivo R1 hasta la interfaz GRE del dispositivo R2. Este es el tr\u00e1fico objetivo para el cifrado. No hay respuesta:<\/p>\n

root@R1:~# ping 1.1.1.2 -c 4\nPING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.\n\n--- estad\u00edsticas de ping 1.1.1.2 ---\n4 paquetes transmitidos, 0 recibidos, 100% de p\u00e9rdida de paquetes, tiempo 3057ms<\/code><\/pre>\n
\nReviso los logs en Gate1 y Gate2. El log informa con alegr\u00eda que el t\u00fanel IPsec se ha establecido con \u00e9xito, sin problemas:<\/p>\n
root@Gate1:~# cat \/var\/log\/cspvpngate.log\n5 de agosto 16:14:23 localhost vpnsvc: 00100119  Conexi\u00f3n IPSec 5 establecida, selector de tr\u00e1fico 172.17.0.1->172.16.0.1, proto 47, par 10.10.10.251, id \"10.10.10.251\", Filtro \nIPsec:Protect:CMAP:1:LIST, Acci\u00f3n IPsec IPsecAction:CMAP:1, Regla IKERule IKERule:CMAP:1<\/code><\/pre>\n
\nEn las estad\u00edsticas del t\u00fanel IPsec en Gate1 veo que el t\u00fanel realmente existe, pero el contador Rcvd est\u00e1 en cero:<\/p>\n
root@Gate1:~# sa_mgr show\nSesiones ISAKMP: 0 iniciadas, 0 respondidas\n\nConexiones ISAKMP:\nNum Conn-id (Direcci\u00f3n Local,Puerto)-(Direcci\u00f3n Remota,Puerto) Estado Enviado Recibido\n1 3 (10.10.10.251,500)-(10.10.10.252,500) activo 1070 1014\n\nConexiones IPsec:\nNum Conn-id (Direcci\u00f3n Local,Puerto)-(Direcci\u00f3n Remota,Puerto) Protocolo Tipo Acci\u00f3n Enviado Recibido\n1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP t\u00fanel 480 0<\/code><\/pre>\n
\nEstoy solucionando problemas en C-Terra de esta manera: busco d\u00f3nde se pierden los paquetes en el camino de R1 a R2. En el proceso (spoiler) encuentro un error.<\/p>\n
Soluci\u00f3n de problemas<\/h3>\n
\nPaso 1. \u00bfQu\u00e9 recibe Gate1 de R1?<\/b><\/p>\n
Utilizo el sniffer de paquetes integrado \u2013 tcpdump. Inicia el sniffer en la interfaz interna (Gi0\/1 en notaci\u00f3n similar a Cisco o eth1 en notaci\u00f3n de OS Debian):<\/p>\n
root@Gate1:~# tcpdump -i eth1\n\ntcpdump: salida detallada suprimida, use -v o -vv para un decodificaci\u00f3n completa del protocolo\nescuchando en eth1, tipo de enlace EN10MB (Ethernet), tama\u00f1o de captura 262144 bytes\n14:53:38.879525 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, longitud 92: IP 1.1.1.1 > 1.1.1.2: solicitud de eco ICMP, id 2083, seq 1, longitud 64\n14:53:39.896869 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, longitud 92: IP 1.1.1.1 > 1.1.1.2: solicitud de eco ICMP, id 2083, seq 2, longitud 64\n14:53:40.921121 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, longitud 92: IP 1.1.1.1 > 1.1.1.2: solicitud de eco ICMP, id 2083, seq 3, longitud 64\n14:53:41.944958 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, longitud 92: IP 1.1.1.1 > 1.1.1.2: solicitud de eco ICMP, id 2083, seq 4, longitud 64<\/code><\/pre>\n
\nVeo que Gate1 recibe paquetes GRE de R1. Sigo adelante.<\/p>\n
Paso 2. \u00bfQu\u00e9 hace Gate1 con los paquetes GRE?<\/b><\/p>\n
Con la utilidad klogview, reviso qu\u00e9 est\u00e1 sucediendo con los paquetes GRE dentro VPN<\/a> del controlador de C-Terra:<\/p>\n
root@Gate1:~# klogview -f 0xffffffff\n\nresultado de filtraci\u00f3n para paquete saliente 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: cadena 4 \"IPsecPolicy:CMAP\", filtro 8, id de evento IPsec:Protect:CMAP:1:LIST, estado ACEPTAR\nencapsulando con SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0\npaquete saliente 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: encapsulado\n<\/code><\/pre>\n
\nVeo que el tr\u00e1fico GRE objetivo (proto 47) 172.16.0.1 -> 172.17.0.1 pas\u00f3 (PASS) bajo la regla de cifrado LIST en la pol\u00edtica criptogr\u00e1fica CMAP y fue cifrado (encapsulado). Luego, el paquete fue enrutado (pasado). No hay tr\u00e1fico de respuesta en la salida de klogview.<\/p>\n
Estoy revisando las listas de acceso en el dispositivo Gate1. Veo una lista de acceso LIST, que define el tr\u00e1fico objetivo para el cifrado, lo que significa que no hay reglas de M\u00c1 configuradas:<\/p>\n
Gate1#show access-lists\nLista de acceso IP extendida LIST\n    10 permitir gre host 172.16.0.1 host 172.17.0.1<\/code><\/pre>\n
\nConclusi\u00f3n: el problema no est\u00e1 en el dispositivo Gate1.<\/p>\n
M\u00e1s sobre klogview<\/b><\/p>\n
El controlador VPN procesa todo el tr\u00e1fico de red, no solo aquel que debe ser cifrado. Estos mensajes son visibles en klogview, si el controlador VPN proces\u00f3 el tr\u00e1fico de red y lo envi\u00f3 en formato no cifrado:<\/p>\n
root@R1:~# ping 172.17.0.1 -c 4<\/code><\/pre>\n
<\/p>\n
root@Gate1:~# klogview -f 0xffffffff\n\nresultado de filtraci\u00f3n para paquete saliente 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: cadena 4 \"IPsecPolicy:CMAP\": sin coincidencia\npaquete saliente 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: filtrado<\/code><\/pre>\n
\nVeo que el tr\u00e1fico ICMP (proto 1) 172.16.0.1->172.17.0.1 no coincidi\u00f3 (no match) con las reglas de cifrado de la pol\u00edtica criptogr\u00e1fica CMAP. El paquete fue enrutado (pasado) en formato abierto.<\/p>\n
Paso 3. Qu\u00e9 recibe Gate2 de Gate1<\/b><\/p>\n
Ejecutando un sniffer en la interfaz WAN (eth0) de Gate2:<\/p>\n
root@Gate2:~# tcpdump -i eth0\ntcpdump: salida detallada suprimida, use -v o -vv para una decodificaci\u00f3n completa del protocolo\nescuchando en eth0, tipo de enlace EN10MB (Ethernet), tama\u00f1o de captura 262144 bytes\n16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), longitud 140\n16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), longitud 140\n16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), longitud 140\n16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), longitud 140<\/code><\/pre>\n
\nVeo que Gate2 recibe paquetes ESP de Gate1.<\/p>\n
Paso 4. Qu\u00e9 hace Gate2 con los paquetes ESP<\/b><\/p>\n
Ejecutando la utilidad klogview en Gate2:<\/p>\n
root@Gate2:~# klogview -f 0xffffffff\nresultado de filtraci\u00f3n para paquete entrante 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: cadena 17 \"FilterChain:L3VPN\", filtro 21, estado DESCARTADO\nen paqu\u00e9te descartado 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: firewall\n<\/code><\/pre>\n
\nVeo que los paquetes ESP (proto 50) fueron descartados (DROP) por la regla (L3VPN) del firewall. Me aseguro de que la lista de acceso L3VPN realmente est\u00e9 vinculada a Gi0\/0:<\/p>\n
Gate2#show ip interface gi0\/0\nGigabitEthernet0\/0 est\u00e1 activo, el protocolo de l\u00ednea est\u00e1 activo\n  Direcci\u00f3n de Internet es 10.10.10.252\/24\n  MTU es de 1500 bytes\n  Lista de acceso saliente no est\u00e1 configurada\n  Lista de acceso entrante es L3VPN<\/code><\/pre>\n
\nHe encontrado el problema.<\/p>\n
Paso 5. Qu\u00e9 est\u00e1 mal con la lista de acceso
\n<\/b>
\nVeo c\u00f3mo es la lista de acceso L3VPN:<\/p>\n
Gate2#show access-list L3VPN\nLista de acceso IP extendida L3VPN\n    10 permitir udp host 10.10.10.251 any eq isakmp\n    20 permitir udp host 10.10.10.251 any eq non500-isakmp\n    30 permitir icmp host 10.10.10.251 any<\/code><\/pre>\n
\nVeo que se permiten paquetes ISAKMP, as\u00ed que se establece el t\u00fanel IPsec. Sin embargo, no hay una regla que permita ESP. Parece que el estudiante confundi\u00f3 icmp y esp.<\/p>\n
Corregir\u00e9 la lista de acceso:<\/p>\n
Gate2(config)#\nip access-list extended L3VPN\nno 30\n30 permit esp host 10.10.10.251 any<\/code><\/pre>\n
\nPaso 6. Verifico la funcionalidad<\/b><\/p>\n
Primero me aseguro de que la lista de acceso L3VPN sea correcta:<\/p>\n
Gate2#show access-list L3VPN\nLista de acceso IP extendida L3VPN\n    10 permitir udp host 10.10.10.251 any eq isakmp\n    20 permitir udp host 10.10.10.251 any eq non500-isakmp\n    30 permitir esp host 10.10.10.251 any<\/code><\/pre>\n
\nAhora desde el dispositivo R1 inicio el tr\u00e1fico objetivo:<\/p>\n
root@R1:~# ping 1.1.1.2 -c 4\nPING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.\n64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=35.3 ms\n64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=3.01 ms\n64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=2.65 ms\n64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=2.87 ms\n\n--- Estad\u00edsticas de ping de 1.1.1.2 ---\n4 paquetes transmitidos, 4 recibidos, 0% p\u00e9rdida de paquetes, tiempo 3006ms\nrtt min\/avg\/max\/mdev = 2.650\/10.970\/35.338\/14.069 ms<\/code><\/pre>\n
\nVictoria. El t\u00fanel GRE se ha establecido. El contador de tr\u00e1fico entrante en las estad\u00edsticas IPsec no es cero:<\/p>\n
root@Gate1:~# sa_mgr show\nSesiones ISAKMP: 0 iniciadas, 0 respondidas\n\nConexiones ISAKMP:\nNum Conn-id (Direcci\u00f3n Local, Puerto)-(Direcci\u00f3n Remota, Puerto) Estado Enviado Recibido\n1 3 (10.10.10.251,500)-(10.10.10.252,500) activo 1474 1350\n\nConexiones IPsec:\nNum Conn-id (Direcci\u00f3n Local, Puerto)-(Direcci\u00f3n Remota, Puerto) Protocolo Acci\u00f3n Tipo Enviado Recibido\n1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480<\/code><\/pre>\n
\nEn el gateway Gate2, aparecieron mensajes en el klogview indicando que el tr\u00e1fico objetivo 172.16.0.1->172.17.0.1 fue descifrado correctamente (PASS) por la regla LIST en el mapa criptogr\u00e1fico CMAP:<\/p>\n
root@Gate2:~# klogview -f 0xffffffff\nresultado de filtraci\u00f3n para paquete entrante 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: cadena 18 \"IPsecPolicy:CMAP\", filtro 25, id de evento IPsec:Protect:CMAP:1:LIST, estado ACEPTAR\npaquete entrante 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: desencapsulado<\/code><\/pre>\n
\nResultados<\/b><\/p>\n
El estudiante estrope\u00f3 la salida. 
\nCuidado con las reglas M\u042d.<\/p>\n
Ingeniero an\u00f3nimo
\nt.me\/anonimous_engineer<\/i>
\n
Fuente: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0421\u0438\u0442\u0443\u0430\u0446\u0438\u044f \u0412\u044b\u0445\u043e\u0434\u043d\u043e\u0439. \u041f\u044c\u044e \u043a\u043e\u0444\u0435. \u0421\u0442\u0443\u0434\u0435\u043d\u0442 \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043b VPN \u0441\u043e\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u0435 \u043c\u0435\u0436\u0434\u0443 \u0434\u0432\u0443\u043c\u044f \u0442\u043e\u0447\u043a\u0430\u043c\u0438 \u0438 \u0438\u0441\u0447\u0435\u0437. \u041f\u0440\u043e\u0432\u0435\u0440\u044f\u044e: \u0442\u0443\u043d\u043d\u0435\u043b\u044c \u0434\u0435\u0439\u0441\u0442\u0432\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0435\u0441\u0442\u044c, \u043d\u043e \u0442\u0440\u0430\u0444\u0438\u043a\u0430 \u0432 \u0442\u0443\u043d\u043d\u0435\u043b\u0435 \u043d\u0435\u0442. \u041d\u0430 \u0437\u0432\u043e\u043d\u043a\u0438 \u0441\u0442\u0443\u0434\u0435\u043d\u0442 \u043d\u0435 \u043e\u0442\u0432\u0435\u0447\u0430\u0435\u0442. \u0421\u0442\u0430\u0432\u043b\u044e \u0447\u0430\u0439\u043d\u0438\u043a \u0438 \u043f\u043e\u0433\u0440\u0443\u0436\u0430\u044e\u0441\u044c \u0432 \u0442\u0440\u0430\u0431\u043b\u0448\u0443\u0442\u0438\u043d\u0433 \u0421-\u0422\u0435\u0440\u0440\u0430 \u0428\u043b\u044e\u0437. \u0414\u0435\u043b\u044e\u0441\u044c \u0441\u0432\u043e\u0438\u043c \u043e\u043f\u044b\u0442\u043e\u043c \u0438 \u043c\u0435\u0442\u043e\u0434\u043e\u043b\u043e\u0433\u0438\u0435\u0439. \u0418\u0441\u0445\u043e\u0434\u043d\u044b\u0435 \u0434\u0430\u043d\u043d\u044b\u0435 \u0414\u0432\u0435 \u0442\u0435\u0440\u0440\u0438\u0442\u043e\u0440\u0438\u0430\u043b\u044c\u043d\u043e \u0440\u0430\u0437\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0435 \u043f\u043b\u043e\u0449\u0430\u0434\u043a\u0438 \u0441\u0432\u044f\u0437\u0430\u043d\u044b GRE \u0442\u0443\u043d\u043d\u0435\u043b\u0435\u043c. GRE \u043d\u0443\u0436\u043d\u043e \u0437\u0430\u0448\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c: \u041f\u0440\u043e\u0432\u0435\u0440\u044f\u044e \u0440\u0430\u0431\u043e\u0442\u043e\u0441\u043f\u043e\u0441\u043e\u0431\u043d\u043e\u0441\u0442\u044c GRE […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91647,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91646","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\udd47C\u00f3mo solucionar problemas de IPsec VPN nacional. Parte 1 | ProHoster","description":"Situaci\u00f3n de salida.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-trablshutit-otechestvennyj-ipsec-vpn-chast-1","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\udd47\u041a\u0430\u043a \u0442\u0440\u0430\u0431\u043b\u0448\u0443\u0442\u0438\u0442\u044c \u043e\u0442\u0435\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0439 IPsec VPN. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u0421\u0438\u0442\u0443\u0430\u0446\u0438\u044f \u0412\u044b\u0445\u043e\u0434\u043d\u043e\u0439.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-trablshutit-otechestvennyj-ipsec-vpn-chast-1","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-08-16T05:42:09+00:00","article:modified_time":"2020-08-16T05:42:09+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91646","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 12:23:24","updated":"2026-02-04 14:42:05","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\/91646","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=91646"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/91646\/revisions"}],"predecessor-version":[{"id":156750,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/91646\/revisions\/156750"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/91647"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=91646"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=91646"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=91646"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}