{"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\/it\/blog\/administrirovanie\/kak-trablshutit-otechestvennyj-ipsec-vpn-chast-1","title":{"rendered":"Come risolvere i problemi di un VPN IPsec domestico. Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Come
\n<\/p>\n

Situazione<\/h3>\n

\n\u00c8 il weekend. Sto bevendo un caff\u00e8. Lo studente ha configurato una connessione VPN tra due punti ed \u00e8 scomparso. Controllo: il tunnel c'\u00e8 davvero, ma non c'\u00e8 traffico nel tunnel. Lo studente non risponde alle chiamate.<\/p>\n

Metto il bollitore e mi immergo nel troubleshooting del Gateway S-Terra. Condivido la mia esperienza e metodologia.
\n<\/a><\/noindex><\/p>\n

Dati di origine<\/h3>\n

\nDue siti geograficamente separati sono collegati tramite un tunnel GRE. Il GRE deve essere crittografato:<\/p>\n

\"Come
\n
\nControllo la funzionalit\u00e0 del tunnel GRE. A tal fine, eseguo un ping dall'apparecchiatura R1 all'interfaccia GRE dell'apparecchiatura R2. Questo \u00e8 il traffico target per la crittografia. Non ci sono risposte:<\/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
\nControllo i log su Gate1 e Gate2. Il log riporta con gioia che il tunnel IPsec \u00e8 stato stabilito con successo, senza problemi:<\/p>\n
root@Gate1:~# cat \/var\/log\/cspvpngate.log\nAug 5 16:14:23 localhost vpnsvc: 00100119  Connessione IPSec 5 stabilita, selettore di traffico 172.17.0.1->172.16.0.1, proto 47, peer 10.10.10.251, id \"10.10.10.251\", Filtro \nIPsec:Protect:CMAP:1:LIST, AzioneIPsec AzioneIPsec:CMAP:1, RegolaIKE RegolaIKE:CMAP:1<\/code><\/pre>\n
\nNelle statistiche del tunnel IPsec su Gate1 vedo che il tunnel esiste davvero, ma il contatore R\u0441vd \u00e8 azzerato:<\/p>\n
root@Gate1:~# sa_mgr show\nISAKMP sessions: 0 initiati, 0 risposto\n\nCollegamenti ISAKMP:\nNum Conn-id (Indirizzo locale, Porta)-(Indirizzo remoto, Porta) Stato Inviati Ricevuti\n1 3 (10.10.10.251,500)-(10.10.10.252,500) attivo 1070 1014\n\nCollegamenti IPsec:\nNum Conn-id (Indirizzo locale, Porta)-(Indirizzo remoto, Porta) Protocollo Azione Tipo Inviati Ricevuti\n1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 480 0<\/code><\/pre>\n
\nSto eseguendo il troubleshooting su C-Terra: cerco dove si perdono i pacchetti di destinazione lungo il percorso da R1 a R2. Nel processo (spoiler) trover\u00f2 un errore.<\/p>\n
Troubleshooting<\/h3>\n
\nPasso 1. Cosa riceve Gate1 da R1<\/b><\/p>\n
Uso il pacchetto sniffer integrato \u2013 tcpdump. Avvio lo sniffer sull'interfaccia interna (Gi0\/1 in notazione Cisco-like o eth1 in notazione Debian):<\/p>\n
root@Gate1:~# tcpdump -i eth1\n\ntcpdump: output verboso nascosto, usa -v o -vv per la decodifica completa del protocollo\nascoltando su eth1, tipo link EN10MB (Ethernet), dimensione cattura 262144 byte\n14:53:38.879525 IP 172.16.0.1 > 172.17.0.1: GREv0, chiave=0x1, lunghezza 92: IP 1.1.1.1 > 1.1.1.2: richiesta ICMP echo, id 2083, seq 1, lunghezza 64\n14:53:39.896869 IP 172.16.0.1 > 172.17.0.1: GREv0, chiave=0x1, lunghezza 92: IP 1.1.1.1 > 1.1.1.2: richiesta ICMP echo, id 2083, seq 2, lunghezza 64\n14:53:40.921121 IP 172.16.0.1 > 172.17.0.1: GREv0, chiave=0x1, lunghezza 92: IP 1.1.1.1 > 1.1.1.2: richiesta ICMP echo, id 2083, seq 3, lunghezza 64\n14:53:41.944958 IP 172.16.0.1 > 172.17.0.1: GREv0, chiave=0x1, lunghezza 92: IP 1.1.1.1 > 1.1.1.2: richiesta ICMP echo, id 2083, seq 4, lunghezza 64<\/code><\/pre>\n
\nVedo che Gate1 riceve pacchetti GRE da R1. Proseguo.<\/p>\n
Passo 2. Cosa fa Gate1 con i pacchetti GRE<\/b><\/p>\n
Utilizzo di klogview per osservare cosa succede con i pacchetti GRE all'interno VPN<\/a> del driver C-Terra:<\/p>\n
root@Gate1:~# klogview -f 0xffffffff\n\nrisultato di filtraggio per pacchetto in uscita 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: chain 4 \"IPsecPolicy:CMAP\", filter 8, event id IPsec:Protect:CMAP:1:LIST, status PASS\nincapsulando con SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0\npacchetto in uscita passato 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: incapsulato\n<\/code><\/pre>\n
\nOsservo che il traffico GRE di destinazione (proto 47) 172.16.0.1 -> 172.17.0.1 \u00e8 passato (PASS) sotto la regola di crittografia LIST nella mappa crittografica CMAP ed \u00e8 stato crittografato (incapsulato). Successivamente, il pacchetto \u00e8 stato instradato (passato fuori). Non ci sono traffico di risposta nell'output di klogview.<\/p>\n
Controllo le liste di accesso sul dispositivo Gate1. Vedo un elenco di accesso LIST, che definisce il traffico di destinazione per la crittografia, quindi le regole M\u042d non sono configurate:<\/p>\n
Gate1#show access-lists\nElenco IP di accesso esteso LIST\n    10 permit gre host 172.16.0.1 host 172.17.0.1<\/code><\/pre>\n
\nConclusione: il problema non si trova sul dispositivo Gate1.<\/p>\n
Ulteriori informazioni su klogview<\/b><\/p>\n
Il driver VPN gestisce tutto il traffico di rete, non solo quello che deve essere crittografato. Questi messaggi possono essere visti in klogview se il driver VPN ha elaborato il traffico di rete e lo ha trasmesso in forma non crittografata:<\/p>\n
root@R1:~# ping 172.17.0.1 -c 4<\/code><\/pre>\n
<\/p>\n
root@Gate1:~# klogview -f 0xffffffff\n\nrisultato di filtraggio per pacchetto in uscita 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: chain 4 \"IPsecPolicy:CMAP\": no match\npacchetto in uscita passato 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: filtrato<\/code><\/pre>\n
\nVedo che il traffico ICMP (proto 1) 172.16.0.1->172.17.0.1 non \u00e8 stato incluso (no match) nelle regole di crittografia della mappa CMAP. Il pacchetto \u00e8 stato instradato (passed out) in chiaro.<\/p>\n
Passo 3. Cosa riceve Gate2 da Gate1<\/b><\/p>\n
Avvio il sniffing sull'interfaccia WAN (eth0) di Gate2:<\/p>\n
root@Gate2:~# tcpdump -i eth0\ntcpdump: output dettagliato nascosto, usa -v o -vv per una decodifica completa del protocollo\nin ascolto su eth0, tipo link EN10MB (Ethernet), dimensione di cattura 262144 byte\n16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), lunghezza 140\n16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), lunghezza 140\n16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), lunghezza 140\n16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), lunghezza 140<\/code><\/pre>\n
\nVedo che Gate2 riceve pacchetti ESP da Gate1.<\/p>\n
Passo 4. Cosa fa Gate2 con i pacchetti ESP<\/b><\/p>\n
Avvio l'utilit\u00e0 klogview su Gate2:<\/p>\n
root@Gate2:~# klogview -f 0xffffffff\nrisultato della filtrazione per il pacchetto in entrata 10.10.10.251->10.10.10.252, proto 50, lunghezza 160, if eth0: catena 17 \"FilterChain:L3VPN\", filtro 21, stato DROP\ndropped nel pacchetto 10.10.10.251->10.10.10.252, proto 50, lunghezza 160, if eth0: firewall\n<\/code><\/pre>\n
\nVedo che i pacchetti ESP (proto 50) sono stati bloccati (DROP) dalla regola (L3VPN) del firewall. Verifico che la lista di accesso L3VPN sia effettivamente collegata a Gi0\/0:<\/p>\n
Gate2#show ip interface gi0\/0\nGigabitEthernet0\/0 \u00e8 attivo, il protocollo di linea \u00e8 attivo\n  L'indirizzo Internet \u00e8 10.10.10.252\/24\n  MTU \u00e8 1500 byte\n  La lista di accesso in uscita non \u00e8 impostata\n  La lista di accesso in entrata \u00e8 L3VPN<\/code><\/pre>\n
\nHo trovato il problema.<\/p>\n
Passo 5. Cosa c'\u00e8 di sbagliato nella lista di accesso
\n<\/b>
\nGuardo cosa rappresenta l'elenco degli accessi 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
\nVedo che i pacchetti ISAKMP sono autorizzati, quindi viene stabilito un tunnel IPsec. Tuttavia, non c'\u00e8 una regola di autorizzazione per ESP. Evidentemente, lo studente ha confuso icmp e esp.<\/p>\n
Correggo l'elenco degli accessi:<\/p>\n
Gate2(config)#\nip access-list extended L3VPN\nno 30\n30 permit esp host 10.10.10.251 any<\/code><\/pre>\n
\nPassaggio 6. Controllo il funzionamento<\/b><\/p>\n
Per prima cosa mi assicuro che l'elenco degli accessi L3VPN sia corretto:<\/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
\nOra avvio il traffico di destinazione dal dispositivo R1:<\/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 statistiche ping ---\n4 pacchetti trasmessi, 4 ricevuti, 0% perdita di pacchetti, tempo 3006ms\nrtt min\/avg\/max\/mdev = 2.650\/10.970\/35.338\/14.069 ms<\/code><\/pre>\n
\nVittoria. Il tunnel GRE \u00e8 stato stabilito. Il contatore del traffico in entrata nelle statistiche IPsec non \u00e8 a zero:<\/p>\n
root@Gate1:~# sa_mgr show\nISAKMP sessions: 0 iniziate, 0 risposte\n\nISAKMP connections:\nNum Conn-id (Indirizzo Locale,Porto)-(Indirizzo Remoto,Porto) Stato Inviati Ricevuti\n1 3 (10.10.10.251,500)-(10.10.10.252,500) attivo 1474 1350\n\nConnessioni IPsec:\nNum Conn-id (Indirizzo Locale,Porto)-(Indirizzo Remoto,Porto) Protocollo Tipo Azione Inviati Ricevuti\n1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480<\/code><\/pre>\n
\nSul gateway Gate2 \u00e8 comparso nel output di klogview un messaggio che il traffico destinato 172.16.0.1->172.17.0.1 \u00e8 stato decrittografato (decapsulato) con successo (PASS) dalla regola LIST nella mappa crittografica CMAP:<\/p>\n
root@Gate2:~# klogview -f 0xffffffff\nrisultato della filtrazione per il pacchetto in entrata 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: catena 18 \"IPsecPolicy:CMAP\", filtro 25, id evento IPsec:Protect:CMAP:1:LIST, stato PASS\npacchetto in entrata 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: decapsulato<\/code><\/pre>\n
\nRisultati<\/b><\/p>\n
Lo studente ha rovinato l'uscita. 
\nFai attenzione con le regole M\u042d.<\/p>\n
Ingegnere anonimo
\nt.me\/anonimous_engineer<\/i>
\n
Fonte: 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\udd47Come risolvere i problemi con IPsec VPN nazionali. Parte 1 | ProHoster","description":"Situazione di uscita.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-trablshutit-otechestvennyj-ipsec-vpn-chast-1","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\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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/91646","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=91646"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/91646\/revisions"}],"predecessor-version":[{"id":156750,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/91646\/revisions\/156750"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/91647"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=91646"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=91646"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=91646"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}