{"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\/sq\/blog\/administrirovanie\/kak-trablshutit-otechestvennyj-ipsec-vpn-chast-1","title":{"rendered":"Si t\u00eb b\u00ebni troubleshooting p\u00ebr nj\u00eb IPsec VPN vendor. Pjesa 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Si
\n<\/p>\n

Situata<\/h3>\n

\nI\u2019m taking a break. Drinking coffee. The student set up a VPN connection between two points and has vanished. Checking: the tunnel is indeed there, but there\u2019s no traffic in the tunnel. The student isn\u2019t answering calls.<\/p>\n

I\u2019m boiling water and diving into troubleshooting the C-Terra Gateway. Sharing my experience and methodology.
\n<\/a><\/noindex><\/p>\n

T\u00eb dh\u00ebnat burimore<\/h3>\n

\nTwo geographically separated sites are connected by a GRE tunnel. GRE needs to be encrypted:<\/p>\n

\"Si
\n
\nI\u2019m checking the GRE tunnel\u2019s functionality. To do this, I run a ping from device R1 to the GRE interface of device R2. This is the target traffic for encryption. There\u2019s no response:<\/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--- 1.1.1.2 ping statistics ---\n4 packets transmitted, 0 received, 100% packet loss, time 3057ms<\/code><\/pre>\n
\nI\u2019m looking at the logs on Gate1 and Gate2. The log happily reports that the IPsec tunnel has been successfully established, no issues:<\/p>\n
root@Gate1:~# cat \/var\/log\/cspvpngate.log\nAug  5 16:14:23 localhost  vpnsvc: 00100119  lidhja IPSec 5 e krijuar, selektori i trafikut 172.17.0.1->172.16.0.1, proto 47, partner 10.10.10.251, id \"10.10.10.251\", Filtri \nIPsec:Protect:CMAP:1:LIST, Veprimi IPsec IPsecAction:CMAP:1, Rregulli IKERule IKERule:CMAP:1<\/code><\/pre>\n
\nIn the IPsec tunnel statistics on Gate1, I see that the tunnel indeed exists, but the Rcvd counter is reset:<\/p>\n
root@Gate1:~# sa_mgr show\nISAKMP sessions: 0 initiated, 0 responded\n\nISAKMP connections:\nNum Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd\n1 3 (10.10.10.251,500)-(10.10.10.252,500) active 1070 1014\n\nIPsec connections:\nNum Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd\n1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 480 0<\/code><\/pre>\n
\nI\u2019m troubleshooting C-Terra this way: looking for where the target packets are getting lost on the path from R1 to R2. In the process (spoiler) I\u2019ll find the error.<\/p>\n
Diagnostikim<\/h3>\n
\nStep 1. What Gate1 receives from R1<\/b><\/p>\n
I\u2019m using the built-in packet sniffer \u2013 tcpdump. I run the sniffer on the internal (Gi0\/1 in Cisco-like notation or eth1 in Debian OS notation) interface:<\/p>\n
root@Gate1:~# tcpdump -i eth1\n\ntcpdump: verbose output suppressed, use -v or -vv for full protocol decode\nlistening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes\n14:53:38.879525 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 1, length 64\n14:53:39.896869 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 2, length 64\n14:53:40.921121 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 3, length 64\n14:53:41.944958 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 4, length 64<\/code><\/pre>\n
\nI see that Gate1 is receiving GRE packets from R1. Moving forward.<\/p>\n
Step 2. What Gate1 does with GRE packets<\/b><\/p>\n
Using the klogview utility, I check what happens to GRE packets inside VPN<\/a> the C-Terra driver:<\/p>\n
root@Gate1:~# klogview -f 0xffffffff\n\nrezultati i filtrimit p\u00ebr paket\u00ebn d\u00ebrguese 172.16.0.1->172.17.0.1, proto 47, len 112, n\u00ebse eth0: zinxhiri 4 \"IPsecPolicy:CMAP\", filtri 8, id e ngjarjes IPsec:Protect:CMAP:1:LIST, statusi PASS\nencapsulating me SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, n\u00ebse eth0\npaketa d\u00ebrguese 10.10.10.251->10.10.10.252 kaloi, proto 50, len 160, n\u00ebse eth0: encapsulated\n<\/code><\/pre>\n
\nShoh q\u00eb trafiku gre i synuar (proto 47) 172.16.0.1 -> 172.17.0.1 kaloi (PASS) n\u00ebn rregullin e enkriptimit LIST n\u00eb hart\u00ebn e kriptografis\u00eb CMAP dhe u enkriptoi (encapsulated). M\u00eb pas paketa u rrug\u00ebzua (passed out). N\u00eb daljen e klogview nuk ka trafik p\u00ebrgjigj\u00ebs.<\/p>\n
Po kontrolloj listat e aksesit n\u00eb pajisjen Gate1. Shoh nj\u00eb list\u00eb aksesit LIST, e cila p\u00ebrcakton trafikun e synuar p\u00ebr enkriptim, q\u00eb do t\u00eb thot\u00eb q\u00eb rregulli i M\u00cb nuk \u00ebsht\u00eb konfiguruar:<\/p>\n
Gate1#show access-lists\nList i zgjeruar IP t\u00eb aksesit LIST\n    10 lejo gre host 172.16.0.1 host 172.17.0.1<\/code><\/pre>\n
\nDalja: problemi nuk \u00ebsht\u00eb n\u00eb pajisjen Gate1.<\/p>\n
M\u00eb shum\u00eb rreth klogview<\/b><\/p>\n
Drejtuesi VPN p\u00ebrpunon t\u00eb gjith\u00eb trafikun n\u00eb rrjet, jo vet\u00ebm at\u00eb q\u00eb duhet t\u00eb enkriptohet. K\u00ebto lloj mesazhesh duken n\u00eb klogview, n\u00ebse drejtuesi VPN p\u00ebrpunoi trafikun e rrjetit dhe e kaloi at\u00eb n\u00eb form\u00ebn e paenkriptuar:<\/p>\n
root@R1:~# ping 172.17.0.1 -c 4<\/code><\/pre>\n
<\/p>\n
root@Gate1:~# klogview -f 0xffffffff\n\nrezultati i filtrimit p\u00ebr paket\u00ebn d\u00ebrguese 172.16.0.1->172.17.0.1, proto 1, len 84, n\u00ebse eth0: zinxhiri 4 \"IPsecPolicy:CMAP\": nuk ka p\u00ebrputhje\npaketa d\u00ebrguese 172.16.0.1->172.17.0.1 kaloi, proto 1, len 84, n\u00ebse eth0: filtruar<\/code><\/pre>\n
\nShoh q\u00eb trafiku ICMP (proto 1) 172.16.0.1->172.17.0.1 nuk kaloi (no match) n\u00eb rregullat e enkriptimit t\u00eb hart\u00ebs s\u00eb kriptografis\u00eb CMAP. Paketa u rrug\u00ebzua (passed out) n\u00eb form\u00ebn e hapur.<\/p>\n
Hapi 3. \u00c7far\u00eb merr Gate2 nga Gate1<\/b><\/p>\n
Po nis nj\u00eb sniffer n\u00eb nd\u00ebrfaqen WAN (eth0) t\u00eb Gate2:<\/p>\n
root@Gate2:~# tcpdump -i eth0\ntcpdump: dalja e p\u00ebrmbledhur \u00ebsht\u00eb e mb\u00ebshtetur, p\u00ebrdorni -v ose -vv p\u00ebr dekodimin e plot\u00eb t\u00eb protokollit\nduke d\u00ebgjuar n\u00eb eth0, lloji i lidhjes EN10MB (Ethernet), madh\u00ebsia e kapjes 262144 bajt\n16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), gjat\u00ebsi 140\n16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), gjat\u00ebsi 140\n16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), gjat\u00ebsi 140\n16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), gjat\u00ebsi 140<\/code><\/pre>\n
\nShoh q\u00eb Gate2 po merr paketa ESP nga Gate1.<\/p>\n
Hapi 4. \u00c7far\u00eb b\u00ebn Gate2 me paketat ESP<\/b><\/p>\n
Po nis utilitarin klogview n\u00eb Gate2:<\/p>\n
root@Gate2:~# klogview -f 0xffffffff\nrezultati i filtrimit p\u00ebr paket\u00ebn hyr\u00ebse 10.10.10.251->10.10.10.252, proto 50, len 160, n\u00ebse eth0: zinxhiri 17 \"FilterChain:L3VPN\", filtri 21, statusi DROP\npaketa hyr\u00ebse 10.10.10.251->10.10.10.252 u hodh, proto 50, len 160, n\u00ebse eth0: firewall\n<\/code><\/pre>\n
\nShoh q\u00eb paketat ESP (proto 50) u hodh\u00ebn (DROP) nga rregulli (L3VPN) i murit t\u00eb zjarrit (firewall). Po verifikoj q\u00eb n\u00eb Gi0\/0 \u00ebsht\u00eb lidhur v\u00ebrtet lista e aksesit L3VPN:<\/p>\n
Gate2#show ip interface gi0\/0\nGigabitEthernet0\/0 \u00ebsht\u00eb n\u00eb gjendje, protokolli i linj\u00ebs \u00ebsht\u00eb n\u00eb gjendje\n  Adresa e internetit \u00ebsht\u00eb 10.10.10.252\/24\n  MTU \u00ebsht\u00eb 1500 bajt\n  Lista e aksesit p\u00ebr daljet nuk \u00ebsht\u00eb e vendosur\n  Lista e aksesit p\u00ebr hyrjen \u00ebsht\u00eb L3VPN<\/code><\/pre>\n
\nKam zbuluar problemin.<\/p>\n
Hapi 5. \u00c7far\u00eb \u00ebsht\u00eb gabim me list\u00ebn e aksesit
\n<\/b>
\nPo shoh se \u00e7far\u00eb p\u00ebrb\u00ebn lista e aksesit L3VPN:<\/p>\n
Gate2#show access-list L3VPN\nExtended IP access list L3VPN\n    10 permit udp host 10.10.10.251 any eq isakmp\n    20 permit udp host 10.10.10.251 any eq non500-isakmp\n    30 permit icmp host 10.10.10.251 any<\/code><\/pre>\n
\nShikoj se jan\u00eb t\u00eb lejuara paketat ISAKMP, prandaj po vendoset tuneli IPsec. Nd\u00ebrkoh\u00eb, nuk ka rregull leht\u00ebsues p\u00ebr ESP. Duket se studenti confundoi icmp me esp.<\/p>\n
Po rregulloj list\u00ebn e aksesit:<\/p>\n
Gate2(config)#\nip access-list extended L3VPN\nno 30\n30 permit esp host 10.10.10.251 any<\/code><\/pre>\n
\nHapi 6. Po kontrolloj funksionalitetin<\/b><\/p>\n
S\u00eb pari, sigurohem q\u00eb lista e aksesit L3VPN \u00ebsht\u00eb e sakt\u00eb:<\/p>\n
Gate2#show access-list L3VPN\nExtended IP access list L3VPN\n    10 permit udp host 10.10.10.251 any eq isakmp\n    20 permit udp host 10.10.10.251 any eq non500-isakmp\n    30 permit esp host 10.10.10.251 any<\/code><\/pre>\n
\nTani nga dispositivi R1, po nis trafikun e synuar:<\/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--- 1.1.1.2 ping statistics ---\n4 packets transmitted, 4 received, 0% packet loss, time 3006ms\nrtt min\/avg\/max\/mdev = 2.650\/10.970\/35.338\/14.069 ms<\/code><\/pre>\n
\nFitorja. Tuneli GRE \u00ebsht\u00eb vendosur. Numri i trafikut n\u00eb hyrje n\u00eb statistikat IPsec nuk \u00ebsht\u00eb zero:<\/p>\n
root@Gate1:~# sa_mgr show\nISAKMP sessions: 0 initiated, 0 responded\n\nISAKMP connections:\nNum Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd\n1 3 (10.10.10.251,500)-(10.10.10.252,500) active 1474 1350\n\nIPsec connections:\nNum Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd\n1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480<\/code><\/pre>\n
\nN\u00eb port\u00ebn Gate2, n\u00eb daljen e klogview jan\u00eb shfaqur mesazhe se trafiku i synuar 172.16.0.1->172.17.0.1 \u00ebsht\u00eb dekriptuar me sukses (PASS) nga rregulli LIST n\u00eb kart\u00ebn kriptografike CMAP:<\/p>\n
root@Gate2:~# klogview -f 0xffffffff\nrezultati i filtrimit p\u00ebr paket\u00ebn hyr\u00ebse 172.16.0.1->172.17.0.1, proto 47, len 112, n\u00ebse eth0: zinxhiri 18 \"IPsecPolicy:CMAP\", filtri 25, id e ngjarjes IPsec:Protect:CMAP:1:LIST, statusi PASS\npaketa hyr\u00ebse 172.16.0.1->172.17.0.1 kaloi, proto 47, len 112, n\u00ebse eth0: decapsulated<\/code><\/pre>\n
\nP\u00ebrfundime<\/b><\/p>\n
Studenti e prishi daljen. 
\nKujdes me rregullat e M\u00cb.<\/p>\n
Inxhinier anonim
\nt.me\/anonimous_engineer<\/i>
\n
Burimi: 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\udd47Si t\u00eb zgjidhim problemet e VPN IPsec vendase. Pjesa 1 | ProHoster","description":"Situata Daljes.","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/kak-trablshutit-otechestvennyj-ipsec-vpn-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sq_AL","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\/sq\/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\/sq\/wp-json\/wp\/v2\/posts\/91646","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=91646"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/91646\/revisions"}],"predecessor-version":[{"id":156750,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/91646\/revisions\/156750"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media\/91647"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=91646"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=91646"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=91646"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}