Que desastroso resulta en muchas ocasiones administrar algo tan simple como una red, especialmente cuando existen usuarios en ella que les importa poco el trabajo de quienes si quieren trabajar en internet.<\/p>\n
No me explayare mucho en este asunto, muchos manuales y tutoriales hay de QoS, yo me dedicare a explicar brevemente como implementar uno<\/p>\n
QoS es calidad de servicio, pr\u00e1cticamente lo contrario a DoS denegaci\u00f3n de servicio, la calidad trata de asegurarse de que el servicio siempre est\u00e9 disponible.<\/p>\n
Como evitar que Paquito bajando 20 canciones en el ares o Manuelito bajando 2 distribuciones de Linux por FTP consuman todo el ancho de banda disponible y evitando que Pedro no pueda ver la pagina de Continental Airline para comprar ese boleto de avi\u00f3n urgente y que no lo puede comprar por que la pagina esta tan lenta que no termina de cargar nunca, por la falta de ancho de banda disponible.
\nEn una red peque\u00f1a Pedro se levantar\u00eda y les pedir\u00eda a Paquito y Manuelito, que dejen de perder el tiempo y que lo dejen trabajar, pero en un corporativo con cientos de empleados a veces no sabes ni quien es el gandalla comi\u00e9ndose todo el ancho de banda y es aqu\u00ed donde QoS salva el dia.<\/p>\n
Una tarjeta de red o cualquier dispositivo de Red se comporta como buffer de tipo FIFO, Primero en entrar, Primero en salir, Estos buffer se le denominan colas de paquetes y por default est\u00e1n presente en modo FIFO en la mayor\u00eda de los sistemas operativos y esta cola tiene un ancho de banda, del total de la tarjeta, que es de 10Mbps o 100Mbps o 1000Mbps dependiendo de la tarjeta de red o el dispositivo conectado como DSL que suelen tener solo 2Mbps a 8Mbps de ancho de banda de bajada y 512kbps de subida
\n\u00bfEsto que significa?
\nSignifica que si entra primero 20 paquetes de ares a la cola y el 21 es de web, saldr\u00e1n primero los 20 de ares y hasta el final el de web, en una oficina esto es absurdo, aunque entraran los 20 paquetes de ares seria natural que quisi\u00e9ramos que primero salgan los de web porque es de trabajo y hasta el final los de ares. En resumen ares se gasta el ancho de banda y no deja casi nada para navegar en p\u00e1ginas web.<\/p>\n
Si tenemos un equipo Linux con almenos 2 tarjetas de red haci\u00e9ndola de ruteador o de enmasquerador con NAT, podemos controlar el tr\u00e1fico que saldr\u00e1 a internet, ordenando los paquetes con prioridades haciendo de esta forma una red muy veloz aunque haya gente bajando m\u00fasica con P2P como ares y otros.<\/p>\n
\u00bfQue es lo que podemos hacer y que no.?<\/p>\n
Podemos controlar todo el tr\u00e1fico que inicia en nuestra red hacia internet, no podemos controlar el tr\u00e1fico que inicia en otro lado fuera de nuestra red, y que viene a nuestra red, esto es porque los paquetes vienen en desorden al estilo FIFO desde su punto de origen, existen m\u00f3dulos como el IMQ para Linux que pueden controlar el tr\u00e1fico que no iniciamos nosotros, mediante discriminaci\u00f3n de paquetes con una efectividad del 90% pero no hablare de este modulo aqu\u00ed.<\/p>\n
\u00bfQu\u00e9 necesitamos?<\/p>\n
El paquete iproute2 e iptables, iproute2 agrega el comando tc para controlar las colas e iptables nos permitir\u00e1 manipular los paquetes que llegan a las colas<\/p>\n
\u00bfQu\u00e9 hay que hacer para controlar nuestro ancho de banda en la red?<\/p>\n
Lo primero es cambiar la forma FIFO en la que opera la tarjeta de red a htb , le cambiare el ancho de banda a la velocidad del ancho de banda del enlace de internet, de nada sirve una tarjeta de red de 100mbps conectada directamente a internet, si el enlace es de, por ejemplo 2mbps asi que no habr\u00e1 ning\u00fan inconveniente con limitarlo a eso que luego nos servidora para hacer un ancho de banda dinamico, despu\u00e9s de ese ancho de banda de 2mbps creare subanchos de banda en colas con prioridades, despu\u00e9s a estos subanchos de banda les pondr\u00e9 su propio buffer o cola de nuevo con htb y con iptables marcare los paquetes para filtrarlos a estos sub colas de los subanchos de banda del ancho de banda principal de la tarjeta de red =)<\/p>\n
\u00bfPor qu\u00e9 es tan de locos esto del QoS con htb?<\/p>\n
FiFo es f\u00e1cil porque es entrada y salida de datos como llegan, consumiendo a su vez todo el ancho de banda disponible, pero htb permite prioridad y heredar ancho de banda sobrante hasta un l\u00edmite establecido.<\/p>\n
Por ejemplo si tenemos un enlace de 2mbps y queremos 3 niveles de prioridades, acomodaremos los servicios en esos niveles seg\u00fan su importancia.<\/p>\n
Por ejemplo si es importante el WEB haremos que el WEB salga por la cola 1 y le podemos dar una GARANTIA, que al menos 1mbps de los 2mbps estar\u00e1n disponibles para web, el otro mega se reparte entre las otras colas, pero que pasa si las otras colas no tienen tr\u00e1fico, habr\u00eda 1mbps desperdiciado, as\u00ed que podemos tomar ese ancho de banda din\u00e1micamente asignarlo al web.
\nPara entender mejor, le garantizamos 1mbps pero puede navegar a 2mpbs si el ancho de banda est\u00e1 disponible<\/p>\n
Ahora imaginemos que en de esos 2mbps le queremos garantizar 512kbps al FTP en una prioridad 2 esto significar\u00eda que bajaran cosas a 512kbps pero si nadie esta navegando en internet podr\u00eda usar tambi\u00e9n los 2mbps disponibles<\/p>\n
Lo mismo para el ARES en la cola mas baja le garantizamos 512kbps y si nadie esta bajando paginas web ni ftp ares tendra los 2mbps.<\/p>\n
En el momento que alguien navegue en p\u00e1ginas web el ares ser\u00e1 relegado y as\u00ed, la p\u00e1ginas WEB navegaran a un mega, si nadie estuviera bajando nada por el FTP el ares podr\u00eda continuar bajando ahora con el mega sobrante, hasta el momento en que alguien decida bajar algo del FTP entonces seria relegando nuevamente a su ancho de banda garantizado que es de 512kbps por el ftp tiene garantizado 512kbps. Cuando ya nadie baje nade de la web y el ftp haya terminado su descarga. El ARES podr\u00e1 recuperar el uso de los 2Mbps-<\/p>\n
Ahora la pr\u00e1ctica, como implementarlo.
\nPara esta pr\u00e1ctica asumiremos que el servidor de NAT o Ruteo tiene 3 tarjetas de red, la eth2 es la que est\u00e1 conectada a internet.<\/p>\n
Para confirmar el estado de nuestra tarjeta de red podemos usar el comando<\/p>\n
tc -s -d qdisc show dev eth2
\nqdisc pfifo_fast 0: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
\n Sent 17459001308 bytes 20574182 pkt (dropped 0, overlimits 0 requeues 6)
\n rate 0bit 0pps backlog 0b 0p requeues 6<\/p>\n
Encontramos que se encuentra en el modo pfifo_fast de Linux, que es simplemente el m\u00e9todo FIFO tradicional de toda tarjeta<\/p>\n
Cambiando la cola de FIFO a htb en la tarjeta de red<\/p>\n
tc qdisc add dev eth2 root handle 1: htb default 11<\/p>\n
el comando agrega al eth2 la cola f\u00edsica de la tarjeta de red el m\u00e9todo htb adem\u00e1s le puso un nombre, la llamo 1: y el par\u00e1metro default 11 indica que espera encontrar una subcola llamada 11 por donde pasaran los datos que no fueron clasificados, generalmente el default es la cola de m\u00e1s baja prioridad, ya que si no los clasificas seguramente es porque son servicios que importan menos que los que clasificaste como prioritarios.<\/p>\n
Volvemos a ejecutar el comando <\/p>\n
tc -s -d qdisc show dev eth2
\npara ver que sucedio con la tarjeta de red, el resultado sera:<\/p>\n
qdisc htb 1: r2q 10 default 11 direct_packets_stat 1732 ver 3.17
\n Sent 1558805 bytes 1732 pkt (dropped 0, overlimits 0 requeues 0)
\n rate 0bit 0pps backlog 0b 0p requeues 0<\/p>\n
ya no es pfifo_fast es htb<\/p>\n
Ahora limitare el ancho de banda f\u00edsico en la cola de la tarjeta de red, lo bajare a la velocidad de 2mbps
\nCon el comando <\/p>\n
tc class add dev eth2 parent 1: classid 1:1 htb rate 2000kbit ceil 2000kbit
\nEs importante saber que rate es el ancho de banda garantizado y ceil el tope m\u00e1ximo del ancho de banda alcanzable.
\nlas class son las colas virtuales, en este caso esta cola est\u00e1 ligada a la de la tarjeta de red, la de la red la llamamos 1: aqu\u00ed le decimos con parent 1: que esta cola se ligara a su padre en la tarjeta de red y classid 1:1 es el nombre que tendr\u00e1 esta cola con un ancho de banda garantizado (rate) de 2000kbps y que nunca habr\u00e1 mas (ceil) de 2000kbps como ancho de banda por que este es el ancho de banda m\u00e1ximo del enlace dedicado<\/p>\n
Ahora es tiempo de partir en pedazos m\u00e1s peque\u00f1o la cola 1:1, esto lo hacemos con el comando<\/p>\n
tc class add dev eth2 parent 1:1 classid 1:10 htb rate 1512kbit ceil 2000kbit
\nesta l\u00ednea dice que esta cola es hija de la cola anterior (parent 1:1) y que esta a su vez se llama 1:10 continua usando el m\u00e9todo htb, le decimos que est\u00e1 sub cola garantiza 1.5 mbps (rate 1512kbps) pero que podr\u00eda alcanzar hasta los 2mbps (ceil 2000kbps) si el ancho de banda estuviera disponible, al final de la l\u00ednea deber\u00eda ir un prior 0, mientras m\u00e1s baja es la prioridad m\u00e1s importante es la cola prior 0 es m\u00e1s importante y ojo, no se especifica cuando es 0, solo cuando es menos importante como 1, 2 o 3 y as\u00ed.<\/p>\n
Ahora creamos la cola menos importante<\/p>\n
Con el comando <\/p>\n
tc class add dev eth2 parent 1:1 classid 1:11 htb rate 512kbit ceil 2000kbit prio 1
\nEsta cola tambi\u00e9n es hija de 1:1 y hermana de 1:10 se llama as\u00ed misma 1:11, recuerdan el default en la cola f\u00edsica de la tarjeta de red, se llamaba 11, efectivamente esta es la cola a la que vendr\u00e1n los paquetes no clasificados, a esta cola se le garantizan 512kbps pero si est\u00e1 disponible m\u00e1s ancho de banda puede llegar a usar hasta 2mbps, la prioridad dice que es 1 menos importante que 0 as\u00ed como otras subcolas con prior 2 o 3 ser\u00eda menos importantes que prior 1<\/p>\n
Con el comando tc -s -d class show dev eth2 , se puede visualizar el trafico que pasa por cada cola.<\/p>\n
tc -s -d class show dev eth2<\/p>\n
obtendr\u00edamos algo como esto:<\/p>\n
class htb 1:11 parent 1:1 prio 1 quantum 6400 rate 512000bit ceil 2000Kbit burst 1664b\/8 mpu 0b overhead 0b cburst 1850b\/8 mpu 0b overhead 0b level 0
\n Sent 9870557 bytes 9434 pkt (dropped 0, overlimits 0 requeues 0)
\n rate 1233Kbit 148pps backlog 0b 23p requeues 0
\n lended: 2433 borrowed: 6978 giants: 0
\n tokens: -27390 ctokens: -10484<\/p>\n
class htb 1:1 root rate 2000Kbit ceil 2000Kbit burst 1850b\/8 mpu 0b overhead 0b cburst 1850b\/8 mpu 0b overhead 0b level 7
\n Sent 9847632 bytes 9411 pkt (dropped 0, overlimits 0 requeues 0)
\n rate 1262Kbit 152pps backlog 0b 0p requeues 0
\n lended: 6978 borrowed: 0 giants: 0
\n tokens: -10484 ctokens: -10484<\/p>\n
class htb 1:10 parent 1:1 prio 0 quantum 18900 rate 1512Kbit ceil 2000Kbit burst 1788b\/8 mpu 0b overhead 0b cburst 1850b\/8 mpu 0b overhead 0b level 0
\n Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
\n rate 0bit 0pps backlog 0b 0p requeues 0
\n lended: 0 borrowed: 0 giants: 0
\n tokens: 9465 ctokens: 7400<\/p>\n
hay 3 colas!!! Exacto, la cola padre que es la de la tarjeta de red, y las 2 hijas<\/p>\n
Recordemos que todo trafico no clasificado por default se va a la hija 11, si ponen atenci\u00f3n ver\u00e1n que el valor send del 1:10 esta en 0, esto es porque no hay tr\u00e1fico en la cola prioritaria, no lo hay porque no hemos clasificado nada toda la red esta desclasificada asi que todo los paquetes que van a internet se van a la cola 11, no hay problema, recordemos que en el ceil dijimos que podr\u00eda alcanzar 2mbps si el ancho de banda est\u00e1 disponible, asi que en este punto todos siguen navegando a 2mbps sin ning\u00fan problema<\/p>\n
Ahora se agrega otra cola a las colas hijas, pero con el m\u00e9todo sfq que permite reorganizar paquetes del mismo tipo, para que salgan juntos, de esta forma intentaremos que si en las colas hay paquetes desordenados, digamos defragmentados, ya que es un t\u00e9rmino mejor conocido por el comportamiento de los archivos del disco duro. El sfq los defragmenta para que los paquetes de web salgan todos juntos, los de ftp salgan todos juntos, y as\u00ed, esto le diremos que lo haga cada 10 segundos que es un tiempo razonable. Para reorganizar los paquetes en la cola.<\/p>\n
Entonces si en la cola hab\u00eda estos paquetes por ejemplo:<\/p>\n
Web,ftp,ssh, web,ssh,ftp,ftp,web el sfq los dejara asi
\nWeb,web,web,ftp,ftp,ftp,ssh,ssh<\/p>\n
Esto lo hacemos con los siguientes comandos.<\/p>\n
tc qdisc add dev eth2 parent 1:10 handle 10: sfq perturb 10<\/p>\n
esta cola es hoja de 1:10 (parent 1:10) asi misma se llamara 10 (handle 10) con el m\u00e9todo sfq que suceder\u00e1 cada 10 segundos y para la otra cola igual
\ntc qdisc add dev eth2 parent 1:11 handle 11: sfq perturb 10<\/p>\n
N\u00f3tese que esto es jer\u00e1rquico, las colas sfq nietas de la cola de 2mbps, le entregan la cola a las hijas htb de la cola de 2mbps htb y esta ultima a la cola de su propio padre que es la tarjeta de red que tambi\u00e9n es htb<\/p>\n
Hasta aqu\u00ed est\u00e1 bien, ya organizamos paquetes y sabemos la prioridad, pero aun no hemos clasificado los paquetes por lo que si volvemos a ver la informaci\u00f3n de las colas, la 1:10 seguir\u00e1 en 0 bytes enviados, la cola que se mover\u00e1n seguir\u00e1 siendo la 11 porque es la default y por ah\u00ed sigue pasando todo el trafico de la red, porque todo continua sin clasificarse.<\/p>\n
Preparando las colas para recibir paquetes clasificados<\/p>\n
tc filter add dev eth2 protocol ip prio 1 parent 1: handle 1 fw classid 1:10
\nfiltramos protocol ip prioridad 1 (mas alta en filtracion) de la cola padre 1: manejara paquetes firmados con la marca 1 (handle 1) estos paquetes sera reenviados (fw) a la clase 1:10
\ntc filter add dev eth2 protocol ip prio 2 parent 1: handle 2 fw classid 1:11
\nigual que el anterior, pero con prioridad menor (2) los paquetes con la marca 2 se reenv\u00edan a la cola 1:11. OJO en esta configuraci\u00f3n podr\u00edamos omitir este comando, recordemos que todo lo que no est\u00e9 firmado o marcado, de todos modos terminara en la cola 11 es la default.<\/p>\n
En este punto ya hay un filtrador de colas esperando paquetes con marcas 1 y 2, pero, \u00bfQui\u00e9n marca esos paquetes?, no hay ning\u00fan paquete marcado a pesar de contar con los filtros los paquetes no vienen marcados as\u00ed que en este momento continuamos con que la \u00fanica cola en movimiento es la 11 porque la 10 no recibe paquetes, ya que f\u00edsicamente ning\u00fan paquete viene con la marca 1 que es la marca que los filtrar\u00eda a la cola prioritaria.<\/p>\n
Es hora de iptable para marcar con mangle<\/p>\n
iptables -t mangle -A FORWARD -p tcp –dport 80 -j MARK –set-mark 1
\niptables -t mangle -A FORWARD -p tcp –dport 80 -j RETURN<\/p>\n
Todo el tr\u00e1fico que mandamos a internet que sea un paquete tcp y que lleve por destino el Puerto 80 deber\u00e1 ser marcado como 1, la segunda l\u00ednea la del return indica que no debe ser remarcado, fue marcado como 1 y con esa debe quedarse, por si hubiera por la red alg\u00fan otro equipo remarcando paquetes.<\/p>\n
LISTO!!!!!, comprobando que es verdad<\/p>\n
tc -s -d class show dev eth2<\/p>\n
debemos obtener algo como esto<\/p>\n
class htb 1:11 parent 1:1 prio 1 quantum 6400 rate 512000bit ceil 2000Kbit burst 1664b\/8 mpu 0b overhead 0b cburst 1850b\/8 mpu 0b overhead 0b level 0
\n Sent 524112583 bytes 499349 pkt (dropped 0, overlimits 0 requeues 0)
\n rate 1971Kbit 230pps backlog 0b 41p requeues 0
\n lended: 128668 borrowed: 370640 giants: 0
\n tokens: -14475 ctokens: -8151<\/p>\n
class htb 1:1 root rate 2000Kbit ceil 2000Kbit burst 1850b\/8 mpu 0b overhead 0b cburst 1850b\/8 mpu 0b overhead 0b level 7
\n Sent 524189335 bytes 500233 pkt (dropped 0, overlimits 0 requeues 0)
\n rate 1980Kbit 241pps backlog 0b 0p requeues 0
\n lended: 370640 borrowed: 0 giants: 0
\n tokens: -11447 ctokens: -11447<\/p>\n
class htb 1:10 parent 1:1 prio 0 quantum 18900 rate 1512Kbit ceil 2000Kbit burst 1788b\/8 mpu 0b overhead 0b cburst 1850b\/8 mpu 0b overhead 0b level 0
\n Sent 121393 bytes 925 pkt (dropped 0, overlimits 0 requeues 0)
\n rate 8752bit 10pps backlog 0b 0p requeues 0
\n lended: 925 borrowed: 0 giants: 0
\n tokens: 9127 ctokens: 7144<\/p>\n
En la cola 10, ya hay movimiento ya le llegan los paquetes de tr\u00e1fico WEB el cual en esta configuraci\u00f3n decidimos que es m\u00e1s importante que cualquier otro paquete, podr\u00edamos tener m\u00e1s colas e incluso colas que comparten varios servicios por ejemplo podemos marcar el ssh en la cola prioritaria <\/p>\n
iptables -t mangle -A FORWARD -p tcp –dport 22 -j MARK –set-mark 1
\niptables -t mangle -A FORWARD -p tcp –dport 22 -j RETURN<\/p>\n
Con eso todo paquete ssh se marca con 1, compartiendo prioridad con los paquetes de WEB<\/p>\n
\u00bfQu\u00e9 es lo que tenemos?<\/p>\n
Tenemos un ancho de banda de 2mbps
\nEl WEB es metido en la cola de prioridad 0 que tiene un ancho de banda garantizado de 1.5mbps y pudiendo llegar a 2mbps si los otros 512kbps no estan siendo usados.<\/p>\n
Tenemos que el resto del tr\u00e1fico no marcado como 1 se va a la cola de 512kbps pudiendo llegar a 2mbps si no hay trafico prioritario en la cola de 1.5mbps<\/p>\n
En resumen, en el caso de ARES podr\u00edamos bajar ARES a 2mbps siempre y cuando nadie navegue en internet, si alguien navega a 1.5mbps en las p\u00e1ginas web, los ares de la red y otros servicios se quedaran con su ancho de banda garantizado de solo 512kbps<\/p>\n
Controlando todas las conexiones que inician desde dentro de nuestra red local y van hacia internet.<\/p>\n
Toda esta explicaci\u00f3n puede verse aparatosa y complicada, no lo es, de hecho no hemos tipiado mas e 10 comandos<\/p>\n
tc qdisc add dev eth2 root handle 1: htb default 11<\/p>\n
tc class add dev eth2 parent 1: classid 1:1 htb rate 2000kbit ceil 2000kbit<\/p>\n
tc class add dev eth2 parent 1:1 classid 1:10 htb rate 1512kbit ceil 2000kbit prior 0
\ntc class add dev eth2 parent 1:1 classid 1:11 htb rate 512kbit ceil 2000kbit prio 1<\/p>\n
tc qdisc add dev eth2 parent 1:10 handle 10: sfq perturb 10
\ntc qdisc add dev eth2 parent 1:11 handle 11: sfq perturb 10<\/p>\n
tc filter add dev eth2 protocol ip prio 1 parent 1: handle 1 fw classid 1:10
\ntc filter add dev eth2 protocol ip prio 2 parent 1: handle 2 fw classid 1:11<\/p>\n
iptables -t mangle -A FORWARD -p tcp –dport 80 -j MARK –set-mark 1
\niptables -t mangle -A FORWARD -p tcp –dport 80 -j RETURN<\/p>\n
Antes de subir este articulo google por otros art\u00edculos similares, como dije al inicio, hay un mont\u00f3n de ellos. Pero encontr\u00e9 uno que explican este mismo m\u00e9todo el htb desde otro enfoque y al leerlos puede quedar bien claro lo que explique aqu\u00ed.<\/p>\n
QoS Parte 1
\nhttp:\/\/cafetera.etsit.upv.es\/~carlos\/carblog\/2007\/01\/30\/qos-local-en-linux-i\/
\nQoS Parte 2
\nhttp:\/\/cafetera.etsit.upv.es\/~carlos\/carblog\/2007\/01\/31\/qos-local-en-linux-ii\/
\nQoS Parte 3
\nhttp:\/\/cafetera.etsit.upv.es\/~carlos\/carblog\/2007\/02\/02\/qos-local-en-linux-iii\/<\/p>\n
IMQ;
\nhttp:\/\/www.etxea.net\/docu\/qos\/qos.html<\/p>\n
Este otro art\u00edculo incluye informaci\u00f3n de IMQ para quienes intenten controlar el tr\u00e1fico de entrada, es \u00fatil si se quiere evitar DoS o administrar el ancho de banda que invertirnos en los servicios que publicamos a internet hosting WEB, correo, ftp y todas las conexiones que podr\u00edamos recibir.<\/p>\n","protected":false},"excerpt":{"rendered":"
Que desastroso resulta en muchas ocasiones administrar algo tan simple como una red, especialmente cuando existen usuarios en ella que les importa poco el trabajo de quienes si quieren trabajar en internet. No me explayare mucho en este asunto, muchos manuales y tutoriales hay de QoS, yo me dedicare a explicar brevemente como implementar uno…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,1],"tags":[],"class_list":["post-237","post","type-post","status-publish","format-standard","hentry","category-consultoria-y-manuales","category-personal"],"_links":{"self":[{"href":"https:\/\/www.lastdragon.net\/index.php?rest_route=\/wp\/v2\/posts\/237","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.lastdragon.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.lastdragon.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.lastdragon.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.lastdragon.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=237"}],"version-history":[{"count":0,"href":"https:\/\/www.lastdragon.net\/index.php?rest_route=\/wp\/v2\/posts\/237\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.lastdragon.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=237"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.lastdragon.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=237"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.lastdragon.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=237"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}